Time to weigh in... A well designed queued message machine offers good debugging options... To wit, my default state is the "not a case" case. In the event of a typo or changing the name of a state, it is captured @ DEBUG and displays the error message telling me what the calling state was and the "incorrect syntax" state. makes the debugging go much quicker as those code of errors are eliminated.Even without invoking the debug logging option in my base machine.
The enums are ok, especially if you are using the state machine toolkit. This forces you to 'ethically' follow a true statemachine structure where NOTHING is arbitrary. And while you can do this with strings to guide the states, it is not as 'enforced'..However, I can limit the number of wires, locals, globals, clusters, references and any other trick you can think of, by adding parameter parsing to my queued message engine, allowing me to send case specific data/parameters without any extra 'tricks'.... Look ma, no hands 🙂
In the 'short time', I have been I have been doing LabVIEW, I have found that people (who have not developed in a hole), have developed similiar coding architectures, so I must be doing something right.
In conclusion, the biggest thing that one can do, is digest these different architectures and utilize them where they are best suited. Remember, there are always 10 ways to skin a cat, however, mine is usually best :D. But you will need to decide which one suits you, just remember... You should stay abreast of what else is going on.
Learn to recognize good code from bad code, and following good coding practices. This forum provides good examples of both. And if you want a third option for a template, check my link at the bottom... Without looking at Jim's, I am sure they are both similiar, although the one I have posted the code for is a few years out of date, and was the base, single loop structure. But it should provide a great base queued message engine (mistakenly called a statemachine) that can be evolved over the years... and also does not tie you to bloated 'tool' packages.
Also, as a tip for developing whichever architecture you decide to pursue. Develop your base machine, put in in your pallete and then in the pallete editor, merge the code, so that you do not deal with a template VI, rather, you drop the code for your 'machine' in your block diagram. Why do this? there have been several times, when something that started as a simple 2/3 case VI develops into a higher level VI... Now, I do not need to trash what I did, I can just add the queue message machine engine directly into what I already have!
Paul
