Jump to content


Photo
- - - - -

Feedback nodes

feedback nodes shift registers

  • Please log in to reply
14 replies to this topic

#1 martin_g

martin_g

    3 more posts to go.

  • Members
  • 7 posts
  • Version:LabVIEW 2010
  • Since:2007

Posted 12 April 2012 - 09:14 AM

Hi All,

After struggling on my recent CLD-R with feedback nodes, I've decided to try using them in some projects. I've got stuck on my first trial however!

I've tried replacing a fairly common conditional incremental count within a For Loop, that I would usually do with a shift register, but I just can't get the correct result with a Feedback Node. Code is attached, is this a correct usage case for a Feedback node?

In the current configuration, when count value returned from the Shift Register is zero, the count returned from the same code using a Feedback node is 1. I've tried other configurations, but still get incorrect results.

Feedback Node.jpg

Attached File  Feedback Nodes.vi   32.54K   34 downloads

#2 jcarmody

jcarmody

    The 500 club

  • Premium Member
  • 789 posts
  • Location:North Carolina, United State, Earth
  • Version:LabVIEW 2012
  • Since:2007

Posted 12 April 2012 - 10:02 AM

One small change and you're there.

Feedback%20Nodes1_BD.png

Resistance is Mandatory

No rulers
No masters
NO CONSENT

 


#3 todd

todd

    Very Active

  • Members
  • PipPipPip
  • 222 posts
  • Location:Seattle
  • Version:LabVIEW 2012
  • Since:2002

Posted 12 April 2012 - 10:15 AM

That's what I thought, but the fourth iteration of the loop outputs the left side of the Increment, which is at 3 for the "100%" case. I don't like the Enable terminal, in this case.

#4 ShaunR

ShaunR

    LabVIEW Archetype

  • Members
  • PipPipPipPipPipPip
  • 2,224 posts
  • Version:LabVIEW 2009
  • Since:1994

Posted 12 April 2012 - 11:36 AM

The enable terminal will prevent the FEEDBACK VALUE (FV) being propegated not prevent the action of the +1 as it does in your top scenario. So,after initialisation (FV=0) you get an output of 1 since 0+1 =1.

So the feedback node is behaving as expected, however your shift register example is not equivelent.

Below is how the feedback node behaves in your example.(I agree with Todd-the enable terminal is not a good usage for this scenario).

Untitled.png

Edited by ShaunR, 12 April 2012 - 11:43 AM.

A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. (Herm Albright 1876-1944).

Founder and general mischief maker on www.labview-tools.com.
SQlite aficionado and websocket zealot.
If it 'aint in LabVIEW, then you 'aint got a clue!

#5 François Normandin

François Normandin

    Son of Scotland

  • Premium Member
  • 1,081 posts
  • Location:Montréal, QC
  • Version:LabVIEW 2012
  • Since:1999

Posted 12 April 2012 - 01:02 PM

You can change the feedback node direction and wire the output of the node instead of the output of "+1".
That would be the equivalent to the case structure.

Posted Image

François [frɑ̃swa], CLA


#6 todd

todd

    Very Active

  • Members
  • PipPipPip
  • 222 posts
  • Location:Seattle
  • Version:LabVIEW 2012
  • Since:2002

Posted 12 April 2012 - 05:47 PM

That still doesn't work for the case where Status Array is all 1's. On the fourth (and last) iteration, the output of the increment is 4, but the output of the feedback node is 3.

#7 martin_g

martin_g

    3 more posts to go.

  • Members
  • 7 posts
  • Version:LabVIEW 2010
  • Since:2007

Posted 12 April 2012 - 06:10 PM

OK, thanks for all of your input, I'll stick to using the shift register, and look for another use to try out Feedback Nodes!

Cheers,

Martin

#8 asbo

asbo

    I have no idea what you're talking about... so:

  • V I Engineering, Inc.
  • 1,273 posts
  • Version:LabVIEW 2011
  • Since:2008

Posted 12 April 2012 - 06:15 PM

I think this is a bad example usage of the feedback node. I would just use Add Array Elements and call it a day. Or if you feel like being complicated, keep the equality comparison and use the Boolean to (0, 1) node and iterative sum that.

#9 Darin

Darin

    Very Active

  • Members
  • PipPipPip
  • 158 posts
  • Version:LabVIEW 2009
  • Since:1992

Posted 12 April 2012 - 07:09 PM

Feedback Nodes have amazing potential that NI needs to unleash. The first step is to get this excellent idea implemented.

http://forums.ni.com...he/idi-p/927458

This would solve this problem (the need to handle the last iteration as a special case), and also eliminate the need to wire the output of the FN through all frames of a Case Structure.

I have been lured many times by the siren song of the feedback node in this instance, so close, so very close, yet in the end, denied!

I like using them to build up dictionaries using variant attributes. Nice tight loop from variant out to variant in. Of course this is only after LV10 when they fixed an annoying bug which affected the combination of variants and feedback nodes (like they went out of their way to target two of my favorite things).

#10 neil

neil

    Extremely Active

  • Members
  • PipPipPipPip
  • 409 posts
  • Location:Surrey, UK
  • Version:LabVIEW 2012
  • Since:2004

Posted 12 April 2012 - 07:56 PM

Holy guacamole!

I did not know about the Enable terminal! Nice :yes:
CLA, CPI and CTM (Certified Tea Maker)

#11 Aristos Queue

Aristos Queue

    LV R&D: I write C++/# so you don't have to.

  • Premium Member
  • 2,620 posts
  • Location:Austin, TX
  • Version:LabVIEW 2011
  • Since:2000

Posted 13 April 2012 - 01:22 AM

If you like the Enable terminal, there's a feature coming in LV 2012 to solve the tunnel output consistency problem. Take a look at the Upgrade Notes when you get your upgrade later this year.

#12 mje

mje

    The 500 club

  • Premium Member
  • 813 posts
  • Location:Milford MA USA
  • Version:LabVIEW 2011
  • Since:1997

Posted 15 April 2012 - 01:14 PM

Yeah, I'm late to the game on this one.

<meme>I don't always use feedback nodes, but when I do, it's only when I don't need the output outside the scope of a loop.</meme>

No seriously, I don't see what feedback nodes bring to the table versus shift registers when you need to use the output outside of a loop. I would consider it if altenbach's idea made it in, but I still don't like them as much as shift registers because they break data flow insomuch as the initializer terminal (and would be final value terminal) isn't visibly linked to the actual feedback node. I find this can lead to confusion in all but the smallest loops.

I use them all the time on the top level of a VI for static data, but if it's in a loop, more often than not I use SRs.

#13 crelf

crelf

    I'm a LAVA, not a fighter.

  • V I Engineering, Inc.
  • 5,742 posts
  • Version:LabVIEW 2012
  • Since:1993

Posted 15 April 2012 - 02:33 PM

I think this is a bad example usage of the feedback node. I would just use Add Array Elements and call it a day. Or if you feel like being complicated, keep the equality comparison and use the Boolean to (0, 1) node and iterative sum that.

Agreed.

post-181-1170858537.png


#14 Aristos Queue

Aristos Queue

    LV R&D: I write C++/# so you don't have to.

  • Premium Member
  • 2,620 posts
  • Location:Austin, TX
  • Version:LabVIEW 2011
  • Since:2000

Posted 15 April 2012 - 03:31 PM

No seriously, I don't see what feedback nodes bring to the table versus shift registers when you need to use the output outside of a loop.

1) In pipelining, particularly common in FPGA, they're critical. Of course, those are configured for feedforward, not feedback.
2) I'm told (and anecdotally find to be true) that electrical engineers are used to reading the feedback notation in other schematics. They read them much easier than the shift registers.

#15 Yair

Yair

    Extwemely Active

  • Members
  • PipPipPipPipPipPip
  • 2,645 posts
  • Version:LabVIEW 2009
  • Since:2003

Posted 15 April 2012 - 06:05 PM

Of course this is only after LV10 when they fixed an annoying bug which affected the combination of variants and feedback nodes (like they went out of their way to target two of my favorite things).


Ugh, don't remind me of that. I based a low-level widely used component on this combination and I stress tested it before I started writing the relevant application to make sure it performs well, and it did. Fast forward to a couple of months later, when I test the app and lo and behold, this performs really badly. For a while, I thought that maybe my original tests were flawed (or worse, imagined). It took some debugging to understand that the bug only manifests itself with a particular combination which wasn't there when I ran the tests (I think it was if you use the initializer terminal to globally initialize the variant, so I ended up initializing it using a first call and select primitive).