Project #Defines or Project Variables

[MikeeB]

The concept is to have a project level #define or variable where a value of your type can be set. This is to allow the user to change constants across multiple targets. Wherever this is called in code it will be set when the run button is clicked and then be static until it is run again. The same would happen when a build is run that the value is set then and never again.

This would allow multi target configuration quite simply and make for some more readable code when you a constant referred to at multiple levels or across large chunks of code. Instead of having a wire to span these sections or being passed down multiple subVIs it would just refer to one point, much as a #define in C

Project

Then calling code for targets

[AristosQueue (NI)]

@sbus Does it suffice to have different constants in each frame of the conditional disable structure returned as one output from an inlined subVI? That would give you the "select value based on condition" that you're asking for, without anything special for global VIs.

The reason I ask is that global VIs will not exist in LabVIEW NXG, so I'd be loathe to add features to LabVIEW 20xx that would make migration harder. Also, you can do the returned constants today without any changes to LabVIEW.

[sbus]

Hi Aristos, long time!

The idea is to get project based options/variables made available inside a VI.  I want to be able to change a project variable and then perform a build using the project variables to control the build, such as building a motion control application to support different motion controllers, or to build a 'regular' and 'debug' version of an executable. Not only do I want to conditionally include code, I want the value available inside my VIs also.I always was dismayed at the implementation of conditional disable structures for the same reasons as MikeeB

The variables ideally would be ABOVE the code, not in a VI, but rather set in the project framework (such as conditional disable symbols are now). Unlike conditional disable symbols, however, they would be assigned a value which, rather than only being used to control a conditional disable structure, would be accessible as a value in a VI within the project also.

I'd want single and enumerated types.  Let's call them Project Variables (PVs) and Enumerated Project Variables (EPVs). Neither are enums or rings in the standard LabVIEW sense; EPVs simply have their possible values enumerated when you create them (a table in the project data). Both PVs and EPVs have type; neither are used in the VI as an enumerated type.

For instance, an example of a  PV would be "NUM_AXES" with a type of INT16 and a value of 3. An example of an EPV would be "MOTION_CTLR" with a type of STRING and values of "IAI_TT", "NEAT_450", and "DOVER DMM-00X0". At compile time both would 'become' simply strings...

For PVs, you'd just drop them on the block diagram (like a global is now) and they'd essentially be manifest constants selected before compile time.

For EPVs, you could drop them on the block diagram and get their value (just like a PV, and their type would be non-enumerated just like a PV); but for EPVs there would also be a special case structure, to allow placement of code for different values of the EPV. We'll call it an "enumerated project case structure", or EPCS. Unlike a standard case structure, only one case in an EPCS would be compiled, and that case would be chosen  by setting the EPV before compile time. Rather than using a selector and wiring a variable to it as in a standard case structure, you'd link the EPCS to a EPV (right-click, select "link", choose from the list of EPVs presented), and it would populate with one case for each enumerated possible value. That way when I code, I can think of it as a traditional case structure, but only one case would show up in the executable - it would be hard-coded for that value of the EPV. There could also be a terminal to allow the programmer to get the value of the EPCS selector (the EPV), just as if it were wired to the inside of the selector terminal in a standard case structure. The EPCS is an alternative to the conditional disable structure, which could be done away with if NI implements the PV/EPV/EPCS idea.

The most important part of this is that the PVs and EPVs are set before runtime (and before compile time); that they are NOT set within the VIs making up the application, but above that at the project level; and that the only code compiled within an EPCS would be for the selected case based on the value of the EPV at compile time. Similar to a #define; but without a pre-processor, and (alas!) without C.

[wiebe@CARYA]

>I always was dismayed at the implementation of conditional disable structures for the same reasons as MikeeB

Any specific reasons MikeeB gave? Not (knowingly) knowing her\him, a thread to those reasons would be useful. EDIT: I can guess of course...

[sbus]

Hi Aristos.

As YOU pointed out in in this thread ("Project #Defines or Project Variables), "Currently, as Mr. Mike notes, you cannot get the Conditional Disable Structure to give you the value of the conditional symbol, so you cannot conditionally define font sizes, or optimization levels, or any of a thousand other things."

It seemed to me that it was only one short step in implementation to be able to get the value of a conditional symbol, and yet it wasn't implemented; and the idea that you didn't get to populate multiple cases for conditional symbol values (i.e. my EPV/EPCS idea) made the code considerably less readable, and unnecessarily restricted the usefulness of the conditional disable structure.

[AristosQueue (NI)]

I know there's no mechanism. When I've raised this question in the past, I've gotten pushback that using the conditional disable to define variables was sufficient for most cases, and it wasn't worth the feature time to make the raw values accessible. Sure, you can't use it for continuous values, but you could use it for anything with discrete values.

So I asked you whether the discrete mechanism would work for you... and got the answer I was expecting: no, it's not enough. That adds one more customer's weight to the argument that we should expose the conditional disable values somehow. And your write up is particularly cogent. I don't know if NI will ever act on this, but as it comes up in future planning, it helps me to have the explicit use cases direct from customers.

[Intaris]

Can someone explain what getting the conditional symbol has to do with setting fonts or optimisation levels?

Do you mean like having a conditional Symbol defined as "Tahoma" and parse that at compile-time?  I'm really not sure what I think of that idea.  Can't this be done with a pre-build VI and an INI file?

I understand the need, but I'm not feeling much love for involving project settings in this at all.

[wiebe@CARYA]

Those conditional symbols are exposed, but not in a way the would allow the compiler to optimize\remove code.

The project conditions are strings, and LabVIEW code to get them won't be 'constant' at compile time. So a case connected to it will keep all of it's cases.

My biggest problem with CDS is that the VI is changed and my SCC is trigger by that.

[sbus]

Another approach - how about a new type of RING control that is NOT changeable at runtime and can have numeric OR string values, by definition non-sequential... you'd set the default data pre-compile and make it a strict typedef control. Think of it as a list of #defines... 

You'd add it the same way you create a globals.vi (right-click, NEW, global) only it would be a defines.vi, and the only items you could place on it would be numeric defines rings and string defines rings...

It should be allowable to use it as a conditional symbol at compile time, or as a case selector variable or as the subject of a comparison at runtime.

Just an idea...