LabVIEW
Best practice Reference node or FGV
Hello!
I have a question about the best (clean) way to acces of the value of a control/Indicator at different point of a program :
I have a control (cylce_en_cours) who is write at two other point in my program.
I use the property node "value" to read the actual value, use and uptade it in a subvi (TS_IHM_Cycle_Number_build.vi) and an other property node to write the value:
I use this "method" at other point of the program (for example here with Skip_on_test failure indicator).
Is it a good way to proceed or not?
I can use fgv but it need a vi with a read or write input parameter and at least i will use a property node to write the new value ...
thank you so much for the advices !
I'd prefer a reference value by wire over a global resource anytime...
It depends a lot on what your situation is though. Some people love FGVs, and they are not wrong per se.
As I see it:
Upsides:
FGV: care free access
Wire: you can follow the wire
Downsides:
FGV: can be accessed anywhere
Wire: you have to pass by wire
FGVs can be a very fast way to build your application. It can also ruin any change to scale up your application or reuse parts without coupling to everything.
From a functional programming PoV, a global (any type) is a side effect. Code with side effects is harder to test. Anything by reference is also a side effect though. But the global has state and is by reference. Consider writing a test. For the reference, you make it point to something deterministic, and pass it, run the VI. For a global, make something deterministic, put it in the FGV, run the VI while forcing sequential ordering. And hopefully, nothing else is using your FGV while running your test.
Search LabVIEW like a graph! 
That's a pretty common solution, but kind of ugly. Don't use Controls as data sources/storage, keep data in e.g. a cluster (that can be a FGV, class or just a wire). I see you already use a cluster, just store the data in it. 🙂
As to writing it back, just update the cluster or send an event or queue up an update (you'll of course need some event structure/queue in your GUI VI to handle that).
The easiest if to simply read/write the cluster and have a e.g. 40ms main gui update interval.
@vincent69 wrote:
thank you so much for the advices !
We could give significantly better advice if you would attach your code so we can see context.
Are the references to controls on the same VI or on a different VI?
Is this a reference to a control or indicator?
Is the referenced control directly on the front panel or e.g. inside a cluster?
So. Many. Questions!
Property nodes typically execute synchronously and require a thread switch so if your code is peppered with many (we already see four!), performance can be impacted.
What else is in that cluster? (I recommend a cluster of values instead of a cluster of references and keep the cluster in a shift register, then read/update values as needed.) Front panel objects are for the user, not for data storage.
Please carefully read the advice by Yamaeda above.
@Yamaeda wrote:
That's a pretty common solution, but kind of ugly. Don't use Controls as data sources/storage, keep data in e.g. a cluster (that can be a FGV, class or just a wire). I see you already use a cluster, just store the data in it. 🙂
I was assuming the control was read to get user input, and written to set a filtered value. Misuse didn't even occur to me...
Why else indeed would you read\write to\from a control?
Storing data in any user interface element is bad.
Assuming that these are indicators (You don't really want to fight the user by writing to controls. If input validation is needed, it should be done higher up, e.g. by using an event structure).
Here's how your code skeleton could look like using my suggestions. Of course you can have an unlimited number of items in the cluster, even the orange value. The nice thing with (un)bundling by name is that the code becomes automatically self-documenting as long as you name the cluster item reasonably.
@altenbach wrote:
Assuming that these are indicators (You don't really want to fight the user by writing to controls. If input validation is needed, it should be done higher up, e.g. by using an event structure).
That code could be in an event structure...
As you pointed out, we don't know.
A time out is usually somewhat of a last resort.
If there are events where the control needs to be updated, by all means use a local, value signaling or value property.
If almost all events require the control to update (it is starting to sound more like an indicator) you can put the update in the event loop before the event structure (not after, you'll miss the update on start).
The time out trick is a hack because you'll always be updating even if it's not required. There's a flip side too: if you keep getting events, you'll get no updates. You'll notice this when you add a mouse move event. Keep moving the mouse: no time outs, no updates!
@vincent69 wrote:
using the timeout event of the envent structure is ok ? (with a 40ms time base for example) or it's beter to generate a user event "update" and send it each time i modify the "ihm memory cluster" ?
As Wiebe said it's a slight hack, but it all depends on your structure and requirements of your code. If it's a mainly passive program (without mouse move event as Wiebe mentioned) it'll work fine.
Update your indicators in the main VI and only in 1 place (i think of it as "noone but 'me'/thisVI changes stuff in this VI). If you take measurements some 'levels' down, wire out the result up the structure so you can wire it directly to an indicator in the main vi. In this case sending the data as an event or queue is acceptable and in large systems often needed, especially if you for some reason want to update an indicator from several places (e.g. send info to a log window).
