I really like your premise and architecture:
An important point is that any state diagram (and logic) that you use to control a process should be related to the process and not to internal computer program states or actions...
In the most general case, I use 4 asynchronous loops running in parallel and accessing the same "Task" queue (which contains strings indicating which task is to be executed)...
The only thing I'd do differently is to use type def enums for the process state and for the task queue to catch misspellings during the programming phase. (On older version of LabVIEW, the enums can be converted to and from strings for the queue, either with the flattening functions or with the Format to String and the OpenG VI.)
I'd argue that your task loop is really a state machine that handles the "computer program states" you reference in your first sentence. Keeping the two machines explicitly separate really clarifies the programming.
--
EnWirementally,
Paul F. Sullivan----------------------------------------------------
SULLutions (781)769-6869
"when a single discipline is not enough"visit http://www.SULLutions.com
----------------------------------------------------
