how to code a stop button

[tkdbruin]

Hi,

I am trying to have a stop button control in my program. I do not want to use the Abort button that is already provided by LabVIEW because I want the program to take certain actions before exiting.

So I simply put an event structure to monitor the value change of the stop button. It works if I do actually want to use the button. But the problem occurs when I don't want to abruptly stop the program. If there is no reason for the user to manually stop the program, the program should just end normally. However the program hangs after finishing everything, apparently waiting for some action done on the stop button.

What is the correct way to code this?

Thank you very much

Jae-Ho Jeon

[altenbach]

This is a typical dataflow issue. If the stop event never occurs, the event structure (and thus the program) cannot finish.

There are many solutions. Please attach a simple version of your program and we'll find the best one. 😉

In general, a well built program starts when openend, and never finishes until the user manually closes it. You don't even need a stop button, you can just filter the "panel close" event, internally discard it, but initiate your shutdown code.

[AndrewAlford]

I would use a state machine logic which is a Case Structure inside a While loop. Goto Help->find examples and search for state machine. The example shipped with labview will get you started.

[WNM]

You may want to take a look at this thread since it deals with the same issues.

[Jarrod_S.]

You could also dynamically (programmatically) trigger the Stop button Value Change event by creating a property node for the Stop button (right-click >> Create >> Property Node) and selecting the property Value (Signaling). Then right-click the new property node and select Change to Write to allow for an input value.

You could then write a value to this property node whenever you wanted to execute the Stop button Value Change event case to shut down the program safely. A couple things to note:

1. Writing ANY value to this property node will execute the Value Change event case, even if the value technically hasn't changed. So don't just place this property node in a loop with a False constant wired to the input! You'll fire tons of unexpected event cases!

2. The Value (Signaling) property is different than the Value property. Both change the control/indicator's value, but only the Signaling property fires the Value Change event as well.

This certainly isn't the only solution. A State Machine is a great idea, though it relies inherently on polling rather than events which can increase response time and cause lost events. But in most cases it will work great!

[WNM]

---

@jarrod S. wrote:

 A State Machine is a great idea, though it relies inherently on polling rather than events which can increase response time and cause lost events. But in most cases it will work great!

---

Actually if the state machine contains a "Wait On User" case/state that in turn contains an event structure used to check for user inputs then there will be no chance for lost events.

If the VI is entirely user-event-driven then the state machine can "hang" on the event structure waiting for the user to do something, followed by the processing based on any occuring user event and then returning to wait for the next one.

If other periodic business must be handled (other than just user events) then the timeout case of the event structure can allow the state machine to deal with the other business before returning to the "Wait On User" case to again look to see if the user needs servicing.

[tkdbruin]

Thanks All.

Right now, I chose to simply programmatically invoke the abort method on the top level VI to force an exit on the program so that it won't have chance to wait for the stop button event. Thank you for all the great ideas.

JaeHo

[jasonhill]

That will definately force an exit.  A word of warning, be absolutely certain that you are closing references, VISA sessions, etc.  before the abort is called.  If you do not memory leaks, VISA errors, plagues of locusts, and other unexpected behaviors will result.