How to change many instances of diagram constant in different vi's?

[crossrulz]

FYI, the Space Constant is an inlined VI that is nothing but a constant wired to an indicator.

I have personally made the argument for a Global Variable being used for a constant.  But another coder can write to that value and completely ruin it.  So I tend to use the GV path for configuration "constants" where I read a configuration and write the variable only at start up and then everybody else can just use it.  I could probably do something like make the GV private to a library and then make an inlined VI that just reads the GV to really keep other people from writing to it.

In this case, I would probably also go with the inlined VI.  The inlining makes the compile code of the subVI part of the compiled code of the calling VI.  Optimizations can be done by the compiler from there, likely including constant folding.

[JÞB]

Certainly you can use the find and replace all limiting the search to text in block diagram objects.  I even did that once and developed a new cosmetic style for numeric constants.

Of course, I should have used a global variable!

If you are seriously worried about making the write idiot-proof, create a library with a global.  Wrap the read and write methods in inlined Accessor vis and keep the global and write vis private. Pack the library! Then nobody can change the value without rebuilding the lvlibp.  A little creative editing of the read.vi's Icon and / or label (display name) should even indicate the protected value!

You would need a very knowledgeable idiot to mess that up.

[Mark_Yedinak]

I was recently burned by an inline Vi which makes be a bit nervous using them now. This was in LabVIEW 2018 and I think the issue was some strange compile error. Anyway, I had an inline VI that was just reading a value out of a DVR. It was an accessor method in a class.  This had been working fine for quite some time and then I had to release a new version of code with some changes. The changes were completely unrelated to this class and were made in other parts of the code. Anyway, I build the executable and begin testing and stuff starts failing. Digging into further I come to find that the inlined VI (accessor method) is returning garbage data. I verified it was being initialized correctly and the magic fix was to simply uncheck the inline online on the VI. It took some time to ferret out this issue but since then I have been cautious with inlined VIs.

[JÞB]

A read global to terminal will inline to read global to wire.  Blazing fast as a global read without exposing a global write outside the ppl.  And zero potential for the memory manager to move the data value location.  I do seam to recall a bug involving stale DVRs in inlined vis until forcing call chain recompile.  This was resolved to the best of my recollection.