Labview 8.0 - My main vi has started to hang!

[smercurio_fc]

---

@Ibbo wrote:

Altenbach, sorry also wanted to ask:

You mention that the VI is getting a hammering from all the property nodes but I was taught that property nodes were the best way of interacting with indicators.  Is that not the case?

---

I think you may have misunderstood what was being said. To just write a value to the indicator you would not need to resort to a property node. Just wire the value to the indicator's terminal. A property node would cause a switch to the user interface thread, impacting performance. There are, of course, some things that you can only do with property nodes, such as making things visible/invisible. If you need to write to an indicator in more than one place then a local variable is better than a property node, but with local variables you MUST be careful to not cause race conditions.

[altenbach]

---

Ibbo wrote:

You mention that the VI is getting a hammering from all the property nodes but I was taught that property nodes were the best way of interacting with indicators.  Is that not the case?

---

Who teaches that??? 😮

Property nodes have a relatively high overhead because they execute synchronously and force a thread switch to the UI thread. Of course you have no choice for setting real properties such as "visible", but value properties are often overkill. When comparing a value change via wire, local variable, or value property node, the value property can be 1000x slower. (For subVIs, there is additional overhead, because property nodes force the front panel to be in memory even if it is not shown.)

There are plenty of discussions here. For example, have a look at the explanation by DFGray here.

Quote (with emphasis added in bold):

"Property nodes are synchronous and terminals and locals are not. This, combined with the UI thread switch, makes property nodes orders of magnitude slower than terminals and locals. Every time you write a Value property node, the node waits until the action is complete. Terminals and locals, however, are cached for the next UI update cycle. The value is changed in memory, but the front panel is updated at about 60Hz. This allows much more efficient usage."

In at least one case you set the visible and value property of the OK button in immediate succession. These could be combined into one property node containing two properties.

Also that constant switching between invisible and visible seems more like a gimmick. It seems it turns invisible for only a very, very short time.

For some reason you don't even connect your boolean controls and indicators to the code. Why not?

[Ibbo]

I read about property nodes being best in a LabView book but I think I must have failed to understand the context (ie. avoiding race conditions).

I didn't connect the boolean controls and indicators to the code because of my understanding that using their property nodes was best (because you have complete control over when the control is read or written in your code).

The visible invisible thing is simply to prevent over enthusiastic use of the OK button causing the embedded while loop to exit early...  but yes it is for a very short time as the rest of the digital I/O code executes very quickly.