update a control value using property nodes

[richjoh]

hmmm whats the problem with doing it this way.

I take a property node implicit or explicit and update a control. No local variables...

[tbob]

Property nodes are much slower than local variables.  If used improperly, they can still cause a race condition.  For just updating a front panel control, there is no advantage to using property nodes.  So use a local variable.  Just beware of race conditions.

[RavensFan]

There are probably only two advantages to updating the value by way of a property node.

1.  If you use value (signalling) to programmatically generate the value change event in an event structure.

2.  If you are already using some property nodes to set other properties like, color, visibility, blinking, ...  That would let you set several properties all in one node structure at the same time.

[Graziano]

---

@Ravens Fan wrote:

There are probably only two advantages to updating the value by way of a property node.

1.  If you use value (signalling) to programmatically generate the value change event in an event structure.

2.  If you are already using some property nodes to set other properties like, color, visibility, blinking, ...  That would let you set several properties all in one node structure at the same time.

---

  Not only: also if you already have a reference to a control, you can use it to access different properties of the control, even in different parts of block diagram.  Or you can change the value of some controls with the same routine, just change the reference provided as input.

  Anyway, if you have to update only one indicator, using local is preferred.

graziano

[altenbach]

---

richjoh wrote:

I take a property node implicit or explicit and update a control. No local variables...

---

There is nothing wrong with using local variables if needed, but a value property node is a very poor substitute for one. First of all, it inherits all the disadvantages of local variables (potential for race conditions, extra data copies, etc.) without providing any advantage.

Substituting a value property node for a local variable is a very misguided effort and means doing the wrong things for the wrong reasons. That's like switching to cigars as a means to stop smoking. 😄

Performance wise, writing to a value property node forces a synchronous update of the control, so it can become very expensive if you do this inside a fast loop for example.

We have discussed all this several times, a good thread is e.g. the following:

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=206678#M206678

[richjoh]

OK, my 2 cents, so updating a control using property nodes is slow compared to local variable. Possibly local variables are so fast they are more likely to cause race condition...

advantages of using property nodes are

(1) better data flow control vs local variable (which does not have an output to wire).

(2) I can pass control references in sub vi after sub vi after sub vi and set any value property node... mostly for large apps (1000 vi) to control front panel. ever try tracking debuggin the local variable you need to catch in 1000 or more vi s.

(3) using property nodes there are no copies of the control, its pass by reference. no advantage or disadvantage here, just use it when appropiate. Each and every local variable is a copy that persist in memory unlike text code where there is local scope, in text code the local variable is disgarded when out of scope.

(4) the local variable speed is no real advantage, seperating UI from processing of data is necessary when delays are unacceptable. Think of it like this - an application built works 100% but takes up 2x memory space, another application works 100% but takes up half the memory space. Memory space is not an issue since you entire used memory is 10% of the total... both apps do the job.

correct me if I'm wrong...

richjoh

[tbob]

Property nodes exist for a reason.  Local variables exist for a reason.  I use both.  There are times when it is proper to use one or the other.  Richjoh and others give examples of how to use property nodes properly.  The original poster alluded to the fact that he was just updating a front panel control.  For this, a local variable is best.  Perhaps there are other underlying things about his code that we don't know where a property node would be better.  Without further information it would be impossible to determine which is the best approach.  No need to argue advantages and disadvantages of both without knowing the whole story.

[CMal]

I'm not sure if anyone has mentioned this yet, but I always like to point out that you can get around the slowness of property nodes by using the "Defer FP Updates=True" property.  This prevents the front panel from updating synchronously while this property is set to true, and it still allows you to control a front panel from subVIs that might be several layers down.  Just make sure to set "Defer FP Updates=False" after you're done, otherwise the front panel won't do anything 🙂

Chris M

[altenbach]

---

richjoh wrote:

OK, my 2 cents, so updating a control using property nodes is slow compared to local variable. Possibly local variables are so fast they are more likely to cause race condition...

---

NOOOOO!!!!!

A race condition has nothing to do with the time it takes to execute a code element, it is entirely determined by the order in which the elements execute. If you have a race condition, you cannot guarantee in which order things happen, but the result will depend on the execution order.

In this case a race condition can occur if other parts of the code need to read the updated value from the control, but a possibility exists that the value gets read before your property node has a chance to update it with the current value.

Sure, the property node has error in/out terminals that can be used to enforce execution order, but at the same time it also sequentializes the code and thus might prevent optimization for multicore/multiCPU hardware.

This thread started out with the simple task of updating a control, and for that a local variable is the proper choice. Property nodes have their uses, but they are overkill for such a simple thing.

Don't forget that programmatically updating a control is not something that has a lot of uses, it is most useful for initializations. It can be very irritating to the operator if he can change controls and then they suddenly change their value programmatically to something else without operator itervention. Beginners often abuse hidden controls as "variables" to be read and written during code execution (either via locals or value properties). This kludge can often be replaced by shift registers where the data does not involve any front panel object at all. Maybe you should take a few steps and ask yourself why you need to update a control at all. Maybe the solution would be to turn it into an indicator and use its terminal directly in the place of the property node. 😉

Can you tell us a bit more about your application and the exact circumstances where you think a value property is advantageous?

[richjoh]

Reason I ask is I got my result back from the CLD Exam. There is a comment from the grader that goes like this "Property nodes used to update values"...

Personally, in my opinion, I don't see what the big deal is when grading the CLD. its appears (the grading) is more about style than execution. Dress for the occasion or you won't get in.... So I have no code to show but now have a better understanding as why the CLD exam comment is there.

Richjoh