09-08-2014 05:37 AM
Some people might find this useful, basically its a way of being able to manage lots of constants without having heaps of vis or risking using global variables.
The idea is to use different enum type defs for each data type and then use a polymorphic vi to select the constant and return it.
What you end up with is this
I should add that this is a bit more complicated in terms of setup so only really useful if you have more than 3 or 4 constants of a type. But once it's set up you can copy the vi's and type defs between projects, easily add remove or modify constants and the block diagram representation is very neat and says exactly what it is. I've attached a zip showing the implementation for 2 different types but it can be extended to as many types as you like.
09-08-2014 07:07 AM
@tobyscott wrote:
Some people might find this useful, basically its a way of being able to manage lots of constants without having heaps of vis or risking using global variables.
What's wrong with using a global variable VI for holding constants? They are very efficient and you can store them all in 1 file. And you don't have the complexity of having an enum and VI for each data type.
09-08-2014 07:12 AM
Basically because there is a risk that you (or more likely someone else using your code) write to them and it screws your code up somewhere else. Basically an extra layer of protection. There is some good talk about it here if you haven't seen http://forums.ni.com/t5/LabVIEW/Community-Nugget-04-23-2007/m-p/510961
09-08-2014 07:30 AM
09-08-2014 07:42 AM
Action Engines are fine until you need lots of them, then your project is also littered with vi's, one for each constant. This reduces that number to two for each type, which can quite often be less. Also the code can be modified to implement more actions if necessary (although that kind of defeats the purpose of a constant).
I'm not saying this is the best method, just a viable method maybe some haven't considered
09-08-2014 07:48 AM
Use Worm. One functional global, all variables. I've tried to expand on worm and make a Variant Repository which supports Write Once, reading and writing to disk, type adaption, and it has an example showing how it can be used with a functional global or action engine.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
09-08-2014 12:57 PM
@crossrulz wrote:
@tobyscott wrote:
Some people might find this useful, basically its a way of being able to manage lots of constants without having heaps of vis or risking using global variables.
What's wrong with using a global variable VI for holding constants? They are very efficient and you can store them all in 1 file. And you don't have the complexity of having an enum and VI for each data type.
Agreed. Refreshing to see some of the "Globals are evil" nonsense go by the wayside, occasionally. Seen my share of action engines and god clusters lately.
09-08-2014 12:59 PM
@Broken_Arrow wrote:
Agreed. Refreshing to see some of the "Globals are evil" nonsense go by the wayside, occasionally. Seen my share of action engines and god clusters lately.
I can't seem to find it at the moment but there was an interesting comic that showed begginner using a Global, intermediate using a shift register, advanced using a VIG, and guru using a global again.
You won't find a global (native global) in any of my applications, but you also won't here me saying they should be banned.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
09-08-2014 01:47 PM - edited 09-08-2014 01:47 PM
Hooovahh wrote: I can't seem to find it at the moment but there was an interesting comic that showed begginner using a Global, intermediate using a shift register, advanced using a VIG, and guru using a global again.
I don't remember where it is hiding either. Luckily, I made a copy of it...
09-08-2014 01:51 PM
Oh, the Irony, that's one of mine!