Community Nugget 04/23/2007

[GReaper]

Thanks for the input all.

I din't think I have any INI issues (say that 3 times fast) because I have default values set using the Read Key VI.  I think I also avoid race conditions by only setting the values via a menu File/Print Options route.

That said, I think the subVI would give me better control and make them self initializing (per that shift reg route) and I could build in a lot more error control to getting and setting.  Setting in particular.

Cheers,

[tst]

Yet another advantage of using a subVI is that changing a value doesn't require to recompile all the VIs calling it (this is even more important if you use source code control).

We've already established that this method has a lot of issues, but I still think it has its place, and would have it even more if we had the Global Constant VI.

[PaulG.]

Good points, but I disagree. Globals are EVIL! The only problem with your solution is that the use of globals ALWAYS (the way I understand it) involves going through the GUI thread, effecting performance. Could you not create a typedef control/constant with the wanted values set to default? This way you would use the constant and never have to use a global - ever.

[Ben]

Paul wrote;

"

Globals are EVIL!

"

I agree!

"

The only problem with your solution is that the use of globals ALWAYS (the way I understand it) involves going through the GUI thread, effecting performance.

"

False. They affect performance because they require copies for each intance.

"

 Could you not create a typedef control/constant with the wanted values set to default?

"

Typedef'd constants on diagrams do not get updated when the default changes.

Ben

[Tomi_Maila]

Hi all,

I've a proposal for an OpenG project that may help lives of all of us.

1. Let's create constant subVI VI templates for the most common datatypes consisting of a value constant and an intigator connected to the only output terminal of the subVI. I attatch an empty contant subVI template to this post (LV 7.1)
2. Let's place these contant to two different places
1. To Templates\Constants folder under LabVIEW installation directory for each version of LabVIEW. This way the constants can be created by selecting New... menu item in LabVIEW.
   
2. To subfolder user.lib\_OpenG.lib\constants folder as Merge VIs. Dropping a Merge VI from palette to block diagram will actually drop the content of the VI on the block diagram. As our constant VIs consist of a constant and an indicator, dropping such on block diagram will actually place a constant and an indicator to block diagram. This will be an alternative way of creating constants based on the same templates.

Tomi

[crelf]

---

PaulG wrote; "The only problem with your solution is that the use of globals ALWAYS (the way I understand it) involves going through the GUI thread, effecting performance."

Ben wrote: "False."

---

This has been discussed several times before (for example, here and here), and whilst the quasi-official word is that they don't execute in the UI thread, I still don't beleive it - no one has been able to tell me when this behaviour chaged (I know that they were in the UI as late as LabVIEW 6.1.1).  Call me a skeptic, but I need a link to an official release note to beleive it.  As far as I understand it, this snippet from NI's website (from an article called "VI Execution Speed") still suggests that thread swapping occurs:

How Multithreading Affects User Interface Actions
When you write to a local or global variable, LabVIEW does not switch to the user interface thread immediately. LabVIEW instead writes the value to the transfer buffer. The user interface updates at the next scheduled update time. It is possible to update a variable multiple times before a single thread switch or user interface update occurs. This is possible because variables operate solely in the execution thread. Functional global variables can be more efficient than ordinary global variables because they do not use transfer buffers. Functional global variables exist only within the execution thread and do not use transfer buffers, unless you display their values on an open front panel.

[Ben]

Hi Chris,

I have to keep reminding myslef what executes where and under which version.

Reply # 35 of the NI link brings it all together in the context of history.

So I still think the answer is "False".

Ben

[shoneill]

Well, isn't it relatively easy to block the UI thread with window movements and the like (or a dialog box).

If the globals are still updated while the UI thread is blocked, then surely they aren't in the UI thread.

I may be missing something here, but isn't an action in the UI thread relatively easy to find (Oh man, I hope I'm not opening a can of worms like the in-placeness of clusters!)

Shane.

[Albert.Geven]

As a first template it is ok,
But I prefer a template where the output is already connected to a terminal

My question is, do we need errorin/out for eventual synchronising
my first feeling says no, but maybe we need sometimes more than one output (e.g. inifile missed )

So let us start with a 4/4/4 terminal pattern.

[johnsold]

I like the indicator in a VI with an 8x8 pixel icon on a small connector pane. I think Ben mentioned this in a posting a few weeks back. This requires minimal diagram space.

Of course if you want error clusters for data dependency, a larger icon is required. I don't see the need for those on a read only global.


Lynn