Redundant State Machine ?

[EJW]

:question: I have attached a simplified version of a state machine i am using in a large program.

I am curious as to what the experts think on my particular implementation of it is.

Does it look redundant, awkward, etc. Any ideas on improvements?

The event structure also handles user events, i left this out in my example.

Download File:post-3482-1160058566.vi

[LAVA 1.0 Content]

Your consumer loop (bottom) waits on a notifier; default is -1 (wait forever).

Your top loop has a timeout of 100 ms, and sends a Timeout notifier every 100 ms. You don't need to send a timeout unless the bottom loop needs to perform some periodic action; it will just "wait forever". That's the nice thing about user events, no polling or no-op type loops!

You should consider using typdefs for your enums; if you add or rename a case later on, you would have to edit all the enum constants in all the different cases on your block diagram(yuck!). I usually name the typdef control to match the vi name..

Looks good! :thumbup:

[EJW]

Your consumer loop (bottom) waits on a notifier; default is -1 (wait forever).

Your top loop has a timeout of 100 ms, and sends a Timeout notifier every 100 ms. You don't need to send a timeout unless the bottom loop needs to perform some periodic action; it will just "wait forever". That's the nice thing about user events, no polling or no-op type loops!

You should consider using typdefs for your enums; if you add or rename a case later on, you would have to edit all the enum constants in all the different cases on your block diagram(yuck!). I usually name the typdef control to match the vi name..

Looks good! :thumbup:

Actually, in the real program, there is a multiple channel/single point data acquisition ocurring, and monitoring of a DIO card during the timeout state.

The various steps (1-4) would coincide with my finite data acquisition (approx 5000 samples per each of 8 channels - 40K total), followed by a process , status, update, and output state, then back to the timeout state providing there wasnt an error generated which is then handled by the error state first. I was using the timeout on the event structure to trigger the timeout state and still allow full UI functionality.

[JDave]

Actually, in the real program, there is a multiple channel/single point data acquisition ocurring, and monitoring of a DIO card during the timeout state.

The various steps (1-4) would coincide with my finite data acquisition (approx 5000 samples per each of 8 channels - 40K total), followed by a process , status, update, and output state, then back to the timeout state providing there wasnt an error generated which is then handled by the error state first. I was using the timeout on the event structure to trigger the timeout state and still allow full UI functionality.

Perhaps I don't quite understand the desired result, but I would prefer two separate VIs running in parallel. One is dedicated to monitoring the DIO card and passing data via Queue to the other VI which processes the data. Or just separate the User Interface portion into a separate VI (I assume the Event Structure handles some other events as well). This could simplify the code and design a bit, IMHO.

David