Mark Yedinak

QUOTE (Black Pearl @ May 7 2009, 09:44 AM) They can. They are useful for entering new feature requests, enhancements, bugs found during your testing as well as customer found bugs. Generally you can assign priority to your items which help you to scope the effort required and organize your tasks.

QUOTE (twinsemi @ May 5 2009, 03:27 PM) Try reinstalling the VISA from a none location. The installer is looking for the VISA runtime components required to include the VISA install in the application installer. The install builder is looking for the VISA stuff from where it was last installed.

QUOTE (Ton @ May 5 2009, 03:32 PM) Exactly. We use table quite a bit in our applications and over time we have built up a library of reusable VIs for manipulating the tables. This is one of those VIs. Others we have are for updating the contents of single cells, coloring cells based on their content, resizing the table as well as several others. In order to reuse these VIs we need to use a reference to the specific table we are manipulating.

Where I work we use the Agile process extensively. The product firmware is written in C and C++ and they use Agile to manage that process. We have also been using it for our LabVIEW development for our tools and automation. Agile itself is language independent so it can work just as easily with a LabVIEW development as it will with other languages. As for which flavor we use all I can say is that the Agile process that works best is the variety you customize to fit your environment. Many of our developers and managers attend the annual Agile conference and they have always returned saying that the folks who were most successful using it made the process their own. Pick and choose the parts from the different flavors that best meet your needs. The one thing that is good about Agile is that it really helps you to break your development down into small manageable tasks. It basically forces you to prioritize your efforts on small parts and do the minimal amountof work to meet the requirements of that task. It helps to keep you on focus for the task at hand and not try to create something that does everything all at once. The down side though is that sometimes it does lead you down the wrong path when a little more forethought would have helped to avoid that. Overall it works fairly well. In our environment we started using Wiki pages for our stories but have since switched to Sharepoint. Sharepoint is a bit more feature rich and makes maintaining the stories easier.

QUOTE (scls19fr @ May 5 2009, 02:13 PM) Here is the corresponding vi.

Here is the block diagram from the VI I use to set the scroll bar position for a table. The only missing piece that you don't get to see is the subVI to count the number of lines in a string. However this is pretty easy to do.

I would use a single control which will allow the user to enter data and give you a single scroll bar. If you want to protect the data in the other columns and make then read only you can place a custom string control (which you color as transparent) over the columns you do not want to be modified. You then disable this control and the user cannot edit the cells below it. However the exposed cells are still able to be modified.

Since you mentioned the Agile process you may want to look at Integating Agile Development in the Real World. I would also recommend that you find some way to capture the requirements for your projects. If you go the Agile route this can be accomplished by writing good acceptance criteria for your stories. The Agile process also helps you to prioritize your development efforts and allows you to manage feature creep.

It sounds like you are doing something along the lines of a decorator pattern.

I basically rolled my own solution that appears to be very similar to the Open G and MGI variants. The main difference that I have is that mine are specific to the section being read. They are driven by typedefs but they mine do require modification if the typedef changes. I may look at converting mine over to use these other methods for the ease of updates. However with thta said I would recommend some form of text based ini file with typedefed clusters for the parameters. You should be able to reuse sections of your ini file in different applications (for example network configuration data) when you have common data. Over time you build up a set of specific sections in your files and your users get a consistent looking configuration file across your applications. If you are only writing one or two applications this may not be as important but it becomes more desireable when you are maintaining 20+ tools for your users.

QUOTE (crossrulz @ May 5 2009, 11:16 AM) They do make external ATA hard disk cases which have a USB connection on them. Essentially this turns an old hard drive into an external USB drive. This is a good way to recover data from an old system. The boxes generally run about $70. QUOTE (crossrulz @ May 5 2009, 11:16 AM) My next question though is how was this file generated in the first place? There has to be a VI or something somewhere that was used to generate it. Or if all else fails, make your own new table and change the code to be able to read your new format. I agree that this is what you need to do.

I would further add are you trying to modify code that was written in LV 5.0 using LV 8.x? If you are this will not work since NI only guarantees you being able to open code from two major releases back. LabVIEW 8.x cannot read LabVIEW 5.0 code.

Can you please provide a few more details regarding your problem. I doubt anyone will be able to give you an answer based on your question. It is far to vague.

QUOTE (ShaunR @ Apr 29 2009, 06:07 PM) Yes, and my statements still stand. NI provides means to install and uninstall the LabVIEW development environment for debugging purposes. I imagine they do for TestStand as well. However, neither development environments are required and therefore deployment costs for a TestStand system are limited to the TestStand deployment license. Systems generally aren't deployed which support full development environments. If that is what you want then yes there is additional costs but that is a different breed of a deployed product.

QUOTE (ShaunR @ Apr 29 2009, 10:26 AM) But the full development license of LabVIEW is NOT required to run a TestStand deployment. Trust me, we are deploying systems here without a full license of either LabVIEW or TestStand installed on the machine. The LabVIEW runtime engine gets installed and a deployment license of TestStand is installed. The only cost for the deployed system is the $500 TestStand deployment license.

QUOTE (ShaunR @ Apr 29 2009, 05:42 AM) Actually a deployment license is only $500. Granted, you still have a license cost per installation but they do not have to purchase the entire TestStand license. These deployments work essentially the same as a standalone LabVIEW application with the runtime engine.

Jim Kring - I have been promising to talk to him about the Vi Package Manager and keep getting sidetracked. (Sorry Jim)

QUOTE (Prabhu_V @ Apr 24 2009, 01:05 AM) You can also do this programmatically using a property node.

QUOTE (crelf @ Apr 23 2009, 11:19 AM) True but one can hope. Just call me an optimist.

If you are only sending some basic pages to the server I think you would be better off building your strings and sending them via the native TCP connections. If you do a trace using your ActiveX version you should see what messages are being passed to the server. Your earlier version may have simply been missing a message that was generated by the ActiveX component. The TCP VIs are fairly basic. You would essentially need to use three of them. They would be the open, write and close VIs. More likely than not you will want to open the connection on port 80. What types of problems were you encountering?

QUOTE (Aristos Queue @ Apr 23 2009, 09:59 AM) I am continually impressed by all the "magic" that occurs under the hood of LabVIEW. This would be a great enhancement to LV when it gets added in the next release. This is one more reason that I think NI should get more aggressive about promoting LV as a general purpose programming language. It allows applications to benefit from current technology where other languages are still quite a ways off, at least with respect to the ease of using these features. However that is an entirely different topic for discussion. Anyway, feel free to pass along a job well done to the developers on my behalf.

QUOTE (GregSands @ Apr 22 2009, 04:30 PM) LabVIEW does split code across multiple cores. It does this now and it does a fairly decent job of it. If however you mean taking a single FOR loop and splitting its iterations across cores then I would agree with you that LV does not do this. However this would be a nontrivial task. Currently though LV does run nodes (and I am using NI's definition of a node) on separate cores. It automatically schedules things for you. Granted, LV realtime gives you more control over it but it works on desktop systems too.

I still fail to see how you can say that a queued message is not generating an event. A message can be queued from anywhere at any time just like your interrupts. The event handler (the part of the code taking messages from the queue) processes them as soon as the arrive just like an interrupt handler. Also, an interrupt handler will only be working on a single event at a time just like a queue. The old Motorola 68000 family processors had 7 interrupt levels which denoted priority levels. In LabVIEW if you created 7 queues and had 7 parallel message handlers (one for each queue) your system would not behave any differently than a 68000 processor. What you do and how events are processed is up to the "interrupt" handler. You had to write the specifics of your ISR for the 68K too. In addition, since the 68K was single threaded higher priority interrupts caused the code in the lower priority ISRs to stop running. Only one thing could be running at one time on that processor. For multithreaded, multicore systems you still need to figure out a way for one task to stop another. This would is true regardless of whether you are using LV or not. Multiple priorities don't really solve this problem when you have multiple parallel tasks running since each task is independent. In addition if you are using a single queue for events you can always queue a high priority task at the front of the queue. This way that event will be processed next. With respect to concurrent or parallel I think you are being a bit picky about the terms. Of course if you have a single CPU nothing every trully runs in parallel. However with multicore CPUs no LabVIEW does utiltize all of the cores. You don't even have to change your code for this to happen. I am not sure how old versions of LV would handle this but certainly the newer versions are aware of multiple cores. This is not true in the text based languages. You have to jump through quite a few hoops to take advantage of multiple cores with a single application.

QUOTE (jdunham @ Apr 20 2009, 06:56 PM) True, my "queue of one" for a notifier was an oversimplification but they are very similar in nature, especially with respect to events. BTW, queues can have multiple listeners too however the outcome is not deterministic. One listener will get the event but you don't really have control over which one if all listeners are waiting on the queue at the same time. Notifiers as you stated will allow each listener to receive a notification.

QUOTE (ShaunR @ Apr 20 2009, 06:21 PM) Perhaps this should be moved to a new thread. QUOTE (ShaunR @ Apr 20 2009, 06:21 PM) Actually Labview is inherently serial in nature (left to right). That is why you have to resort to other techniques to manage parallelism. I also fail to see how they are event driven given that you put something in the queue and take things out...nothing more. It is a serial buffer with access to only the first and/or last entry in the buffer. LabVIEW is inherently parallel in that to program parallel tasks all you need to do is drop two nodes next to each other. The underlying scheduler and task switcher will automatically run these pieces of code in parallel. Now with multicore CPUs LabVIEW can truly run them in parallel by running code segments on separate cores. The only "serial left to right" nature of LabView is the dataflow nature of the language (which also leads to parallelism) and programming style. There is nothing in LV that forces code to be executed from left to right if there is no dataflow. This is actually a common race condition bug that people make. They will put some node down on the right side of the diagram and think to themselves that since it is right of everything it will execute after the code to the left. In reality though once all of its inputs have been satifisied it will execute. Creating parallel tasks in C or C++ is not a trivial task. You have to manually create your processes and threads. In LabVIEW this is all done for you. Drop two loops next to each other and you have parallel code. It is as simple as that. No, queues are event driven. While waiting on a queue (or a notifier) your code does nothing. It is waiting for an event to trigger indicating that either an element has been queued or you have a timeout. Event driven means that your code is doing nothing until some event occurs. The code will effectively be using zero CPU cycles. (LabVIEW's scheduler will consume a few CPU cycles but the higher level code in your application will do nothing.) QUOTE (ShaunR @ Apr 20 2009, 06:21 PM) I don't tend to use queues much, but I do extensively use notifiers for passing data and synchronising, which aren't really event driven either in so much you can wait for a notifier and it will get triggered. The only truely event driven features in Labview are the Event Structure and VISA Event. But linking events programmatically accross disembodied vi's (which I use far too often); I've always found troublesome. Notifiers are nothing more than a queue of size one. A notifier can only have one element "queued" at a time. Queues simply allow more elements to be placed on the stack. Event structures and VISA events are just different event types. Regardless, when using queues or notifiers you are writing event driven code. As for your disembodied code I suggest you try http://forums.lavag.org/Network-Queue-t11048.html&p=46805' target="_blank">network based queues. Since you already use notifiers it shouldn't be too difficult for you to use queues.