Implementing Stop, Pause, Retake Data in one loop and over several other loops

[momof4]

I have a sub vi that communicates to three GPIB devices(Controller, UUT, secondary standard).  I'm thinking of using a state machines with the states of command pressure, monitor to ready(For loop), settling time, take data, plot result, pause, redo test point(s).  I have booleans that will be active at certain times of this process.  In the take data case, the STOP, PAUSE, RETAKE DATA SET will all be active which makes that case somewhat messy with all the boolean stuff.  While in the monitor to ready I need only the STOP.  This also requires the use of local variables - which from my understanding is a bad idea.  Can anyone give me some advise on the best way to program?  THANKS in advance!

[Mark_Yedinak]

It would be helpful to see what you have written so far.

Without seeing any code I would suggest that you define a typdefed cluster that will contain specific state information (your booleans) and wire that through your state machine using a shift register. Each state could act upon the specific data that it needs to use. If you are tieing your UI (stop button for example) into the state machine I would avoid doing this. Use a producer/consumer architecture which allows you to separate the UI tasks from the processing tasks. If the user hits teh stop bottun a STOP message is sent to the consumer loop via a queue/or notifier. It is generally a good idea to separate th eprocessing tasks from the user interface.

[momof4]

Thanks for the input!  I just took core 3 and learned more about producer/consumer architecture and thought about using it but I didn't think it would work because in the take data case of the state machine if the STOP button is pressed the data collection is interrupted and the program operation is stopped.  The little that  I understand about queues/notifiers is that you could not interrupt the data collection.  Am I understanding that correctly?  With the state machine I am using FOR LOOP's with a conditional terminal - if STOP(or PAUSE or RETAKE DATA) is pressed the loop stops and performs the desired action.  I guess I could use the same thing with the producer consumer but it doesn't seem like it would be practical.  Hum?  Any further guidance would be appreciated.  THANK YOU!

[johnsold]

As Mark requested, posting your VI would make it a lot easier for us to make productive suggestions.

You indicate that you have {for loops with conditional stops connected to front panel buttons} enclosed in one or more states of your state machine.  This can (and in your case probably does) cause all kinds of problems.  The producer/consumer architecture is designed to handle precisely these kinds of situations.  ALL the buttons and other front panel controls which require immediate action are handled by an event structure in the producer loop.  Commands derived from the button presses are sent to the consumer loop via a queue.  If you use a state machine, it is typically in the consumer loop.  But in order to remain responsive to commands (especially Pause and Stop), the consumer (state machine) loop must never stay in one state longer than the minimum acceptable time to respond to the commands. Rather than nesting loops inside the cases, pass the data via a shift register on the outer loop and keep repeating the same state until its task is completed or until a new command results in moving to a new state.

You indicate that one of your states is Monitor to Ready (MtR).  Apparently it is used after a command to change the pressure. Consider this alternative:

Current state Pressure Next state

MtR Not Ready Wait 100ms

Wait 100 ms x MtR x means pressure is not checked in this state

MtR Not Ready Wait 100 ms

Wait 100 ms x MtR

MtR Ready Take Data...

It stays in the MtR state just long enough to read the pressure and test whether it is ready.  Then it either goes to a Wait state to wait 100 ms before taking another reading or goes to the Take Data state to continue the process.  After the Wait state it goes back to the MtR state again.  After each state it checks the queue for a new command.  Thus it never takes longer than 1/10 of a second to respond to a command from the user interface.

Use a similar approach to any other state which might take a long time to complete.

A Stop command does not necessarily stop the program.  It can send the state machine to a shutdown state which turns off the data acquisition, sets the pressure to a safe level (vent?), save any data accumulated so far, and then ask the user if he wants to exit the program or restart the process.  This is one of the huge advantages of using queue to send messages (commands) from the producer to the consumer as opposed to having the button connected to a loop stop terminal.

Lynn

[momof4]

Thanks!  I see.  Very helpful.  I'm in the planning stage and the code is actually not giving me problems.  It just seems like there should be a better way.  ...and there is!  I'll put some thought into the recommendation posted and will post the code if I need further assistance.  THANKS, again!

[momof4]

Hello,  This is Alma.  I developed some code based on your recommendations (Lynn and Mark).  If you would take some time to look at it and give me your input on my approach, I would appreciate it.  I've been a LabVIEW user since 2.2 days, was away for a few year, came back to 7 Express, and feel like I've been playing catch up ever since.  I would appreciate any suggestions.  THANKS in advance!

[srdfrn]

Hi Alma,

That looks like a great start.  One thing I noticed is that you don't have your "Action" Indicator set up to update as the program runs.  Is this your intention?

Also -- I know you have already taken Core 3, but if you would like a few more resources to look through, which have information on Producer/Consumer loop architecture, check out the following:

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

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

Regards,

Stephanie R.

National Instruments