Simple State Machine Vs Queued State Machine

Question

Using LV2009 + WIN7+Pentium 4 @ 2.5Ghz with 3 GB RAM.
I have a machine control code inside a 10mS main loop that has 7 ( yes seven ) Queued State Machines (  QSM) and I find the  Finished Late boolen keeeps poppping often. Not a very good sign if you ask me.
And the code itself does not have too much of computation or FP activity. But it has four Graphs with one plot on each of them. These are updated once every 10ms. Can slowing this update ( say once every 250ms ? ) help ? 
A simple query : In terms of performance overhead, does a QSM  demand more than a  Simple State Machine ( SSM ) ? Can I avoid the Finished Late warning by switching over to SSM at least in three of the cases out of the seven ?
Thanks 
Raghunathan
LV2012 to Automate Hydraulic Test rigs.

Answer 1

I think your question demonstrates my point.  Unfortunately, I don't have a good example to point you to and don't have the time to write one.  I will try to explain better.  Let's take a simple example - a landscape watering controller (sprinkler controller).  This controller will have several states (e.g. initializing, waiting, watering, closing). Each of these states will accept several commands, but not all commands are accepted in all states.  For example, if the system is watering, a command to start watering could be ignored.
In most programs, at least some states should be interruptible.  For example, if it starts to rain, the watering system should stop watering immediately instead of watering for a set length of time.  However, if the system is in the initialization state, this will probably not be interruptible (but also short).
As you said, the classic LabVIEW way to implement such a thing is to have a case statement to represent the state, and a case statement (usually queue driven) in each state frame to handle the commands.  You thus have a loop with a double case structure.  This can get somewhat unwieldy for large programs.  Note that which case structure represents what will be determined by the relative number of each item. For example, if you have fifty commands and three states, the state should go into the command case.
So how do LabVIEW classes help?  They can eliminate one or both levels of these case structures through the use of dynamic dispatch.  This is done as follows.  A parent class is created that is a generic command.  It has commands for each state.  For each actual command, a class is derived from the parent class.  There are VIs in the specific command class for each state.  A command is generated by creating the correct object for the current state, then calling the parent class command.  Dynamic dispatch will execute the code for the correct command.  The command execution loop is then reduced to a single command VI which dynamically dispatches based on the actual command and the current state.
In practice, things as usually not quite this simple, and you may want different cases for either different commands or different states so that you can change the connector pane of the dynamically dispatched VI as needed.  Look up the LabVIEW examples on dynamic dispatch to see this in action.
I am afraid I have still not made myself clear.  Keep asking questions and I will try to keep answering.
This account is no longer active. Contact ShadesOfGray for current posts and information.