Please Critique my State Machine Code

[HRL_Employee]

I wrote this program to control a 3D DLP Printer.  It flashes a lamp, lowers the build platform, moves the wiper blade back, raises the platform, brings the blade forward, waits for a while, then does it again.  I welcome any comments or critiques.

A couple issues I have:

1.  Can I clean this up at all, especially the initialization state?  A coworker suggested I use a stacked sequence to initialize things, but I read those are not good practice.  I wanted to make a subVI for the stepper motor since I use stepper motors in this way at work pretty often, but most the code is in the initialization state, which it seems like I can't put into the subVI anyway.

2.  I used the LabView State Machine template to start off, and it only checks the stop button when its waiting on user.  Should I make another event-checking-loop in parallel with the state machine to watch the stop button in case the user wants to stop during the print?

3.  I welcome any advice on error handling.  I think I should make an error state and deal with things there, correct?

Thanks for any time.

[oscarfonseca]

Hello HRL_Employee, I'll try my best to answer these concerns:

First of all, the community will not be able to fully review your code since there are some VIs missing. Thus, I base my comments solely in the Main VI you attached.

1. Can I clean this up at all, especially the initialization state?
   Yes, you should be able to use a subVI for this and please don't consider the stacked sequence. If you started from the Simple State Machine example project (File > Create Project.. > Simple State Machine) you will notice there is a Type Def cluster that holds all the state machine data. You can pass this to your subVI in the Init state and perform the actions in a clean diagram without passing a lot wires out from the terminal.
2. Should I make another event-checking-loop in parallel with the state machine to watch the stop button in case the user wants to stop during the print?
   Usually for more robust state machines, I would use the Queued Message Handler, which allows for this asynchronous listening to the User Interface. Else, you would add this check in a "Wait for Event" state in the state machine (usually with an event structure inside it).
3. I think I should make an error state and deal with things there, correct?
   Yes. The Queued Message Handler has more robust error handling, too, if that's a big concern.

All the best,