Best Approach for Communication Between Two while Loops with Different Speeds in LabVIEW?

[PLSVK]

Hello LabVIEW community,

I'm currently working on improving an old LabVIEW VI, and I'm trying to find the best way to handle communication between two while loops running at different speeds. In the current VI, the communication between the loops is done using local variables, but I’m not sure if that’s the most efficient or reliable method.

I would like to know what alternative methods or best practices you would recommend for such communication. My primary goal is to improve performance and reliability, especially given the loops are operating at different speeds. 

I’d appreciate any insights or suggestions based on your experiences!

Thanks in advance!

[Basjong53]

It seems the top loop is updating the "WerteSing" indicator every 50 ms by using the "T soll Thermstate" control which is in turn updated by the bottom loop running every 250 ms. Why not just use dataflow and remove the top loop entirely? Just place the 3 subVIs of the top loop between "po_code" and "po_calc" of the bottom loop.

[LVNinja]

Some LabVIEW Purists say local variables are forbitten...

Check the performance with 2 different scenarios, measure the time to run the whole program the way it is now and then as the previous post suggested, combining in the same loop and see if there is any benefit. 

The risk of using Local variables, is that if the top loop runs faster than the lower loop, it may happen that it will run multiple times with the same data not the new data that came out of the bottom loop. 

One way to avoid that is using Producer/Consumer architecture, using queue message handlers. This way, every new data is send into a queue and the top loop removes the data from the queue (FIFO) and there is no data loss, and no risk of running with old data.

[PLSVK]

thank u for replying..Actually, I am communicating with two different devices that use different protocols. So, I guess I need separate handling for each device, which is why I am using two loops. If I were to combine them into one loop, it could complicate the communication process and synchronization between the devices. It would be difficult to ensure that both protocols are handled correctly and efficiently in a single loop. Therefore, it might not be ideal to merge them into one loop, especially if each device has its own timing and control requirements.

[PLSVK]

Thank you for your reply and the helpful suggestions!  I also considered using QMH, but as both loops are acting as producers and consumers simultaneously, it doesn't quite work in this case. I think using two separate Notifiers could be the best approach to ensure proper synchronization.  Thanks again for your help 🙂

[Basjong53]

It is not clear from just a screenshot what this program does, you didn't mention any instruments. Depening on the type of instrument communcation, you could still merge two loops, seeing as the two instruments are dependent on each other. They need each others data to perform their things.

As it stands now, the top loop executes 5 times in the time the bottom loop executes 1 time. So the top loop reads the same 'T soll Thermostate' value 5 times. Is this the desired operation? It could be, just asking.

[LVNinja]

Having separate loops for different instruments seems to be a good approach, I would do the same. I would go one step further. Keep the UI as the main VI loop with configuration, etc in one loop, acting as a a conductor (of the orchestra), then use the instrument loops as the musicians, communicating with the instruments and send the data into a queue message to avoid lost of data. 

[billko]

---

@LVNinja wrote:

Some LabVIEW Purists say local variables are forbitten...

Check the performance with 2 different scenarios, measure the time to run the whole program the way it is now and then as the previous post suggested, combining in the same loop and see if there is any benefit. 

The risk of using Local variables, is that if the top loop runs faster than the lower loop, it may happen that it will run multiple times with the same data not the new data that came out of the bottom loop. 

One way to avoid that is using Producer/Consumer architecture, using queue message handlers. This way, every new data is send into a queue and the top loop removes the data from the queue (FIFO) and there is no data loss, and no risk of running with old data.

---

We don't say they are forbidden, just discouraged, and you explained very well one reason why, and what the better solution is.  🙂