I am currently using a VI, lets call it MAIN.vi, which is based on a queued message handler, employing 4 queues. Specifically, it consists of 5 while loops one of which holds an event structure. The other 4 loops are used for hardware control, data acquisition, data processing and display, respectively, and each with its corresponding queue. This works rather well and does what I want.
Now, I want to add some pumps to my setup. These pumps are controlled from the the MAIN.vi user interface. The main mode of operation I envision is that the user can send certain states (along with some data) to the PUMP.vi, which executes the state and uses the data. Here are some example cases:
- MAIN.vi sends the state "Start Procedure" along with a 2D-array:
PUMP.vi enters state "Start Procedure" in which it interprets the 2D-array as procedure steps (rows) and pumping speeds (columns 0 & 1) and step duration (column 2). It then goes to a state "Next Step" in which the first row is send to the pumps as a VISA command. After this state it goes to the state "Check Status" in which I check if the current procedure step has completed, based on the duration of that step. If it has completed, it enters "Next Step", if it hasn't it reenters "Check Status". It does this until the last step completes and then enters an "Idle" state, in which nothing happens.
- MAIN.vi sends the state "Emergency Stop":
PUMP.vi enters the state "Emergency Stop", regardless of what other states are scheduled to execute, and halts the pumps. Then it idles.
My problem is that PUMP.vi "never" finishes, that is only sends back some data to the display loop of the MAIN.vi when in the "Check Status" case. As such, my current implementation waits for PUMP.vi to finish, which holds up my hardware loop and stalls proper functioning.
My current implementation envisions a queued message handler for PUMP.vi, similar to MAIN.vi, only that PUMP.vi has one queue, not four. That way I can refer to the MAIN.vi queues inside PUMP.vi and vice versa. IS THIS A GOOD ARCHITECTURE FOR THIS PURPOSE?
PUMP.vi is only supposed to stop when MAIN.vi completes as well.
Summary of requirements:
1): Upon running MAIN.vi, PUMP.vi is started and remains in the idle state until another state is received.
2): MAIN.vi can send states to PUMP.vi which are then handled. Based on the specifc states sent, PUMP.vi can decide on any further states to run.
3): PUMP.vi contains a "check status" case in which some data is send back to the display loop of MAIN.vi using a queue.
4): MAIN.vi has full control over the execution order of PUMP.vi, in that certain user actions can be prioritised, such as an "Emergency Stop".
