LabVIEW
How to change many instances of diagram constant in different vi's?
Solved!
If the constant should not be a constant you need to find a different solution. For example you could read the desired value from an ini file and put it in a global (plain global or state machine), then read that value wherever needed.
It really depends on a lot if things. Maybe it should be a control input for all subVIs so you can change it even during the run.
This is a more subtle version of using duplicate code in different places, then trying to find each instance and making the same change to all of them. In this case, these are duplicate constants that you need to change.
To avoid this in the future, have the value in one place where all the different VIs can access it and you only need to change it in one place. This is one of the few times where a global variable is appropriate. There are many other ways to skin this cat as well.
@santo_13 wrote:
What I would do is create a VI containing constant wired to indicator. Now use this VI at all places where you use the constant. Now when you want to update the value of the constant, go inside this single VI and update it, every instance of this VI will be updated to the new value.
You can set the VI to inline for best performance.
Does this execute faster than wiring a global variable? Does inlining the subVI make it just as fast as if it were placed directly in the VI since it's part of the VI now? Is it more memory efficient? Is it just a preference to avoid global variables? Seems to me that a global would just reference a memory location while the subVI is extra code. Just asking so maybe I can take advantage of a different way of doing things.
@santo_13 wrote:
I have not done any benchmarking against Global variables, but by default, I seldom use Globals. Moreover, there is no control if some developer opts to writes data to a Global Variable that was meant to be a constant (and you've to write the constant value to global at some place).
In theory and my understanding is that inlining the VI will make the content of the VI become part of the caller which is as if the constant was directly placed in the caller VI and compiled. This way, it will always be faster than reading from memory as the constant is already part of compiled code.
I extensively use this technique which is similar to the const keyword of C programming, to use the same constant across VIs similar to how you typedef ENUM to be used across all callers.
That's the second time I've read about being afraid that users would change the values. Why would the global ever be exposed to a user in the first place? Unless you are letting the technicians run source code, which would never, ever be allowed where I work. I would be more concerned about someone changing the source code than changing some global values. On the other hand, with globals, it is very easy to make the jump from tweaking values in a global to reading from a config file into those globals.
Now inlining does make sense because, as you said, it becomes part of the VI itself. I guess this results in constant folding?
@santo_13 wrote:
A typical scenario for using the VI based constant will be mostly in the source code where the end-user need not change or require changes after building them. In my line of work, we use source code extensively and engineers use the test automation, in this case, it is fine to edit the VI instead of having a file read/write feature.
If the requirement is to store settings, it is not a constant and cannot use the VI based constant, instead, it will turn into an LV2 Global VI to store the settings.
Oh, so different usage cases. The software I write is strictly for production use and it is forbidden to change anything. Using FGV in the manner described above just makes it an extremely slow global. But if you actually meant "AE" where actual calculations go on and you need to make sure they complete before anything else asks for the data - that's different.
