Pablop wrote:
Thanks Ravens Fan,
I was thinking about putting the logic in a subvi. The current state and various paramters as input, the next state as output. It would clean up the diagram, but not necessarily avoid the logic creep as I add steps. I may poke around with this concept.
I was just reading about action engine in another post, but most of the terminolgy and concepts were not clear to me.
Do you have experience with queueing/enqueuing/dequeing to control a state machine? I've been thinking about that process list idea and was wondering if it has legs. I suppose I can start messing around with the examples and tutorials to see if its a fit.
In case you haven't seen Ben's Action Engine Nugget.
Most of my state machines have been simpler. A couple of calculations in line, pass it into the shift register. There is one place where I have used an architecture similar to a queued state machine.
I have a separate loop that handles serial comms with another device. I provide the loop with a queue, and before running it, I preload it with a few commands, such as Get A, Get B, Get C, where I want to continually have the loop poll the device for values A, B, and C. In the case structure for those commands, they will re-enqueue the command. Other parts of my code have the ability to execute some actions by putting their own command sets in the queue, such as Set D, data, Get E, .... these commands don't reenqueue themselves.
This gives me the ability to continually poll the the device for the values A, B, C but also allow other parts of the code to get their turn to essentially communicate with the serial device in turn. Another key command is shutdown which will allow the VISA resource to close and to flush the queue, close the queue reference and exit the loop gracefully.
With any of these commands, if I need something to happen immediately, then I enqueue that command to be put at the front of the queue to be next up.
