LabVIEW
On block diagram terminal are not connected to anything- property nodes are used instead. Is there an advantage to this? (LV7.1)
I don't know if I would use a property node where a wire would suffice. The way I understand it: wires first, locals 2nd, and property nodes third in terms of performance. And never EVER use Globals. 
This was probably written by a LabVIEW beginner with a strong background in text based programming and is a very bad way to do things in LabVIEW!
Value property nodes (within the same diagram) act like local variables for all practical purpose, except they impose much more overhead because they are synchronous. The can be be orders of magnitude slower that locals or directly wired terminals.
They share all the disadvantages of local variables (race conditions, extra data copies, diagram clutter, code fragmentation, etc.).
Like local variables, they are confusing because the distinction between control and indicator is lost. For example if you would change a control to an indicator, nothing in the code would break but later if you run the VI, you can no longer operate it. Similarly, if you would change an indicator to a control, the user can change the value at runtime, possibly severly interfering with the code. If you wire the terminal, the main purpose (control vs. indicator) is better defined.
See also e.g.: http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=112401#M112401
(Local and global variables, and value property nodes have their use for special cases, but they should only be used if really needed).
PaulG. wrote:
And never EVER use Globals.
Never say never. One acceptable use of globals is to hold the GPIB address of instruments. They are set once and never written to again. If you change an instruments address, you change it at one place in software and all your code works.
There are other such uses for globals. When used like a constant, there is nothing wrong with globals.
Yes, i like having a global variable to keep my repository of constants (ege speed of light, unit converter constants, Bhor radii...) troughout my project. i has specifically big advantage when manually "changing" those constants (setting plank constant to '1'
There are other such uses for globals. When used like a constant, there is nothing wrong with globals.
). on other words it acts like a typedef for constants. 
The ability to define "constants" in LV would be nice.
And because I just like to spin things the other way...
What if all of the property nodes are using "Value(signaling)"? That would cast a whole new spin 
on this topic.
on this topic.Ben
For more reading on the topic of Globals please see the "Are Globals Evil?" Nugget.
Message Edited by Ben on 01-04-2008 05:59 PM
