08-25-2009 12:24 PM
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?
08-25-2009 02:07 PM
08-25-2009 02:37 PM
08-25-2009 02:50 PM - edited 08-25-2009 02:54 PM
> 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.)
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.
08-25-2009 02:52 PM
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
08-25-2009 04:23 PM
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...