What is the maximum number of globals allowed in one global file?

[road_dog]

I remember there was a limit discussed in a LabVIEW class, but I can't remember it. But I know I exceeded the number on one project and VERY WEIRD things happened. Does anybody know this number?

Thanks Much

[mikeporter]

If you are writing code where this sort of limit is an issue, you have a lot biggers problems on your hands than what the limit is...

Mike...

[tst]

I don't know about such a limit, and I think that if there is one, it will probably be high (255?) ,but to expand on what Mike said, using globals is prone to race conditions and bad memory performance and using a lot of globals is prone to a lot of... (you know the rest). The very weird things (what are they?) are probably the result of a race condition. Maybe that class you attended wasn't that good.

There are various ways of passing data between VIs, the best of which is by creating proper inputs and outputs for your VIs and using wires to pass the data. If that isn't possible, you should group the data in logical groups which you can pass together and not pass each control on its own. Another way of minimizing memory hits (and make it somewhat easier to control race conditions) is using alternative global variable approaches, like the LV2 style global. In short, you will probably need to restructure your application to make it easy to work on and to get it to work right.

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

If you want any more help, you should give more details, like what are the weird things you see, what is your application supposed to do, how much experience you have, how big is it and so on. If it isn't too big, I suggest you save the files as an LLB (File>>Save With Options>>Development Distribution) and post it here.

[Ben]

I Second the previous commnts.

I believe in LV 6.1 and prior there was a limit of 550 controls on any front panel. I believe that would cover the teh globals as well. (No, I did not write a VI with 550 controls, but one of my customers did!).

The other limitation had to do with the nesting of cluster elements. It was a bizarre condition but had to do with the total number # of characters invloved in nesting of cluster objects. eg cluster.element1.sub-element_A.sub-sub-element... had to be less than thansome large number. I believe this was the thread where Rolf Kalbermatter wrote something like,

"Once all of your physical memory is filled up with a single cluster, your application is probably going to suck!?

Please forgive me if I miss quoted.

Ben

[mikeporter]

If you can explain a bit more about your application, we can help you sort out the structural problems in the code that make the global size limit appear to be a problem. There is never a good reason for using a huge number of globals--regardless of how they are arranged.

Mike...

[tst]

Ben, your quote is accurate (look here).

I also remember seeing that 550 number somewhere as the top limit for the number of controls (although I think it was 555, actually).

Anyway, I just tried in 7.0 and had no problem with considerably more than 550 DBLs, both in a VI and in a global VI.

[JeanPierre]

The type descriptor (TD) of LabVIEW data is limited to nearly 64K bytes since the length header is 16bit. The control name(s) and typedef control name(s) are included in the TD. The Front Panel of a VI/Global has the TD of a cluster embedding all its controls and indicators. Even with short names, you can't expect a FP/cluster to hold more than a thousand controls/indicators, since the length of a control TD is 4 bytes minimum + name length. I think that the bundle/unbundle nodes are themselves limited to 255 inputs/outputs (yes I tried once).

Fortunately, you can use as many Global VI as you need if one is filled :tongueincheeksmiley:

That is for your information only, don't try this at home or at work. In any case you should avoid to use such an amount of globals on the same VI or many VIs. Encapsulate your data into logical sets and design VIs dedicated to managed these sets. That makes your application well structured, easily maintainable and reusable.

[tbob]

I think you all scared Road Dog away.  Globals don't have to be bad.  When used as constants, there won't be any race conditions, and it is a great way to share the constants across vi's.  One great example is to use globals to hold the various addresses of test instruments and aliases (GPIB/LAN addresses, port numbers, device numbers and aliases).  These are setup once and never written to.  In the RF world, globals can be used to hold calibration constants, even though they will usually be written to at least once.  A calibration program is run and the cal factors are written to globals.  Then when the real test program is run, all vi's have access to the cal factors through the globals.  In this case, only the cal program writes to the globals, and it is usually before anything else is run.  The test will only read from the globals, hence no race conditions.  I wish the people on this list would explain race conditions and educate the newcomers on proper use of locals and globals rather than just tell people to avoid them like the plague.  Locals and globals are used extensively in text based languages.  Text programmers learn about race conditions and how to avoid them.  Globals and locals are very useful if used properly.  Education on proper use is a much better approach than a blanket avoidance.

[Ben]

HI Tbob,

You are going to earn the title of Global Enthusiast if you keep this up

Race conditions are to Globals as Venerial deseas is to sex. If you want to avoid the former then abstain from the latter.

Yes you can use globals.

In fact, I ran a benchmark comparing how fast I can read a global booean vs the same coded as a LV2 global. The Global booean was 6 (or was it 16?) times as fast.

When answering Q's that use phrases like "strange things" we bring up the race condition and point users to LV2's.

Sure text based programmers learn how to handle global access in multi-threaded environments. These types of interaction are implemented by making the global a protected section that are protected using semaphores. This same approach can be used to protect LV globals. Just ensure all reads and writes of teh globals are only done after acquiring the semaphore that protects the global. If you did thisfor all accesses to the global you would not have race conditons with globals.

Unfortunately this is a lot of work because now you have to deal with creating acquiring releasing the semaphores and this has to be done for each value you need to protect from simultaneous access.

Now if there was an easier way well then....

BUT THERE IS!

It turns out that when a VI is not reentrant (like in a LV2) LV implements a scheme that prevents simultaneous execution of the VI. So by using a LV2 you pick-up the resource locking with ZERO EFFORT!

So being lazy, I use the method that is imune from race conditons from the very begining. That way when my customer asks "Can I manipulate the cal values from any of the machines on the network?" I can say "YES, that was functionality is supported by the design".

I could not say that if I implemented the cal via globals.

So that is why I push LV2's and and discorage globals.

Ben

[tbob]

Ben, I am not advocating the use of globals or locals.  I am advocating proper programming.  If I had a case where I wanted to read and write to something, I would also try to avoid locals and globals, and use the LV2 style.  I was merely pointing out that globals and locals do have a place (used as constants, for example).  In the RF world, I would not want anyone manipulating the cal factors.  That is a sure way to allow a bad unit to pass.  The cal factors can only be changed by the cal program, and even that is protected so that only certain people can run it.  I deal with medical devices, and passing a bad unit can result in death.

I still say that globals are great for holding constant values like GPIB addresses and instrument aliases.  There is no chance of race conditions here, none at all.  Globals used as such are safe, faster, and a lot more convenient.  So why not use them in this manner?

Your key words here are "discourage globals."  I would also discourage globals unless used as constants.  But to "avoid at all costs" is just simply not good advice.  It really all depends on the usage.  Just like sequence structures.  People use them when they are not needed, but there are some times when they are necesarry.