application configuration constants

[zeeed]

Coming from C++ and C I'm used to dedicating a place in an application, where important constants are #define'd (=named) and can then be referenced in the rest of the application.

With LabVIEW, I couldn't find an immediately intuitive way of doing that.

Here's what I thought about:

• creating a VI with globals so they can be referenced => it appears the values aren't saved with the VI
• creating a set of named constants somewhere in the corner of the main VI => they can't be referenced with local variables
• creating a bundle with named values => requires clumsy unbundling every time the value is required. 

How do you guys do that?

I'm looking to store stuff like buffer sizes, interface specificiations, data id => name associations and the like - stuff that does NOT belong in an .ini file.

Thanks!

zeeed

[Javed_H]

Hi Zeed

One way to appoach this problem would be to store the values of the globals in the config files. Whenever you run the VI, you can load values in to the Global variables from the file.

Regards

Javed

[Mark_Yedinak]

---

@zeeed wrote:

Coming from C++ and C I'm used to dedicating a place in an application, where important constants are #defined (=named) and can then be referenced in the rest of the application.

With LabVIEW, I couldn't find an immediately intuitive way of doing that.

Here's what I thought about:

• creating a VI with globals so they can be referenced => it appears the values aren't saved with the VI
• creating a set of named constants somewhere in the corner of the main VI => they can't be referenced with local variables
• creating a bundle with named values => requires clumsy unbundling every time the value is required. 

How do you guys do that?

I'm looking to store stuff like buffer sizes, interface specifications, data id => name associations and the like - stuff that does NOT belong in an .ini file.

Thanks!

zeeed

---

Why not use an ini file? You can make this a private ini file that the user cannot modify by using encryption. It is useful to have these values stored outside of your actual code. That way it is very easy to modify the application's behavior without having to modify the code.

Also, clusters are a preferred method for passing data through an application. Globals should be avoided. Although if they are effectively read-only values than you will avoid race conditions. However clusters are preferred because they add to the readability of your code. LabVIEW is a dataflow language and it uses the wires to pass data through the system. If you simply are looking to avoid using an unbundle this is a poor reason to keep things as individual elements. If you wire them through your code you can end up with tons of wires. Of course you should bundle only related elements. Superclusters (a cluster containing everything under the sun) is not a good design approach either.

Another approach you could use would be to create a LVOOP class (LabVIEW OOP) which contains your global data. You would use methods to access the elements. This gives you a clean API and also allows you to include things such as data validation within the methods.

In any language global variables are generally a bad design. It makes code much less modular and makes it easier to introduce bugs. It is likely someone would not realize all the places a global is used and can make a change which us undesirable side effects. You are generally better off to pass values into to subsystems rather than rely on global values. This keeps the design clean and more maintainable.

[SimonH]

zeeed,

The closest analog to C/C++ would be to use controls that are either hidden (right click on them and select hide) or moved offscreen.  You can then reference the values with wires or local variables.  That being said I highly recommend that you do NOT do this.

Dataflow is the dominant programming paradigm in LabVIEW and it forces you to think a little differently to procedural languages. The way I, and many other LabVIEW users, handle the need for global (or similarly largely scoped) data is to include it in a type defined cluster and store it in a shift register in the main program loop.  

This makes the data available to every part of the program I deem it appropriate for (as I only pass the relevant parts of the cluster to each subVI).

There are many benefits to this approach:

1. Generally the LabVIEW compiler is able to generate much more memory efficient code when you use shift registers and wires as opposed to controls and local variables.  Using front panel controls to store data that isn't actually necessary for display can cause needless memory copies and thread swaps.
2. You reduce the likelyhood of creating hard to debug race conditions.
3. The cluster can be easily passed to subVIs.
4. Using a type-defined cluster gives you a single point of modification if you need to rename or reorganize your data items.
5. It scales better than named local variables.  Once you get lots of named controls using local variables can quickly become unweildly as they are always presented as a flat list of names.  With the cluster approach you can create clusters of clusters if you need heirarchy.
6. For me it's more readable -- the unbundle by name nodes let me know exactly what data is being accessed where and the wire lets me follow where data access may be occuring.
7. This is the way you work with LVOOP if you ever want to do any object oriented programming in LabVIEW the transition becomes much easier.

Of course if one solution worked in every situation we wouldn't need programmers any more would we?  Let us know if you have any other questions, we're happy to help.

~Simon

[aeastet]

For this I would use a strict type def or an action engine to hold my important values that you want to get to. I would then set the values of these in an INI step in the state machine. If you need to load them from a file you could still do this using an ini file and the action engine.

[Wetzer]

Hi Everyone,

i agree with Tim, i would use Typedefs and Default Vaules for this purpose.

Regards!

Moritz M.