Sequencing LabVIEW events without locking up entire program

[LabVIEW_Enjoyer]

I am working on a project that uses LabVIEW to send TCP/IP commands to some instruments (motor controllers, PLCs, measurement instruments) to automate a rather large process that requires 100+ commands to be executed in a specific sequence. These commands are sent via each instruments "Send Command" VI, which all function essentially the same way, with "Error in" "Error Out" terminals along with VISA terminals. The most "proper" way I figured to do this was by wiring the "Error In" "Error Out" wires between commands to sequence them properly, in conjunction with some "Stall Data Flow.vim" blocks for timing. This alone works excellent, but a problem arises because I need to asynchronously read and display sensor data while this long automated process is occurring. LabVIEW wants to complete the very long chain of events before moving onto any other task, and since this is a multiple minute process, I cannot asynchronously read my sensor data without constantly adding sensor checks into this long process, which seems incredibly tedious. Am I going about this the wrong way? I know that LabVIEW is great for parallel events where you don't usually have one long chain of commands, and so I am unsure if LabVIEW is even the right tool for this, although I cant think of another software that allows me to easily send TCP/IP commands to multiple instruments of different brands with an easy to make GUI while simultaneously reading sensor data.

To sum up my question: How do you sequence many (100+) actions while executing other asynchronous actions simultaneously?

[Jay14159265]

---

@LabVIEW_Enjoyer wrote:

To sum up my question: How do you sequence many (100+) actions while executing other asynchronous actions simultaneously?

---

Use the actor framework 

[Mark_Yedinak · Accepted solution]

Yes, LabVIEW is a good choice for this. What I would suggest is that you separate your sensor task from the command task. They should run in parallel. That way you can continue to read your sensors while sending the commands to the instruments. I would also suggest that rather than having a big long sequence of your send commands VIs, I would use an array with the the commands and use a for loop to send the commands. If you need different delays between commands this could be part of your array of commands. I envision the array to be a cluster with the necessary data for the commands such as the VISA reference and the command itself. It would also contain any other data that is required such as the delay.

[stefanha · Accepted solution]

Implementing the actor framework to parallelize 2 or 3 simple tasks seems like using a sledgehammer to crack a nut here.

As Mark mentioned, you should just have 2 or 3 loops in the same VI that run independently in parallel.

Loop number 1 is sending your chain of commands.

Loop number 2 is reading the sensor data. If the processing and visualization of the sensor data is not very consuming, you can do that directly in this loop aswell.

Else you should add loop number 3, which receives the raw sensor data from loop 2 via the LabVIEW Queue functionality and takes care about the processing and visualization.

Stefan

[altenbach · Accepted solution]

LabVIEW is a parallel language, so any part that does not depend on other parts will run independently.

First be careful with terminology.  You talk about "LabVIEW events", but later you don't mention any event structures and I don't think events are appropriate unless the sensor reading is event based, (i.e. triggered by the user). I assume sensor readings are  timed at regular intervals.

In any case, you need (at least) two independent parts.

A FOR loop that iterates over an array of commands. If you place a small wait, the stall dataflow is not needed. Place that inside a state machine while loop so it can be repeated. Also show the conditional terminal so the process can be interrupted if needed or on error.

Now place another while loop in parallel that reads your sensor data at regular intervals.

Maybe you need another while loop to handle UI interactions. Maybe add some light communication between all loops to synchronize certain happenings and state information.

A very (very!!) rough skeleton. Many parts are missing of course (cancel button, etc.).

[Jay14159265]

---

@stefanha wrote:

Implementing the actor framework to parallelize 2 or 3 simple tasks seems like using a sledgehammer to crack a nut here.

---

 At one point I believed as you say here, but that was before I embraced it and started using it on a daily basis. Now as soon as you start talking about parallel execution or sending messages, the quick and easy solution is most certainly using the Actor Framework, The only downside it you have to learn how to use it, which can be a bit of a bummer of a learning curve but once you are there you will never have to worry about queues or loops ever again, all your code can easily use the full power of the computer it is running on and it's super fast to develop code with. 

[LabVIEW_Enjoyer]

Ah this makes sense. My issue was that I did not realize while loops naturally run in parallel as handled by the CPU (or whatever). Up until now I had tried to use a single while loop with a case structure activated by a button that began the long process, with my sensor data being read outside of the case structure. I implemented 2 while loops as suggested and it works flawlessly. Thanks for the help. I know it was an elementary issue to be having, but I am new to LabVIEW and these things are not always obvious, so I appreciate the time you and the other repliers have taken to answer.

[altenbach]

---

@LabVIEW_Enjoyer wrote:

I know it was an elementary issue to be having, but I am new to LabVIEW and these things are not always obvious, so I appreciate the time you and the other repliers have taken to answer.

---

Automatic parallelism is one of the great strengths of LabVIEW. I am glad you learned it now! Good luck! 😄