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!
Showing results for 
Search instead for 
Did you mean: 

functional variable initialisation proposal

Status: New




Proven Zealot

IIRC, you can replace it with a feedback node and utilise the initialisation methods of that instead. Functionally identical.


While feedback nodes solve this issue, I dislike them unless the backwards wire of the feedback node is a very short loop, else I prefer a while loop with uninitialized shift registers. 

Please consider a while loop instead of a for loop since its a more common design pattern in a FGV than possibly the example above with for loops. 

Proven Zealot

I see no reason why we couldn't implement this, but it seems to me to have multiple downsides. Most of those downsides are shared with the Feedback Node today. I would hesitate about proliferating them.


My concern with this notation is non-trivial initialization code. For example, read a value from a config file and use that as the initial value.


In your example, you initialize with a simple constant. Great. But if you initialize with a computed value, that computation code runs every time (being upstream of the loop/feedback) (to read the config file, for example) and on the first call it sets the value of the register but on all future calls the value gets thrown away. In other words, you waste a bunch of time recomputing every time. You *still* need to put the First Call prim down with a Case Structure to avoid that overhead (opening and reading the file on every iteration).


Moreover, a large percent of the time that you need custom initialization, you also have some condition for re-initialization, i.e., when your program, without restarting, resets to its initial state. That situation still requires the case structure. With the notation shown here, reset has to be done by inserting the reset code somewhere along the feedback, pretty much negating the value of the notation.


To me, it's a fine solution for very simple cases, but it is easy to write non-performant code without realizing it and it is limited in the cases that it can solve.