Design Pattern: Classic State Machines as Dynamically Generated Reentrant SubVIs

[Steffen Prince]

I am looking for a design pattern that will allow me to dynamically generate an arbitrary number of Classic State Machines. These CSMs should inherit their initial state information from the top level VI. The top level VI should also be able to read the indicators of the CSMs.

I would like to use this pattern as a basis for individually controlling the heating and cooling of arbitrary number of UUTs with heating elements, represented as CSMs.

I have modified a pattern found in this thread.

My question is: Is this an appropriate pattern for what I'd like to do?

As a new user of LV (~4 months), I would appreciate your comments on structure and style of my block diagram.

 

The generic CSM will randomly transition between the two states: "Positive Sign" and "Negative Sign." The output is the random number, scaled by a numeric control, with sign according to the state.

The top level VI creates a number of instances of the reentrant CSM VI by reference, according to the number of subpanels it must fill.Then, once the CSM VI's are running and inserted into subpanels, the top level VI can change the Scaling controls and read the CSM outputs, which are compiled into one graph, displayed on the front panel.

[F._Schubert]

Really nice work for just 4 month experience!

Here my review

You should:

* Use shift registers for the error wires in the top level (all while and for loops).

* Set the stop loop also if an error occures (or the button with the error.status)

* Initalize the Controls of the reentrant VIs using CtrlValSet before the run VI

* If you change the Scaling, it will not affect the historical data. Is that desired?

* Reentrant VI: Replace the inner Case Structure by a switch statement

You could improve the design if doing one or more of the following:

* Use OpenG. They have an Application control palette that encapsulates the RunVI, CtrlValSet and CtrlValGet methods

* Use queues, notifieres and/or events for the communication with the SubVI. It will make the program more complex but you will get better scalability (less effort to add new functionality)

* Use the Event structure to catch user events. To do so, You will need two loops in the main V: one for CtrlGetVal+ display (Consumer), one for catching the Events and passing them (via queue or notifier) to the SubVIs and the consumer (this is the producer).

* For the last two points, try to learn about the producer/consumer design pattern.

Felix