Feedback node initialization not identical to Shift Registers

[Robzilla]

I'm seeing discrepant initialization behavior between shift register tunnels and feedback nodes.  

All SR/FL in single-iteration while loop, within 3-iteration for loop.

• SR: re-initializes each "for" iteration
• FL with tunnel initializer: re-initializes each "for" iteration (same as SR)
• FL with internal initializer: initializes only on first "for" iteration (discrepant)

Is this intentional behavior?   Using 2022 Q3

[altenbach]

I cannot look at your VI unless you do a "save for previous", 2020 or below, but the global initialization of a feedback node is different and will only initialize on first call. This is by design and a very welcome functionality.

You can pick the exact mode by right-clicking in:

[Bob_Schor]

Interesting.  I've been working on older versions of LabVIEW (primarily LabVIEW 2021).  I also rarely use feedback nodes.  What I noticed, however, was the similarlity of the initializer with the "On First Call" initializer, which works exactly once in the running of the entire program, rather then the loop.  Still, it is confusing, which is possibly why I never really "adopted" the feedback node, but preferred While Loops and shift registers ...

Bob "Can't Teach an Old Dog New Trix" Schor

[crossrulz]

If you are using the Globally Initialize option on the Feedback Node, it is only initialized when it is first called. What you are describing is exactly what these three options were designed to do.

[altenbach]

---

@Bob_Schor wrote:

  Still, it is confusing, which is possibly why I never really "adopted" the feedback node, but preferred While Loops and shift registers ...

---

I absolutely love feedback nodes, especially for action engine, because they eliminate the need for a "one iteration" while loop AND a "first call?" primitive, greatly simplifying the code.

For example, compare the two codes in my ancient post here. (read the later posts too!)

 

The only functionality I am missing is discussed in this old idea.... (please vote or it!!)

 

[Robzilla]

Thanks for pointing this out - these are major implications that are somewhat swept under the rug.   Here's what I found...

It seems the forced settings of Globally Initialize drive the difference between these scenarios

• FB Node with tunnel initializer
  • Globally Initialize disabled (converts to internal initializer if selected)  => [1,1,1] initialized each For loop (same as SR)
• FB Node with internal initializer
  • Globally Initialize on compile or load => [10,11,12] initialized once on compile, each run feeds back from previous
  • Globally Initialize on first call => [1,2,3] initialized once on run, feeds back from start of each run

[altenbach]

Yes, these are all useful, but I agree it is not really well documented.

Of course the two version of "globally initialize" don't really differ once you have a typical built application that can only run once per session..

[BertMcMahan]

Just a general FYI, use extreme caution when "automatically" initializing a shift register or feedback node in a shared clone reentrant VI (like much of the Actor Framework). Since they're shared clones, they will not reinitialize when a new process uses them. Same goes for the "First call?" primitive. I've taken to never automatically initializing anything shared, and never using the First call? primitive, as it's bitten me at some point down the line every single time I've used it.

I have found myself coding something "that will never be a shared/reentrant VI" using this technique, then later on deciding "dang, it does need to be shared after all!". So, I just stick to manual initialization if at all possible.