Allow for Stacked Feedback Nodes

[PaulRB]

When using feedback nodes, you can store data like you can with shift registers. However, you cannot get multiple data points from previous iterations like you can with stacked shift registers. I think this is best shown with a picture, so here is my idea:

 

[Darin.K]

Although my eyes kind of hurt, it seems that all enable terminals are linked to the same input so I think it would actually help.  It won't help me understand the FSS with the passthrough wire, some type of funky FPGA thing I suppose. 

(I would consider changing the direction of the FNs)

I do not do FPGA, but I do like the FN because of the enable terminal and array initialization, and I would like to see something along these lines implemented.

[Darren]

I think it would help.  The constant value coming in from the cluster is enabling the logic of the entire diagram...notice it's ANDing all the feedback values, and enabling all the feedback nodes.  Maybe I could mock up a screenshot at some point, but I think the entire diagram can be replaced with a stacked feedback node inside a case structure that doesn't execute if that input boolean is false.

[Darren]

Darin: This is auto-generated code...the FSS with the pass-through facilitates easier wiring through scripting.  😉

[WG-]

I think this is a bad idea, because this adds another way of doing the same thing. I think programming languages/environments should only allow 1 method, to keep and preserve consistity and clearity.

[GregSands]

WouterG: I think this is a bad idea, because this adds another way of doing the same thing. I think programming languages/environments should only allow 1 method, to keep and preserve consistity and clearity.

???  I thought the LabVIEW philosophy was that there are never too many ways to do something!

To be more serious, isn't this roughly equivalent to not allowing the Compound Arithmetic node because you can always create multiple Addition nodes?  I would have thought that providing more elegant ways to achieve the same result provides more clarity, not less.

[vitoi]

I would like to re-iterate that the shift register is a clearer way of doing/showing the same thing. (And just like WouterG said.)

[Manzolli]

Agree with Norbert B, the order should be like in the shift register and the initialization terminal should hang at the bottom. Kudos!

[GregSands]

Now that I am programming FPGAs, I can definitely see the need for this.  And like Darin said, it would be great if the Initialize (and Enable?) were movable to the top, and then the most recent value would always be next to the Initialize Terminal.

[)]

In great support of PaulRB's idea, I would add the following suggestions:

N.1 Proposed functionality

N.2 Proposed operation

N.3 Explanation / justification

1.1 Ouput mode choice for n>1 in z^(-n):

a) Stacked outputs (perhaps even selectively)

b) Output cluster (all data from previous loops)

1.2 Via configuration panel

1.3 Many applications require a significant amount of z^(-n) data, wiring hundreds of data points is a little sub-optimal. This is of particular relevance where data would have to be recompiled to a cluster or array, e.g. to generate a waveform. Examples include recursive system identification (often needing 1000s of data points for motion control), but even simply generating trajectories of motion to be overlayed to a video stream. One could argue to use a loop, but many applications need data points from a master loop, generated / acquired on-line, where internal loops won't help. One could also argue to use multiple feedback nodes, but this is clearly not very efficient, neither is "real estate" friendly. Think about just 100 data points including z^0, the minimum set one needs is 18 feedback nodes (e.g. data combined to blocks and staged by powers of 10), and even then, initialisation works by steps of 1 for the first 10, but by steps of 10 from 11 to 100, with the latter also being sub-optimal. Therefore, an output cluster option with al previous data (down to z(-n)) would be by far the most important to have, to my opinion.

2.1 External input option for negative horizon depth: n in z^(-n)

2.2 Via configuration panel, depth to be reinitialised on every input change (economic) or VI call (also ok), any currently unavailable data to be initialised as per initialisation terminal (e.g. when negative horizon is increased)

2.3 Again a system identification example seems most suitable: one would wish to be able to identify optimal negative horizons on the fly, either programmatically (e.g. driven by positive horizon [prediction depth], which in turn may be driven by physical data also automatically acquired) or via manual front panel control (e.g. when experimenting, prototyping, testing, etc).

3.1 Data loss control mode choice:

a) None (if data not acquired, iteration result isn't added to output cluster)

b) Padding (if data not acquired, iteration result is as per initialisation terminal)

c) Sample and hold

d) Sample and hold and interpolate (on next acquired data, hold until)

e) Aggressive integration (if data not acquired, propagate difference from previous step)

f) Conservative integration (if data not acquired, propagate total accumulated difference from output cluster accumulated so far)

3.2 Via configuration panel

3.3 These modes are trivial ones, of course, but may prove useful, and could well offer efficiency / speed advantages compared to case structures. Modes c) d) e) may produce interesting results if the input type of the ominous feedback node is, say, a string, but these modes could be set to work on numeric data only (e.g. forcing everyithing non-numeric to just sample and hold). Okay, all of it can be programmed easily, and the latter three are probably too application specific to include, but at least a) b) c) would be nice, wouldn't it?