LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Value Signaling property for interloop communication

Solved!
Go to solution

I just ran across this sentence in a LabVIEW StyleGuide on the DQMH website:

 

    "Avoid the use of the Value Signaling property for inter-process communication."

 

In my medium-size applications, I often have a GUI loop (with an Event Sequence), a DAQ loop, and a Logging loop in the top-level vi. I use queue's or events to communicate between the loops, and sometimes a Value Signaling property to trigger an event case in the GUI loop from one of the other two loops. I am in the midst of learning DQMH, and can see that if I employed properly, the need to using Value Signaling would largely disappear. But in the meantime, can someone explain why it's a faux pas?

0 Kudos
Message 1 of 6
(131 Views)

What is an "event sequence"?

 

We can probably give more targeted advice once we see some simplified code. What do the triggered events do?

0 Kudos
Message 2 of 6
(118 Views)

My guess is that Value Signaling is much slower because it's performing a front panel update.

Message 3 of 6
(109 Views)

I meant "Event Structure", not Event Sequence. 

 

 

0 Kudos
Message 4 of 6
(96 Views)
Solution
Accepted by topic author FlatCat

Paul Cardinale nailed it. The Value Property (with or without signaling) is performed in the UI thread just as any other VI frontpanel property. This means your code has to arbitrate for the UI thread, update the control value, wait for the control to be redrawn and then return back to the thread it was originally operating in.

 

There are various examples that show the performance difference of using the value property nodes, globals, and locals. From those the first is way less performant than the other two.

 

Globals are bad in many other ways as they let anyone change the value at any time, creating perfect sources for race conditions. Locals are better as they isolate access to one single VI but if you are not careful, you still can create race conditions.

 

But the value property is slow, evil, very easy to create race conditions and did I mention ugly? Use of it should be causing you some pain. It’s sometimes unavoidable but in most cases simply lazy programming, that will bite your ass rather sooner than later.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 5 of 6
(54 Views)

But the value property is slow, evil, very easy to create race conditions and did I mention ugly? Use of it should be causing you some pain. It’s sometimes unavoidable but in most cases simply lazy programming, that will bite your ass rather sooner than later.


I've gotten away with them without being bitten in the ass because I only happen to have used them where timing is not critical, and I am always very careful about race conditions. But I promise to stop using them, if for no other reason than to avoid being called lazy 😀. Thanks to you and Paul for explaining. 

0 Kudos
Message 6 of 6
(41 Views)