Community Nugget 04/23/2007

[tst]

---

@Tomi M wrote:

To subfolder user.lib\_OpenG.lib\constants folder as Merge VIs.

---

I don't understand that one. The whole point of a const is to be the same everywhere. Using the merge function will simply drop a literal constant.

Your first suggestion sounds like a potential step in the right direction. Perhaps writing a toolkit to assist in the generation of constant VIs (name + icon + documentation?) would make it easy enough?
Personally, I find that the hardest part is the icon because constants can have long names and an icon doesn't have a place to conveniently hold the text.

Albert, I think a constant should be a constant, not a loadable resource. As such, it should have no possibility for run-time errors and should not be dependant on the data flow. It should simply return its value. I understand the usefulness of error handling, but that simply would not be a const.

In this case, I can return to my optional implementation of having the constant VI have a block diagram and forcing it to execute when it loads. There are issues with that, though.

As a side issue, if I understand correctly, there is no real need for a change to a global VI to cause a recompile to all the VIs calling it. If a global variables has two numerics (A and B) and I multiply them in another VI and I then add another numeric (C), the VI using A and B should not have any real reason to recompile. Yes, the list of options changed, but the selected options did not, so that's an editor issue.

[Albert.Geven]

Hi Tst

I agree that dataflow is never necessary for a constant, but a loadable resourec may give extra information.

and afetr thinking twice a 4/4/4 connector has no way to have a central output, anybody better suggestions.

[falkpl]

To emulate the CONST keyword a simple vi with a single value waire out will do.  The file I/O allows it to be a reconfigurable constant (not a true constant but very convienent).  The most important aspect of a constant it that it is fixed prior to execution.  the const keyword will makes the value of the variable read only.  Maybe in the future there will be a read only flag for variables.  As for icons being too small to capture the meaning of the constant, you can always use the lable of the subvi for more space.

[DFGray]

If you have a newer version of LabVIEW, and can tolerate the security/recompile issues already mentioned, the network shared variable makes a great constant.  It outperforms the global, in some cases, if it does not change.

However, I prefer subVIs for constants and single-element queues for things which will change.  The control freak in me does not like the idea that someone else could mess with my data.

[Ben]

"The control freak in me does not like the idea that someone else could mess with my data."

I can relate to that. I'll often put error checking into my sub-VI that clearly "blame" the caller if misused.

Ben

[Steve.Briggs]

It's always nice to come back from a long break and read up on the importance and discussion of globals.

**Breathes a sigh of relief**

[crelf]

---

@Ben wrote:

Reply # 35 of the NI link brings it all together in the context of history.  So I still think the answer is "False".

---

I'd still really like to see the relase note that tells us when this changed.  I'd also like to see some more technical documentation, rather than just a post in a forum (no offense to JLS - but this is an extreeemly important point that I'd like to see officially clarified once and for all).

[Gabi1]

Hello all

this thread has been very interresting to me.

however, several issues: to my understanding, global variable are a viable option, also to keep constants. but not only. imagine a situation where a caller routine wants to add an input to a way under first layer subvi (far down in the tree). transfering this variable trough all caller subvis isn't an elegant option at all. the utilisation of global then become necessary. the only question: what is the value of the global before actually writing to it? only "make current value default"?

that lead to my second tought: is there a way to tell labview to automatically make value defaults everytime one closes the VI? i am talking of the main vi and not the subvi called, which can be saved using a method call.

Thanks guys

[Ben]

Hi Gabi1,

Please see teh Action Engine Nugget for an alternative to globals.

Ben

[Gabi1]

Ben i have just read about type def along with AE...

this is really too bad i didnt read that 2weeks ago. i built up an enormous piece of control system, in which i had big trouble keeping my data type trough all subvis (especially each time i decided to change some of it in my clusters...).

well, good to keep in mind tough. those are very nice nuggets you delivered. Thanks