LabVIEW
Dr. Damien's Development - Setting Front Panel Controls
LabVIEW 6i introduced control references to allow programmatic control of controls and indicators. Part of this interface is the Value property, which allows the user to set the value of a control or indicator from a location not in the original VI. Unfortunately, this process is slow, since it is a synchronous process. The value of the control must be fully updated and displayed before the property node returns and allows execution to continue. Is there a faster way to do the same thing? Yes!
There are VI methods to set and get the values of controls/indicators on the front panel. Use of these is much faster than using the Value or Value (Signaling) properties. This is because these methods are asynchronous. They set the transfer buffer, but do not wait until the front panel is updated to return. Look for the VI method Control Value»Set in the pull–down list on the VI property node. There are flattened and variant versions. The overhead of converting from a flattened or variant to the actual data type means that these methods are much slower than local variables or using the terminal itself.
Attached is a small project containing benchmark code which sets a front panel control. In the interest of completeness, I have included benchmarks for setting a terminal, setting a local variable, using the VI method, and using the Value property. Performance is in that order, with the first two being almost indistinguishable on my test machine.
Attached code is in LabVIEW 8.2.1 for Windows. The timing functions call into KERNEL32.DLL.
This is great code to have - thanks!
This comes down to "how fast is fast enough?". You have to weigh the benefits of using references. Updating the terminal directly or using a Local requires a flat VI, whereas updating then front panel from a VI nested several layers deep requires references or (yeesh) globals. If it takes a millisecond to update an indicator that pertains to a slow process - such as setting a relay - then I'm all for the reference.
p.s. Don't change your code (not worth it) but one confusing thing is the term "Reference" in the enum. I kept thinking this was setting something by reference, when in fact it is getting the baseline.
My least favorite thing about the Set Control Value method is that it creates fragile code. You must type the control name perfectly to match the label (one of the very few text-based language SNAFUs inserted into LabVIEW's graphical programming). Also, if you change the label of a terminal in a subVI without remembering to change the string into the Set Control Value, you have broken your code without knowing it (run-time failure, versus being able to catch the error compile time).
Finally, for whatever reason, LabVIEW allows terminals - even terminals of the same type - to have the same label. Even empty labels are allowed. This creates an ambiguous scenario where it's indeterminable which control value will be changed by the method (well, I think the control created first is the one to change, but there's no straightforward method for determining which control was created first).
The one scenario where Set Control Value is arguably the best method to pass data is when making Fire-and-Forget dynamic calls. That's why I'm a huge proponent of this Idea, which would all but deprecate the Set Control Val method.
Wow! The snippet renames my controls to be properly unique! Well, here's a screenshot of what I'm looking at. If you test that snippet code, rename all controls to "Numeric" prior to running. And also, change the "This VI" control into a ref constant.
