An output terminal for feedback nodes that mirrors the initializer terminal

[altenbach]

Feedback nodes can reside entirely inside one case of a case structure. This simplifies coding if feedback operations are limited to one single case. Unfortunately, there is no easy way to retain the output once the loop has finished if the last iteration executes one of the other cases. As a result, we might see local variables or even indicators inside the case containing the feedback node, defeating the "in place" purpose. For a "wired" solution, we need to place the feedback node outside the case and wire across all other cases (image top).

I propose an output terminal that sits on the output edge of a loop and contains the contents of the feedback node at the time the loop finishes. Typically that would be the edge of the same loop that contains the initializer terminal (image bottom), but it should also be available for globally initialized feedback nodes and on other loop boundaries surrounding the feedback node (selectable).

I am sure this idea needs to be worked out in more detail, so this is just an initial concept. 😄

Message Edited by altenbach on 06-16-2009 09:34 AM

[tst]

Your specific example would actually be better implemented with the conditional auto-indexing suggested in one of the other ideas, but in general I agree with you and there are other cases (e.g. nested structures).

[JackDunaway]

Would the initializing and output terminals have to be on the same loop (like shift registers)? I don't think so.

[altenbach]

tst > ...specific example ...

Yes, of course! My example was stripped down to the bare bones to just show the concept, sorry about that. 😉

The vast majority of my feedback nodes contain a fixed sized array, operate on it "in place" inside the loop, and I need the array after the loop(s) has(have) finished.

With my suggestion implemented, the code remains relatively simple, even if we have a dozen cases in the case structure, each containing a different feedback node. 😉

mechelecengr>  I don't think so.

I don't think so either, that's why I wrote:

altenbach> and on other loop boundaries surrounding the feedback node (selectable). 😄

[altenbach]

Thinking more about this, it is even very desirable to have multiple instances of the output terminal allowed of there are several stacked loops: zero or one per feedback node on any loop boundary surrounding the feedback node.

One suggestion for the UI:

BY default, the output terminal is not shown. If we show it, it will be in the toplevel loop at first. Then we can move it out one loop at a time but it also will remain visible on all inner loops.

Message Edited by altenbach on 06-16-2009 11:47 AM

[PJM_Labview]

I have to say that I am not too excited with this idea. In my opinion, feedback node tend to make the code more obfuscated, so adding an output "terminal" just increase the obfuscation.

Just my 2 c.

PJM

[altenbach]

PJM,

Until LabVIEW.8.5, I stayed far away from feedback nodes for similar reason, but in LabVIEW 8.5 we got the new standalone feedback nodes that no longer needs to be tied to a loop in any way. A globally initialized feedback node has no equivalent shift register because it also includes "first run?" functionality for free. Also the arrow direction can now be changed manually so it matches the code logic.

I must say that these new features have changed my perspective dramatically and I use feedback nodes more and more. They have significant advantages in many scenarios and lead to simpler and easier to read code. (See for example my last paragraph here or Darren's second image here).

Message Edited by altenbach on 06-16-2009 04:34 PM

[JackDunaway]

PJM,

I agreed with you until 2 weeks ago when I read Darren's blog. Since then I have been on a rampage converting action engines, functional globals, timers, counters... you name it... to feedback nodes. There is nothing LESS obfuscating that condensing wires into one case that are ONLY changed in that case. No more piping through these completely untouched wires through all my case structures!

In a benchmark I performed on a cRIO of our most-called action engine (somewhere between 5k-10k times per second), there was no performance difference whatsoever (performance was my biggest concern, as FN's historically were notoriously slower). 

CONDENSED VERSION:

Step 1: I would strongly encourage you to start using feedback nodes.

Step 2: Kudos this excellent suggestion. 

Best regards,

Jack

[PJM_Labview]

In the example you provide Christian, lets imagine that you are in a for loop that do quite a bit of stuff. Now, because of the initializer terminal, I know there are a feedback node somewhere, but where is it? I have now to go hunt for it looking in different frame inside the for loop to find it. Because this brake the data flow, I think this make the code more difficult to understand at a glance.

I understand though that it is neater (less wire).

In situation where it allow you to get rid off a while loop I concede that this is useful (although to be fully honest, while I recommend this to the FIRST team I was coaching I am still using the shift register) .

PJM

[JackDunaway]

I think your "hunt for the feedback node" argument breaks down pretty easily. Using shift registers, you have wires shorted through the cases, and you're asking yourself a new hunting question... "Now where am I operating on this data that's being piped through every single darn case??"

I don't have LV 8.6.1 in front of me, but aren't you able to right click on the initializer terminal and select "Show Feedback Node"?

[tst]

> but aren't you able to right click on the initializer terminal and select "Show Feedback Node"?

I don't know, but if you aren't, this is definitely a desired feature.