Showing results for 
Search instead for 
Did you mean: 

Architecture Suggestion: Deferring Procedure to another VI


I am currently using a VI, lets call it, 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 user interface. The main mode of operation I envision is that the user can send certain states (along with some data) to the, which executes the state and uses the data. Here are some example cases:

  • sends the state "Start Procedure" along with a 2D-array: 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.
  • sends the state "Emergency Stop": 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 "never" finishes,  that is only sends back some data to the display loop of the when in the "Check Status" case. As such, my current implementation waits for to finish, which holds up my hardware loop and stalls proper functioning.

My current implementation envisions a queued message handler for, similar to, only that has one queue, not four. That way I can refer to the queues inside and vice versa. IS THIS A GOOD ARCHITECTURE FOR THIS PURPOSE? is only supposed to stop when completes as well.


Summary of requirements:

1): Upon running, is started and remains in the idle state until another state is received.

2): can send states to which are then handled. Based on the specifc states sent, can decide on any further states to run.

3): contains a "check status" case in which some data is send back to the display loop of using a queue.

4): has full control over the execution order of, in that certain user actions can be prioritised, such as an "Emergency Stop".

0 Kudos
Message 1 of 2

Your current setup sounds fine - you just need to add a "non-emergency stop" state by the sounds of it.

Is that the problem you're describing?

Once is finishing up, send a new message to containing the instruction to go to the stop state, and then have end if it reaches the stop state.

0 Kudos
Message 2 of 2