Implemenying Global constants through out a project or module in LABVIEW

[falkpl]

I am looking for the best method for implementing global constants in a project, the method I use now is to make a vi which returns a single indicator value that has been wired to a constant.  This works nicely but it seems like a lot of unnecessary overhead.  I was hoping for a way of performing something similar to a header file (*.h) in c which uses a #define preprocessed directive.  This has no overhead since it replaces the named constant with the global constant value.  A typedef is similar to this but it has the problem that the constant appears as a constant and does not allow for a custom icon to be associated with it.  I guess the ideal situation would be if typedefs allowed for custom icons on the block diagrams for constant instances.  Is this possible?  It would make coding much more readable.  A header file could be simulated with a library of typedefs (scripting might even allow a .h file to be auto-generated)  Any ideas on this.  Other solutions. 

Paul

[LV_Pro]

I guess I'm not understanding what you are looking for that can't be done with the regular global in LabVIEW? You can make them using type def controls, can have them preloaded with values early in your program, and with LabVIEW 8.0 there is a new "global" that is truely global, being able to be called from vi's running on other machines. The overhead should be also minimal, you could probably even have the initialization vi loaded and unloaded dynamically.

 (I also don't know why someone gives a single star for a valid question!)

P.M.

Message Edited by LV_Pro on 10-20-2005 11:04 AM

[falkpl]

Yes typedefs are the way to go except one problem/annoyance, I cant get typdef constants to show up as a custom icon which is great for readability (the whole purpose of defining constants in the first place is for the programmers to be able to understand the code).  In 7.0 I can use a generic constant for the type but that is not so great.  The Biggest problem is with complex structures which when they are not in iconic form hog why too much space on the block diagram and when the type def is altered always resizes, obscuring code.  The #define is nice in c++ because I not only can define constants in one location (making it very easy to change) but are preprocessed, so the constant takes up minimal memory (only one location) and requires no functional call to retrieve, essentially they are replaced with a pointer to the memory location throughout the program.  In addition they can be marked at const type so that they can not be modified at runtime promoting better data hiding and control in modular programs.  I guess I would like a little finer control over data in LABVIEW than is currently provided.  This not to say that all can not be done with LABVIEW, since there is always a work around.  Thanks for the help.  As for the 1 star?  I guess its not my day, first I didn't win the powerball then I get 1 star, oh well.

Paul

[Ben]

Hi Paul,

If I follow you then take a look at the attached zip for an example of how I have handled this situation.

The "auto-growing" type-def'd constant are in a  sub-VI so they do not "auto-destroy" my diagram.

The sub-VI's do "bundle by names" to give me different version of the same type def.

This does take a little more work than just dropping a constant but

1) it make my code easier to read and

2) the sub-VI's do what my defined constants used to do back when I used to "C".

I hope this helps,

Ben

[falkpl]

Thanks Ben,

I will take a look at your code.  I think that #define is a very important feature in c which greatly simplifies both code readability and code management.  Wouldn't have been very easy for NI to allow us to ise our own custom icons on constants.

Paul

[Ben]

Hi Paul,

If I rember corectly the "#define" was a pre-proccessor command that let us establish a translation between a symbolic string and the syntaxically (sp?) correct string used by the compiler.

The big thing I see that is missing in the approach I suggested is the "conditional" defines. I believe with LV8 and the new project window, this short-coming is now addressed.

Ben

[falkpl]

I look forward to the new LV8 features, I hope to begin the migration process this winter when work slows down a little.  The only advantage to a preprocessed directive is that is will replace the code before processing (like cutting and pasting the value in place of the constant, with no function call overhead.  This could only be a problem with CPU intensive code.  See the following "toy" example.

//haven't been programming in c lately so don't jump on my syntax.

#define PI 3.14

void calculateManyCircleAreas()

{

float area = 0.0;

for (r=0;r<10000000;r++){area = (PI*r*r);

}

void calculateManyCircleAreas2()

{

float area = 0.0;

for (r=0;r<10000000;r++){area = (getPI()*r*r);}

}

float getPI(){return 3.14;}

the first example simply replaces the named constant with a value, while the second example uses a function call, requiring pushing the return value on the stack along with an Instruction pointer, and 2 required jumps in program flow.  Your solution is none the less the best I have seen and what I am using.  Labview used to have the same problem with commenting (ie placing code in a case statement and hardwiring it to a false Boolean) where the code was not removed by the complier but simply not executed (not quite the same thing) but this too looks to be fixed in LV8.

Thanks,

Paul