From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-07-2006 04:59 PM
02-07-2006 05:07 PM
If possible, you always want to pass data to/from your front panel controls/indicators with wires. If this won't suffice (parallel loops, e.g.), then you will want to use locals. Try to avoid using the "Value" property unless you must write to your controls/indicators in a subVI. The "Value" property is very slow compared to locals due to threading issues associated with property nodes.
Hope this helps,
-D
02-07-2006 07:45 PM
02-08-2006 02:20 PM - edited 02-08-2006 02:20 PM
Hello all,
To take it one step further, the speed hit comes from the fact that these items
run in the UI thread along with all of your other user interface actions
(speed), and copies are always made of the data (performance AND speed)!
Check out the "LabVIEW
Performance and Memory Management"
tutorial -- while a little old its concepts are still dead on and it
does a great job of explaining the details of these issues.
If you need to pass data from/to parallel loops or sub-VIs consider
putting the
data in some sort of container (like a single element queue), and
passing the
container around.
Hope this adds just a little more insight!
Message Edited by Travis M. on 02-08-2006 02:21 PM
01-04-2012 12:43 AM
Really good Thread thanks
12-03-2012 04:22 AM
Hello travis could you please pour in some more information on Property node concept and whn can it be best used?? Thanks in advance.
04-15-2016 01:20 PM
Most of the threads address time penalities writing values, not reading them.
In a new app I am reading the propert value of "STOP", as the node has an error cluster input.
That extra input helps with Data Flow paradigm.
Also I can "OR" the nodes error cluster output and "STOP" to a loop termination.
So what's the cost compared to encalsuplating "STOP" in a sequence or case structure?
04-15-2016 01:28 PM - edited 04-15-2016 01:29 PM
You can test it yourself. Oviously the property node is far worse.
04-15-2016 01:38 PM - edited 04-15-2016 03:44 PM
@Pappion wrote:Most of the threads address time penalities writing values, not reading them.
Your use of a property node also precludes the use of latch action, which is the typical mechanical action of a stop button. What does the button do? What is the rest of the code architecture?
We cannot really tell without seeing the entire diagram.
If this is a toplevel stop to end the program, I would eliminate it anyway and use an event structure for the panel close event. It is not normal or intuitive to close an program with a special stop button in some poorly defined panel location, but everybody knows the meaning of the [X] in the upper right. You can always discard the event and handle special shutdown code. You could for example enqueue the stop command at the opposite end in that event case.
You can do that in a small parallel loop that just sits there, but enqueues an exit command if the user tries to close the panel.
04-15-2016 04:14 PM
They are Test Methods for IP. So no, I can not share the APP.
The Event X close suggestion is useful. I will have to try it some time. Right now, I have no need for it.
I want to avoid using the ABORT button, and do error processing, hence the queue redirection to Exit State.
Anyway I did do my own testing, and feel like I'm goofing off....