Not to throw a wrench in things, but I have come to disagree with the idea of calling this concept here a "state machine." It is really a sequencer. States generally can end in "-ing" such as "Initializing", "Shutting down", "Stepper Motor Moving", etc. Now based on your "state" you can respond differently to different messages, requests, and so on which potentially send you through a different sequence. For instance, I am shutting down, so if I get a start test message, I ignore it. I may handle that different if I'm in the idling state, and different still if I am in the testing state. These two things, state machine and sequencer, are being interchanged fairly often and I think making this distinction is important.
If you start feeling you have way too many cases, one thing you can ask yourself is "could I just put the SubVI right here -- do I really need to have an entire case for 'turn on instrument, turn off instrument' etc?" I can tell you that as of late I have erred on the side of just dropping the SubVI right where I need it, in most situations, because it doesn't send me from case to case to case trying to follow the code which a sequencer would. Sometimes I do need a sequencer, so I use it, but I still am always asking myself this "do I really need it" question.
Edit: One important thing I forgot -- State machines often require passing, you guessed it, state, from one loop iteration to the next. And poor management of mutable state can turn into a nightmare when it comes to having multiple parallel loops running. So there is that, too. I have been focusing a lot on minimizing mutable state lately, avoiding putting too much in parallel when it can be in the same loop, and maintaining system state in a single location. It is quite remarkable how much easier it makes application development and debugging..
