control property node best practice?

[BrentSchenk]

Hi all,

I have included a pic but here's a short rundown on what I need to do:

I have three buttons, run pause and stop, each do the obvious.  When it isn't runnning I want the stop and pause disabled, and when it is running I want run disabled and stop and pause enabled, I think you get the picture.  The picture shows right now how I accomplish this, but is this the only way or best way to be updating these properties of the buttons?  I have to imagine there might be a better way to do this.  Also, if anyone can think of anything obviously not in the best LabVIEW programming practice in the picture I would be open to suggestions for improvement.  It's two parrallel loops, one to handle the events and one to perform each state of the test.  They communicate together through a queue reference.

regards

Brent

[RavensFan]

Updating the property nodes as you have shown is the only way I know of how to do it.

Overall, your architecture looks good.  One recommendation I have is to not wire a False constant to the 2 while loops.  Come up with a way to end the application gracefully.  As it is now, you have to use the Abort button to end the application.  I'm not sure why you are dequeueing and item in the Stop: Value change event.

[altenbach]

Another option might be to get rid of all the juggling of properties and unclutter the UI at the same time.

For example for start/stop, you could use a single switch action button where the FALSE case is labeled START and the TRUE case is labeled STOP. Press it to start and it will turn into a stop button during the run state.

The pause button could just be ignored when not in run mode, again without all that extra disable/enable code.

[F._Schubert]

The initialzation code in the flat sequence could be placed in an initialzation state in the state machine. The you call the state machine with initialization followed by idle.

Furthermore, the initialization code has the property nodes error not propagated.

Another option is to have one state machine loop only for the property nodes. But this will only be good practice, if your overall code is hug.

Overall, I miss a stop capability of the program (UI loop runs forever, Shutdown code in State machine?) and error handling (call of an error handling state if an error occures, stopping loops in case of error, error case around UI event loop).

Felix

[johnsold]

I have used a radio button control with Idle, Start/Running, Pause, Resume, and Stop buttons.  I use an array of references to the internal booleans to loop through all the enable/disable settings.  All this is done in the event case for Value Changed on the radio button control.  You could also use the OldVal terminal in the event case to simply ignore some combinations rather than disabling if that would provide a better user experience.  I also use OldVal to control a case structure to do some display initializations when Start follows Idle for example. 

Lynn 

[BrentSchenk]

I appreciate all of your inputs on the programming style.  First thing i did was implement a graceful way for the program to terminate itself.  After learning from you guys this is the only way to make those changes to those buttons i created another state in the state machine that sets the buttons back to idle status and i just call that and it goes to the idle state after that.  I will also be taking the other suggestions into consideration but after removing all those property nodes outside the loops and the ones inside the stop button event the diagram looks quite a bit cleaner.

Thanks guys

Brent

[DFGray]

One final comment, although it almost does not apply in this case.  Using a property node to set a value is about 1000x slower than using a local variable.  If you can, you should use the local.  In your case, the time is not critical, so it really should not matter.  Also, you would need a single-frame sequence (such as you used for initialization) to force any flow control.