Configuration Files

[EJW]

When reading/writing configuration files, if you are reading into an indicator, you can just wire the data from the read to the indicator. When wiring the data to a control, however, one must use a local variable or a property node. Since this is being done in the initialization state of my program , does it really matter between using the local or the prop node. I would think during this state of the program, execution speed is not an issue. If I am correct in assuming: Property NOdes don't create copies of the data, local variables do. However, property nodes do switch to the UI thread to obtain a value. Are these assumptions correct as well?

[Grampa_of_Oliva_n_Eden]

QUOTE(EJW @ Apr 25 2007, 03:56 PM)

When reading/writing configuration files, if you are reading into an indicator, you can just wire the data from the read to the indicator. When wiring the data to a control, however, one must use a local variable or a property node. Since this is being done in the initialization state of my program , does it really matter between using the local or the prop node. I would think during this state of the program, execution speed is not an issue. If I am correct in assuming: Property NOdes don't create copies of the data, local variables do. However, property nodes do switch to the UI thread to obtain a value. Are these assumptions correct as well?

Unless I missed something, YES!

Ben

[BrokenArrow]

QUOTE(EJW @ Apr 25 2007, 03:56 PM)

.....does it really matter between using the local or the prop node......?

Aren't modern computers so fast and have so much memory, and recent versions of LabVIEW are so good at compiling for run-time, that the whole "avoid Local Variables and Property Nodes" mentality is no longer valid -- aisde from creating race conditions? (I can see the foaming-at-the-mouth LabVIEW gurus now ). Deciding between a Node and a Local, to me, comes down to the fact that a Node has the added benefit of GUI manipulation, otherise I don't know why you'd use a Node over a Local.

Richard

[Rolf Kalbermatter]

QUOTE(BrokenArrow @ Apr 29 2007, 08:45 AM)

Aren't modern computers so fast and have so much memory, and recent versions of LabVIEW are so good at compiling for run-time, that the whole "avoid Local Variables and Property Nodes" mentality is no longer valid -- aisde from creating race conditions? (I can see the foaming-at-the-mouth LabVIEW gurus now ). Deciding between a Node and a Local, to me, comes down to the fact that a Node has the added benefit of GUI manipulation, otherise I don't know why you'd use a Node over a Local.

Richard

No certainly not! By using property nodes to set that value of controls in abandunce you will likely create a program that feels very sluggish. For just one time intialization of the front panel this would probably be not to bad but it is very likely that once you start to use value properties intensely you use it all over the place and if you do that in a generic update state of your UI state machine it can already get bad. If you do that in a subVI through a control reference that is called all over the place in your program, you can probably sell a coffee machine too with your program so that your user can do something while waiting for the UI to update after each mouse click :-)

Rolf Kalbermatter

[BrokenArrow]

QUOTE(rolfk @ May 14 2007, 03:35 AM)

No certainly not! By using property nodes to set that value of controls in abandunce you will likely create a program that feels very sluggish. For just one time intialization of the front panel this would probably be not to bad but it is very likely that once you start to use value properties intensely you use it all over the place and if you do that in a generic update state of your UI state machine it can already get bad. If you do that in a subVI through a control reference that is called all over the place in your program, you can probably sell a coffee machine too with your program so that your user can do something while waiting for the UI to update after each mouse click :-)

Rolf Kalbermatter

Rolf, In the last sentence of my post, I tried to make a point that using a Property Node (over a Local) would NOT be the way to go.... and I mentioned that the Property Node manipulates the GUI, i.e. takes time. My first sentence; however, was off the hook and deserves any and all bashing you originally intended to dole out. :thumbup:

Richard

[Gary Rubin]

QUOTE(BrokenArrow @ Apr 29 2007, 09:45 AM)

Aren't modern computers so fast and have so much memory, and recent versions of LabVIEW are so good at compiling for run-time, that the whole "avoid Local Variables and Property Nodes" mentality is no longer valid

Are you serious?

Aren't you the one banging your head against the wall because the application you are trying to debug uses too many local variables?

QUOTE

The following searches gave a "Search Aborted. Too many search objects were found"....

Globals

: >2000

Locals

: >2000

Front Panel Terminals

: >2000

and...

347 VI's

594 sequences

1368 Attribute Nodes (old term for Property Node I guess)

This project is a morph of something that was started 10 years ago, has had 5 or so programmers in it, with almost weekly additions. There's almost no wires. If something is more than a few inches away or in a different frame, a local variable was used. There are hundereds of "read only" variables, and even "write only" variables !!!

[Mellroth]

QUOTE(BrokenArrow @ Apr 29 2007, 03:45 PM)

...I can see the foaming-at-the-mouth...

Blubb,Bllbllb

/J

[crelf]

QUOTE

There are hundereds of "read only" variables, and even "write only" variables !!!

"write only" variables: that's so tragic it's funny, but then again, not too funny, but so not too funny that it's really funny...

[BrokenArrow]

QUOTE(crelf @ May 15 2007, 09:45 AM)

"write only" variables: that's so tragic it's funny, but then again, not too funny, but so not too funny that it's really funny...

I'm delighted that this is getting some giggles! :thumbup: :beer: :thumbup:

[Gary Rubin]

QUOTE(BrokenArrow @ May 15 2007, 12:46 PM)

But, in my defense, these aren't "my" local variabes, globals, etc that I've been complaining about in another post. I've inherited the program in question, and the buckets of fun attached to it.

Regardless of whether they're "someone else's" local variables, I would think this experience would cause you avoid local variables like the plague in all of our future coding.

I've run across code similar to yours (although not nearly to that scale), as has anyone else who's ever tried to use the example Labview code for the ICS-554 A/D card. I never used locals much anyway, but after slogging through that, my knee-jerk reaction was to avoid them even more.

[Neville D]

QUOTE(EJW @ Apr 25 2007, 12:56 PM)

Since this is being done in the initialization state of my program , does it really matter between using the local or the prop node. I would think during this state of the program, execution speed is not an issue. If I am correct in assuming: Property NOdes don't create copies of the data, local variables do. However, property nodes do switch to the UI thread to obtain a value. Are these assumptions correct as well?

I think you are correct. Property nodes won't create copies, BUT they are even slower than Locals, probably due to the thread switch to the UI thread among other things.

In terms of speed:

Wire is fastest, followed by local, followed by property node.

In terms of initialization, it may NOT matter for a few (even a few hundred) variables what you use to initialize, and property nodes will even help you keep the block diagram neat, burying the nodes in a sub-VI and reusing it for resetting properties of similar variables. I guess that was the idea in having the value property.

Neville.

[crelf]

QUOTE(BrokenArrow @ May 16 2007, 02:46 AM)

...in my defense, these aren't "my" local variabes...

I know - I'm laughing with you Hey - why aren't you laughing?

[EJW]

QUOTE(Neville D @ May 15 2007, 01:06 PM)

I think you are correct. Property nodes won't create copies, BUT they are even slower than Locals, probably due to the thread switch to the UI thread among other things.

In terms of speed:

Wire is fastest, followed by local, followed by property node.

Neville.

Soo... A system that does not have a lot of memory (or not a lot left) may benefit from using property nodes during initialization, and a system with enough memory should use local variables and gain the performance benefit of speed.

"write only" variables?? I want some of what they were taking...

[jpdrolet]

QUOTE(Neville D @ May 15 2007, 01:06 PM)

I think you are correct. Property nodes won't create copies,

Why does this myth still prevail? When you read a value property node, you get a copy of the control value at the read time, the same way you get a copy from a local.

I think this come from the idea that control references are data pointers which they are not. They are only control references, a value that allows to identify the control. And while the reference can be carried around without the control data being copied, data is indeed copied when you use the value property from the reference.

[BrokenArrow]

QUOTE(EJW @ May 15 2007, 01:18 PM)

"write only" variables?? I want some of what they were taking...

Here's how you create "write only" variables in LabVIEW:

1) circa 1998: Mark writes a number to a Global called "LaserBias", so that 5 other VI's can use it. He then goes on to work at Lockheed.

2) circa 2001: Joe doesn't need the variable in two of the VI's because he cleaned up the code a bit. He dies tragically in a rice picking accident.

3) circa 2003: Nancy is bewildered by 2000+ globals, and the sharp lady she is, gets rid of many of them, but now the motor doesn't work. She's fired.

4) circa 2005: Fred gets rid of all of the global reads having to do with the "Laser" because the Laser is no longer used in the system since the motor doesn't work anyway. But who knows, we might need a laser again some day, so he leaves the global write in that one VI.

5) circa 2007: Richard comes on board to find out why the new Laser doesn't work. In a VI called "Init Systemr" is a DBL constant of 1250 written to a U32 global called "LaserBias". There's also 4 Property Nodes dedicated to Visible, Disabled, Boolean Text, and Caption Visible. No other references to that global exist. He finds 82 such "write only" variable and goes on to moan about it on LAVA.

:beer: :beer: