LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Structure that allows constants to be generated at compile time.

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 


Active Participant

I like this idea. It makes constant folding more explicit and provides a shortcut to what you'd otherwise have to do with a prebuild action

Trusted Enthusiast

It would fill a few gabs in functionality.


I'd use this to embed resources (like images). In source code, they are loaded from file, in executable, they are embedded...


A tricky part would be the timing. You'd think the compile happens when you press build, but if the VI is already compiled (needed to run it in source code), this might not happen again. That might not be a big thing, it's a matter of specifying the VI code is run again and then "folded" when the build is done.


I'd call it "On Build" instead of "On Compile" for that reason: building an executable is something different then compiling the VI. On FPGA it's more or less the same, but I'd like it on any target.


When running source code, it might be useful to specify the behaviour: on first run \ on compile \ run code. On first run would re-run the VI once after restarting it. On compile would only re-run the code after a re-compile (when changed). Run code would simply run the code every time. Once compiled, it uses the result of the executed code.


On FPGA\RT targets it could also be a bit confusing: the code that's inside should use host scope (paths etc.), while the VI is scoped on another target.


I was envisioning that there would be two settings "On Build" and "On Compile."  On compile would be on every vi change. On build would be a subset of On Compile that only happens during build. There might have to be a project scoped update button as well. e.g. rerun all constant generation. But of course I wouldn't be savvy to all the implementation details after all its just an idea right now.


As far as when viewing on running targets, I imagine that the code will always be faded out during run time giving the indication that the code is not currently being used.

Trusted Enthusiast

@Taylorh140 wrote:

I was envisioning that there would be two settings "On Build" and "On Compile." 


That would work too.

Proven Zealot

I added my kudos and asked that this be placed in the feature backlog for LabVIEW NXG. It's a good idea, but not one I see us acting on soon.

Trusted Enthusiast

Reading this idea, it seems to be very closely related to THIS Idea I posted a while back.  Formulation / wording is different, as is possibly the direction I was originally approaching the issue from, but I think the end result is very similar.


Either way, Kudos.


@Intaris I must agree. These Ideas are very closely related. I didn't even mention constant folding in mine (althougth it was what i was referring too), I was just looking for a better/more flexible pre-processor tool. I was more focused on the tool and you on the result. Thanks for your idea and effort.