LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to store constants

I'm working on a set of drivers that call functions from a DLL provided by the instrument manufacturer.  They have an extremely detailed manual, which has been very helpful.  When they describe the functions (and the different values I can pass), they use named constants, and then at the end they define the value of each constant.

 

This sort of thing works great in a text-based programming language: just assign the appropriate values to the constants at the beginning and you're ready to go.  But what's the best way to store these constants in LabVIEW?

 

My initial approach was to use (strictly typedef'd) text rings (or occasionally enums): the constant name was the text string, and the numeric value was the value of that string.  The problem is that they occasionally have multiple constants with the same numeric value, and LabVIEW doesn't let you have duplicate values in a text ring.

 

The thing I really like about using text rings is that this way, I have all of the values at hand to use in a control or a constant; I just plop down the appropriate text ring and select the constant I want.  It's also easy to keep consistent across all of the VIs in the project, since it's a typedef.

 

But...since it looks like this won't work, at least not completely, what's the best alternative?  Enums wired to case structures that pass out the appropriate value?  Dual arrays, one with the constant name and the other with the value?  Something else?  The downside is that all of the above need some sort of wrapper VI, but I can't think of a way around that.  What would you do? 

Message 1 of 14
(13,964 Views)
I'd like to know this too.  Sometimes I just assign constants to hidden controls at the beginning of my VI, and use local variables to represent the constants, but I'm sure there's a more elegant way to do it.
0 Kudos
Message 2 of 14
(13,942 Views)
The only time I use global variables is to store scalar constants.  I have a single global variable with many different constants, so it has the text ring feel to it.  No race conditions since you will never write to it, right? (only enforced by the honor system).  If you need array constants, or are allergic to globals I'd suggest using a functional global.  More of a pain than it should be with the wrapper VI, but using them should become second nature to you.
0 Kudos
Message 3 of 14
(13,927 Views)

It's also easy to keep consistent across all of the VIs in the project, since it's a typedef.

 

Unlike an enum, the ring's data isn't really part of the typedef. If you drop a (strict typedef) ring constant on the diagram, the data is only up-to-date as of when the constant is dropped on the diagram; it isn't dynamically updated to reflect changes in the data of the underlying typedef. (And of course anything goes with non-strictly typedef rings, where you can set the strings at runtime.)

 

 ring.png

 

As for the best solution, I don't know. Despite the above problems with rings I have still used them for this purpose since usually the definitions don't change with time. Your idea of using an typedef enum + case statement in a VI seems like the safest approach for constants that can have duplicate or nonconsecutive values.

Message Edited by Rob Calhoun on 08-25-2009 02:52 PM
Message Edited by Rob Calhoun on 08-25-2009 02:54 PM
0 Kudos
Message 4 of 14
(13,921 Views)

The two array constant way works good with a search. You search the string array and index the number array. Throw a error if not found (search gives index -1).

 

You might want to simplify your life by writing a parser vi (propably they give you some header (*.h) file. After parsing you just convert the indicators to constants and voila. You could also use a text ring control and use the Strings[] property to fill it, laterconvert it to the strict type def.

 

Felix

0 Kudos
Message 5 of 14
(13,917 Views)

Nice inputs so far.

 

My approach to this type of problem is to not store the constants in LabVIEW at all.  The problem, restated, is how to associate a name and a value (of indeterminate type?) right?  Config files work well for this! just let the key:value pairs associate your data.

 

Ex of 

Equip_A_config.ini

 

[Constants]

Low=1

Med=5

High=10

Default=5 .....etc....

 

[Power on State]

Reset=True

ID=True

Address=COM5...etc...


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 14
(13,893 Views)