LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget 04/23/2007

While I admit I have never thought of using constants in LabVIEW before now.  Reading through the discussion I get the feeling this is not the way I would have handled this.  After thinking about it (please provide constructive feedback) I think I would have tried a blank variant in a VI.  This single variant (lets call it CONST) could house an attribute for each constant that you need.
 
Reasons:
> Adding new constants or setting values could be made through helper VIs for easy readability.
> Since a variant can house any type of data you have also have a constant of any data type.
> The Set Variant Attribute VI already facilitates checking over writes (replaced is TRUE if an attribute and value were replaced).  It would be simple to check this output and, if set to true, set the error out cluster...
 
Of course this means you would have to explicitly initialise it with a list of constants at run time though... hmm
0 Kudos
Message 31 of 39
(3,853 Views)

The problem with using variant attributes is that the value is a variant instead of being strictly typed and that you need to use strings as the attribute names. You can get around this by creating a wrapper for each constant, but then it would be much simpler to simply create the VI.

As mentioned, no currently available method is really suitable. The best contender is the subVI const, but those are annoying to create if you have a lot of them. My initial suggestion was a way to get around that annoyance by paying in other areas. If you want security, you can't really use a global as a const, because another developer could decide to write to it, but I think this would be an acceptible risk under certain conditions (although it still far from an optimal solution).


___________________
Try to take over the world!
0 Kudos
Message 32 of 39
(3,836 Views)
The message edit screen is NOT working!
 
What if we scripted the sub-VI generation based on a dialog?
 
 
 
But how would we easily find and manage them once they were created?
 
Ben

Message Edited by Ben on 05-01-2007 06:57 AM

Message Edited by Ben on 05-01-2007 06:59 AM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 33 of 39
(3,829 Views)


@Ben wrote:
 
What if we scripted the sub-VI generation based on a dialog?
 
But how would we easily find and manage them once they were created?
Tomi already suggested that and I agreed that creating such an editor is basically a good solution.

I don't think there is any need to manage them after they were created, because I would simply create all of them in their proper place in the file hierarchy. Then, if you need to change one, you just go and find it as you would any other VI.

Basically, what I do think is the hard part about this is getting a proper icon for each subVI.

___________________
Try to take over the world!
0 Kudos
Message 34 of 39
(3,787 Views)
It was already mentioned but SubVIs as constants can have more functionality. For example, in OpenG Toolkit,  subVI path constants are allways provided  with a relative path input for path building. It makes sense since a path constant will most of the time be used with the build path function.

If the constant is usually multiplicative (like Pi) it is more useful to have a Multiply by Constant SubVI rather than a simple constant output. 



LabVIEW, C'est LabVIEW

0 Kudos
Message 35 of 39
(3,368 Views)

One question here: why can't ring constants be used? They give you a name you can select and several values can be bundled together. If you put the ring constant into a typedef you can configure a nice package of data. The only thing missing is making the typedef constant(?).

Of course then you cannot programmatically change the output of your constant - but then it's not a constant either, but a function (?)

 

0 Kudos
Message 36 of 39
(3,279 Views)

The main reason for not using rins is that their value is limited to the integer data types and often you would want your constant to be of other types.

Also, rings do not play as nicely with case structures as enums do.

They do have their advantages, though, and you can use a typedef ring constant. To get it to update its values when you update the typedef, you need to change the data type of the typedef. You can do this by changing its representation and then changing it back. Be sure to use a representation of the same number of bits (or preferably higher) to avoid losing previously configured values.


___________________
Try to take over the world!
0 Kudos
Message 37 of 39
(3,264 Views)

Well, after 15 years I have to ask: Do we have any "official" method to create constants in LabVIEW?

If not, are the Global Variables or subVIs still the recommend solutions?

0 Kudos
Message 38 of 39
(781 Views)

@mthheitor wrote:

Do we have any "official" method to create constants in LabVIEW?

No.

 

I don't know about recommended, but those options still seem to be the most practical. In practice, it seems relatively rare that I actually need this functionality.


___________________
Try to take over the world!
0 Kudos
Message 39 of 39
(747 Views)