LabVIEW
Is it possible to change indicator/control depending on enum?
Solved!
@jdepypere wrote:
Now that I'm at asking simple questions - say I have a led and I need to set/get the values in multiple places.
If the LED is only used as an indicator, writing to it from many different places can potentially lead to confusion, because these writes can occur nearly in parallel and the indicator value is unpredictably dependent on whatever code segment wrote to it last. What good is an indicator if it sends mixed messages?
If the code is correctly architected as a state machine, you could connect it after the main state case, each state outputting the desired value. No local variables needed because all states re-use the same terminal. If you need to communicate a status to other states, you would keep the LED value in a shift register so it is available at all times. Correctly written, a programs rarely needs local variables. Exceptions are user interface functions where you need to programmatically set the value of a control, or in certain cases where parallel tasks need to share information (In the latter case, there are plenty of other, potentially better ways, though).
Programmers with a heavy text programming background tend to use hidden indicators and plenty of local variable in the same way they used variables in text based code. That's not good LabVIEW programming, because it leads to potential race conditions and also forces extra data copies in memory (not a big deal for a boolean, but a problem with large arrays, for example).
@jdepypere wrote:
Is it advised to use solely local variables from the led, thus leaving the original led linked to nothing in the diagram, or is it better to always have the original led linked up somewhere as well? Or does it not matter and is the second method better for cleaner code?
You should never have a disconnected terminal, it should be connected in the most central location. This way searching for the terminal, by e.g. double-clicking the control instantly leads you to the most relevant code location.
@jdepypere wrote:
I presume it doesn't really matter, and that setting the LED var instantly updates all the local variables (thus no race-conditions occuring), but ofcourse I'm not sure...
What is a LED "var"? Define "instantly"! Front panel updates are asynchronous, so the LED value is also kept in a transfer buffer.
A race condition is a function of code architecture. If the LED is used purely as an indicator, the code does not care. You seem to be also reading the value elsewhere and in this case the value critically depends on the relative timings of independent code segments. Of course if you try to avoid that by sequentializing the code with a liberal sprinkling of sequence structures, you again end up with overly complicated and inefficient code that cannot take advantage of multiple CPU cores..
