How do I create another run button?

[Jesse B]

I am currently building a LabVIEW application for use in our analyzer labs. I can get the application to run upon opening the program, but once the user ends the VI with a large "STOP" button I created, that user cannot get the program to run again without clicking the small white arrow on the upper-left corner of the screen. Some of the users who are unfamiliar with LabVIEW have a difficult time finding the run button. Is there a way to create a large "RUN" button on the front panel that tells the VI to run?

Thanks in advance.

[ASTDan]

The main problem you have is once the VI is stopped you can only run it again from the LabVIEW run button. You might want to rearchtiect your program so it is not dependant on someone pressing the run button.

I like to add a Start and a Stop button for my applications that need that functionality. I hide the run button from my users. In my applications the VI's are always "running".

There are many ways to do this the simplest is to use a state machine architecture

http://zone.ni.com/devzone/cda/tut/p/id/3024

I like to create a "Wait for user" state that contains an event structure that monitors the UI. Based on what happens in the UI, the wait for user state fires the appropriate case. The only catch is you will have to poll the stop button when in a "running" state.

There are architectures that are more versatile. I like this one.

http://zone.ni.com/devzone/cda/tut/p/id/3023.

Check out this presentation for more information on state machines

http://decibel.ni.com/content/docs/DOC-2724

[jdunham]

I think most LV developers handle this by not using the STOP functionality. A 'normal' application hides the toolbar (since nothing on the toolbar has meaning to non-LV users), runs when opened, has some LV-implemented buttons for starting the user's tasks, and remains running until the user wants to quit the app, at which time the Exit LabVIEW function should be called.

Users shouldn't really be expected to tell the difference between 'running' and 'loaded but not yet running'. It's your job to make sure that the built app never gets into the latter state. Pretty much no other program they will use on the computer has that behavior, so they find it very confusing. It doesn't really require much extra code to accomplish this.

[Jesse B]

Yeah, that does make sense to just have the program quit entirely whenever the user clicks "STOP", or to just have it always running and then the "RUN" and "STOP" buttons apply to an inner loop in the program. The situation we had was users would sometimes want to investigate signals in Measurement & Automation Explorer, but were unable to do so while the program was running since those I/O channels become reserved by the program. In this case, it sounds like the always running but having a "RUN" and "STOP" button for an inner loop would work best.

Thanks again,

Jesse.

[Darrell]

QUOTE (jdunham @ Mar 5 2009, 03:28 PM)

A 'normal' application hides the toolbar (since nothing on the toolbar has meaning to non-LV users), runs when opened, has some LV-implemented buttons for starting the user's tasks, and remains running until the user wants to quit the app, at which time the Exit LabVIEW function should be called.

Using a state machine is a good way to handle this. If you're not familiar with state machines in LabVIEW, try File>>New... And when the dialog widow comes up, select the following from the tree: VI>>From Template>>Frameworks>>Design Patterns>>Standard State Machine.

[Mark Yedinak]

Personally I prefer the producer/consumer pattern. I like to have all of the user interface events handled by an event structure. This provides faster feedback for the user, even if the actual action is not taken immediately. You can always let the user know that it is being processed. With a state machine only architecture you always have to wait for a state to complete before you can detect input from the user. In some cases this can be a long time and the user is left wondering if the application is aware of their input.