Add the ability to split feedback nodes

[tst]

There are times when I don't really like the way feedback nodes make my diagrams appear:

I don't like the wires going back and overlapping things. This usually happens when there are a number of FNs in a single piece of code.

One way to work around this issue is to do something like this:

This splits the wire into two nodes and is essentially the "text based" approach - create a named variable and use it as a buffer. The fact that it's a local doesn't really bother me that much, even though that might raise the local police on me, but it does have some actual disadvantages - memory allocation (not usually a real consideration, but still), difficulty in setting an initial value, a technical possibility of creating race conditions if the user doesn't know what they're doing, it's harder to see that the two nodes are connected, etc.

So what I want is something which would combine the two - allow us to right click a feedback node and select Split, which would split it into two:

which results in this:

This is essentially like having a shift register without the loop. It ties the two parts of the node together and it should allow having an init terminal on the read node. In theory, it could also have a label. Also, note that in this case I didn't limit the vertical positioning of the nodes. This should be useful in cases where nodes are connected through elements which change the height of the wire, like Build Array or Select.

If you want to see some more opinions on this, we discussed it here a few years ago - http://labviewartisan.blogspot.com/2009/03/why-are-you-still-using-loops-in-your.html

Also, here are a couple of alternate visuals, just for completeness, although I don't really like them:

[Intaris]

I can see the usefulness of this (I would certainly make use of this idea) but I would add that we should see a reaction on BOTH terminals when we select one (wuithout actually selecting both) so that we don't accidentally mix up "interleaved" shift registers/feedback nodes i.e. if you have another read terminal inside your case with an additional write, it might be confusing to some which is actually connected to which.  With the wire, the grouzping is pretty clear (even if the method of being clear can be annoying)

[AristosQueue (NI)]

We have a way to split the feedback node. It's called a shift register. I really don't think that introducing yet another syntax for this is a good idea. Put the single-iteration loop around the node and be done with it. The major advantages to me are that the structure node gives a clear indication of the two nodes being paired (so you have a visual guide where to look for its partner and indication that when one moves, the other moves) and it prevents UI weirdness with Create SubVI From Selection (selecting only half of such a node becomes yet another reason you cannot create subVIs).

Both for myself in my own code and my role in R&D looking at what it would do to language pollution, I don't think this is a good idea.

I *could* see us putting uninitialized shift registers on an Inplace Element Structure. What would you think of that?

If we did implement your split-node solution, I would probably encourage putting a must-be-unique label on the two halves to clearly indicate when two are paired, like the labels on the local variable matches the variable on the FPTerminal.

And, about that local variable solution that you've got now... ug. I see that you acknowledge the memory overhead, but just to be clear to other readers of your post: that is a full copy of the array at read and another full copy at write. That's pretty heavy compared to the shift registers/feedback node solutions. Possibly ok in Tst's particular use cases, but not something I'd advocate as general practice.

[Intaris]

Put the single-iteration loop around the node and be done with it

This always feels like a hack to me.  Imagine a feedback within one of the cases int eh example above.  Putting a loop in there also adds to the complexity of the code and gives a false sense "at a glance" about what the code is doing.  I would have thought that this would actually be a better solution to the feedback problem than the current version since the current version has wires flowing backwards which is otherwise not encouraged.

I still think the quick identification of which input and which output belong together is very important in this regard.  While the for loop or while loop for a single iteration loop would help with this, I don't like that idea.

[AristosQueue (NI)]

> This always feels like a hack to me.

That sentiment is why I asked about the Inplace Element Structure. And I don't think it is a false sense to raise a big flag that says, "This VI is stateful."

[crossrulz]

I would be fine with the Inplace Element Structure being able to use uninitialized shift registers.

[Darin.K]

The Flat Sequence Structure (and its unspoken-of ilk) makes more sense to me as a location for SR.  Besides, there could be no interleaving with the IPES, unlike the FSS.  I could imagine them starting and stopping on arbitrary frames, the only constraint I would place is that they could not overlap in position if they overlapped in a frame. 

[tst]

AQ, of all your objection the one I connect to the most is the too many syntaxes (syntaces? syntaii?) one, but the thing is, I don't like the structure sometimes. There are cases where there's a bunch of code and I want something minimalistic - no structure, no wires. It doesn't really matter if the structure is a loop or an IPES or a sequence. If the current feedback node is too much for a specific case, then these would probably be too. This happens even in cases where there's already a loop and I still prefer using a feedback node to a shift register. The example I posted in the idea is actually not a very good example of where this would be more useful, but it was the images I already had from the other discussion, so I used them.

I have no objection to SRs on an IPES or on a sequence (I actually voted and commented on one or two such ideas before the no-improving-stacked-sequences-police shut them down), but I'm pretty sure that would not solve the problem I'm having, which is wanting to have a shift register with a minimal footprint. It also doesn't allow to set them at different heights in order to minimize wire bends, which I think I would like. I understand the argument that both different heights and the lack of a container could hurt readability, but I think I could live with that.

And yes, I absolutely agree that a quick way to identify the second half is probably a must. This could be a shared label, a double click to highlight, a single click to highlight, etc.

[AristosQueue (NI)]

> It also doesn't allow to set them at different heights in order to minimize wire bends, which I think I would like.

...

> but I think I could live with that.

That is one detail that I would have to see given a fair number of kudos before I would believe it would be a good thing for diagrams, and then I'd have to see usability tests on a wide range of users. That strikes me as likely to impair readablity significantly.

The lack of a structure to pair the nodes also makes it much easier to have one half end up inside a structure node and the other half outside. Another error case to check for and explain.

Still, as a member of R&D, I can see why you would have that goal and wouldn't say no if it really helps many users.

----

Speaking strictly for myself as a LV programmer -- *statefulness* is not something I ever want to be minimized on a block digram. I like that global variables, local variables and shared variables are big labeled things. I like that USRs require a structure node. Feedback nodes already flirt with my "waaaay too easy to miss" threshold. If I'm looking through diagrams, I want it to be bloody obvious that "this VI may be storing results either run over run or call over call and thus is far more likely to be the source of that strange not-always-reproducible bug than any other VI." Their testing burden is higher, and understanding their logic requires more meta-thinking. So your overall goal of a minimalist SR/Feedback Node actually conflicts with my goal of "blindingly obvious and calling attention to itself always". And this isn't something were we get to have different opinions and we'll just configure our LVs differently because when I'm having to look over your code, I want that called out significantly, where as you want it to recede into the background as a secondary detail.

[AristosQueue (NI)]

Tst: Can you post some more of the diagrams where the Feedback Node as it stands feels too heavy weight to you? The one that you posted in the idea originally isn't something I see as bad, especially if you were to run the blue backward wire over the top of the structure parallel to the orange one.

[tst]

---

I like that global variables, local variables and shared variables are big labeled things.

---

As do I. What I don't like are big bulky things which require wires to cross many things. I think my favored design for the split node is prominent enough, but I can understand how this varies by user.

I'll try to keep my eyes open to find diagrams which better show why I would want this. Hopefully others will too.