difference between feedback node and shift register

[bronger]

Halloechen!

What is the difference between a feedback node and a shift register
in a loop? (I'm sorry if these names are not correct; I had to
back-translate them from my German LabVIEW installation.)

Thank you!

Tschoe,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[EdDickens]

Operationally, they do the same thing. Pass a data item from iteration of a loop to the next.

The difference is in how they are wired and the fact that a feedback node can't be expanded to get items from more than the previous iteration of the loop.

You can still initialize a feedback node by right clicking on it and selecting 'Initializer Terminal', then wire your init value to the new terminal on hte left loop boarder.

Ed

[altenbach]

If you only have one history terminal, they are the same and you can covert between the two by right-click "Replace with feedback node/Repace with shift register". Feedback nodes have the advantage of less clutter, especially if you have wide loops (short localized wire loops instead of telephone lines across). Personally, I always prefer shift registers. Feedback nodes always seem to make the diagram less clear.

[Lavezza]

Both Shift Registers (SR) and Feedback Nodes (FN) can pass data from one iteration of a loop to the next.
Both can be initialized to a value before the loop starts (although this is hidden by default for FNs).

The main differences are:

1. Getting values from previous iterations
   
   • SR = can expand input terminal to get multiple previous iteration values
   
   
   • FN = can only get the most recent iteration



2. Getting last value when loop ends
   
   • SR = value is available at output terminal
   
   
   • FN = value is not available without additional programming




3. Block diagram space
   
   • SR = wires must be run to both sides of the loop
   
   
   • FN = wires can be very short

So, in sit
uations where you only need the last value and you don't need to pass the final value out of the loop, the FN provides a less cluttered option.
HOWEVER, the FN is currently SLOWER than the SR.
I don't see why this needs to be (interally LabVIEW could replace a FN with a SR. Or, since the FN is a more restrictive case, it could probably be optimized to be faster than a SR.)

[FrenchPress]

Ok, so I realize that the last post was in July of '04, BUT I think that as of today, on V7.1.1 the FN is faster than the SR.

I was writing an intensive integrated test app, and needed to pay close attention to performance, and wrote a quickie test to check the time difference.  The results were that the FNs were between 30% to 50% faster than the SRs.  The std deviation of that measurement was pretty high, as my test was not very deterministic, and i'm sure that XP was jumping away to process spam from Nigeria, etc...  🙂  However, I ran it at full clip for about 20 minutes and averaged the results, so I would have to say that I'm using Feedback Nodes whenever possible until somebody tells me it's not the thing to do...

[tbob]

Excellent observation.  We are always looking for ways to speed up execution.  5 stars to you, monsieur FrenchPress.

[Les Bartel]

Hmmm.

I just ran a test on LV 8.0 and the feedback node took 50% longer than shift register.

 - les

Message Edited by Les Bartel on 05-16-2006 03:02 PM

[altenbach]

The consesus was always that a shift register is faster.

(see also http://forums.ni.com/ni/board/message?board.id=170&message.id=154958&query.id=0#M154958 and the NI response)

Are you sure your benchmark is valid?

Where all VIs propery saved before running or could it be that some were just upgraded from a previous version and thus were artificially slow?

[Les Bartel]

I've attached the VI.  I wrote it today.

 - les

[FrenchPress]

OK.  Got it now.

I ran les's vi and confirmed his result, and started to scratch my head.  Why did I get different results?  How could those results be consistent with NI's explanation?

The difference between my test and Les's test is that he writes new data to the node/shift register with each iteration.  In my test I used the node only to hold the millisecond counter start time.

Presumably this means that there is some checking going on to determine if the value has changed, and if it has it re-allocates, blah blah blah...  Taking 40% more time than the SR.  But if you're reading only, such as old-style global variables or the like, then it's faster.  This would be consistent with NI's note, and our combined test results.

Yes, since I know you're wondering, I still use old-style global variables once in a while, and perhaps that's fodder for another thread...