Wiring constants into the queue in a queued, event driven state machine

[MicTomReiSr]

I'm creating a queued state machine. Every time I change the queue control options to create a new event I have to recreate a constant in each queued event. Is there a way around this? I'm up to 27 events and changing them all is cumbersome. And I'm sure there are more to folow.

[tbob]

I am not sure what you are trying to do. What options in the queue are you changing? Why do you need a constant in every event. Sounds like you are not using the queued state machine properly. Please post your code.

[MicTomReiSr]

tbob,

Thanks for the response. I borrowed the technique from a presentation (Five Techniques for Better LabVIEW Code) posted on the Bloomy controls website (http://www.bloomy.com/resources/index.php#pres). I'll also attach my code. There are several SubVIs that I purposely did not include. I will if needed.

Appreciate your feedback.

[tbob]

This is really not a proper use of a queued state machine. Usually a state machine is used when the outcome of one state dictates the next state. In your particular case, you are initializing, then waiting for some control event to cause some action. Your program is not a true state machine, but rather an event driven machine. I would do away with the queued state machine altogether. Move the intialization code to the beginning of the vi, in front of the loop. Move the code inside each other case to the event structure. For example, the code in the TTL Read case can be moved to the event structure case TTL Word: Value Change. Now, when you add a new control, you only need to create a new event case for that control.
If you still want to use the state machine and the queue, you will have to modify each and every event case everytime you add a new control.

[MicTomReiSr]

Ignoring the TTL Read event, how would you manage the LED events and Channel Enable events?

[LV_Pro]

Are you using enums for your constants? If so, make a control from one, right click on it and under "advanced" select "customize" and when in the control editor change the pulldown from "Control" to "Type def." Save it with a useful name, and then in the vi in which you originally created it, use it to create a new constant. You will be able to select the different constant values were you need them and now when you want to add or subtract a "named" value you just click on the closest copy of the type def, either control or diagram constant, and choose customize (or double click into the tool editor if you made that choice in the options in the Tool pulldown at the top of the screen). Any changes you make will automatically be replicated everywhere you have used the typedef, whether a control, indicator or constant. Using enums also allows having case statements that have cases with the same names at the "named" value.

Hope this helps and is what you were refering too.

Putnam Monroe
Certified LabVIEW Developer

[Dennis_Knutson]

You do all of the events the same. In the LED X event, put your LED State String Creator subVI and wire the control to the input. In each LED x Gain event, wire the control to the subVI. Just move all of the code that you have for each state into the event that is set.

[MicTomReiSr]

Thanks Putnam. That was it.

[tbob]

I have partially modified the vi so that you can see how to finish it. I have moved the state case structure to the bottom so that you can highlite and drag the code from the case to the event. I have also deleted the queue and associated functions. After moving all code from the case to the event, you can delete the case structure. Make sure all wiring is correct, especially the stop condition and the other boolean shift register wires. This is really the best structure for this type of event driven programming. Easy to maintain by adding more event cases, and less overhead by removing the queue. Don't get me wrong, I am a firm believer in state machine architecture, but your situation was not practical for a state machine. Perhaps you will run into another project that will be suitable for a queued state machine.

[tbob]

Forgot to attach. Sorry...