Jump to content

Structure that allows constants to be generated at compile time.


Recommended Posts

I posted This on the Idea exchange a few days ago. I have been wondering why no-one sees the need for constant generation at compile time. I think this would be especially useful in FPGA, but also for constants that need data from the build environment. Perhaps there is just a better way of doing these types of operations? Let me know what you think?

Quote

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. 

image.png

 

Link to comment

This seems like it would be pretty easy to do using a pre-build step. Is there something you had in mind which isn't solved by this? (Also, on FPGA you can do something like this using VIs to define initial contents of memory)

As for the popularity of the idea, I'm actually kind of surprised the idea exchange still has as much activity as it does -- 85 whole kudos this year -- considering nxg. Anyway, some ideas in the same vein:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Disable-Symbols-settable-in-Application-Builder/idi-p/924581
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Conditional-Disable-Symbol-Constants/idi-p/1034752

The first would solve my main issues. The second would be neat, and I've occasionally wanted it in the past. I'm not really sold on the value of what you've described outside of the compile time you show in your post (which is not something I've ever personally implemented)

Link to comment

I typically view the conditional disable as a different kind of item. Not really that different from a case structure with a global written to the conditional terminal. Run this code or that code depending on the configuration of the system. But code is still run on the production environment.

This idea is a bit different because the code is run only on the development environment. The idea is in some ways a very convenient prebuild step. Also it increases consistency. Why do prebuild on pc and vi memory initization on FPGA when you could do it in a uniform fashion. Why not use LabVIEW as its own pre-processor?

Value would be for things like reading configuration files from the development PC, that i don't want editable in production. Easily Labeling the front panels SVN REV and build time. Perhaps event reducing startup time for LV apps by preprocessing startup code.

To me I feel like this would be a great additional structure. I do appreciate your thoughts on the topic, thanks.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.