Stacking Plots generated on runtime - Multiple Sweeps

[Daniel_Novo]

I don't understand the feedback node construct. Particularly the "delay" option, which as I understood it by its help reading in english and german , was precisely the amount of data stored in the feedback loop. It is always hard to understand what a high level function is doing without actually knowing - accessing the code - what it is REALLY doing. 

The concept of minding the DATAFLOW is only truely aplicable if you know all the paths DATA can take. Having only access to the Help feels like trying to grasp the the morning traffic by looking at map. 

I give it try. Thanks. 

BR, D. 

[GerdW]

Hi Daniel,

---

@Daniel_Novo wrote:

I don't understand the feedback node construct. Particularly the "delay" option, which as I understood it by its help reading in english and german , was precisely the amount of data stored in the feedback loop.

---

The delay option doesn't apply to your code and you don't need to fiddle with it…

That option is related to the option of shift registers to increase their number of outputs at the left side of a loop: you get access to values of previous iterations (i-1, i-2, i-3,…) Setting the delay of the feedback node allows also to access values not just from last iteration, but also from more previous iterations… (And yes, this relates to "amount of data stored within the feedback node"!)

[Daniel_Novo]

Nowhere on the help is mentioned the feedback node is data storage. That everything that goes through it ends up stored. I wouldn't dare messing with the code. But knowing that a function is actually storing data is pretty relevant to understand the DATAFLOW. By looking at the code one might understand what it is actually doing.  Moreover, having the option to opt out of this storage (storage size same as delay size) can only be logical. After all a feedback node is function to process data. Logically process functions shouldn't be storing data. If anything memory usage would greatly improve. By adding the feedback node I've added a container that I never needed to be there in the first place. I just need n-1 not n-m for m loops. Imagine the size of this node if the user performs a 1 million sweeps without shutting down. All the more redundant if I consider I have an output for that data (graph or array) which should show only what I need and not all that has been - until now unknowingly - contained by the feedback node just because it went through it at some point in time.  In that sense, the delay is only indicating where the user access begins on the pile of data. It is the proverbial tip of the iceberg.  

One single sentence could  greatly improve the Help on the feedback node. 

The feedback node stores all data that goes through it. 

Anyway, I am new to this. I takes getting used to.

Thanks for sticking with it.  

BR,D. 

[GerdW]

Hi Daniel,

---

@Daniel_Novo wrote:

One single sentence could  greatly improve the Help on the feedback node. 

The feedback node stores all data that goes through it. 

---

Your sentence is wrong: the feedback node (or shift register) does not store ALL data that "goes through"!

It only stores the amount of data of the last iteration (and more previous iterations if configured for delay)…

I think the LabVIEW help is quite correct when it says for the Feedback Node:

Stores data from one VI execution or loop iteration to the next.

The help also says:

By default, the Feedback Node stores data from only the previous execution or iteration. However, you can configure a Feedback Node to store n samples of data by delaying the output of the node for multiple executions or iterations.

This describes how the delay works and how much data is stored within the feedback node…

[Daniel_Novo]

You wrote: 

LabVIEW basics: Data are stored in wires and feedback nodes/shift registers!

.. there's that.

And solution is to pass an empty array to the node. 

so... yeah. Let's just say it all makes sense. 

[Daniel_Novo]

Hello GerdW, 

I really gave this solution a go. Tried different strategies with all the tools on the waveform toolbox. Got it to point where it was satisfactory but not really what I needed. Left it there went back and gave it another go a couple of times. But I must say this solution is very limited and frustratingly unsatisfactory. Using time as data slicer presupposes a time invariant data acquisition which in reality never happens. So instead of having a simple indexing type of task one ends up trying to synchronize and time events. Adding unnecessary delays to try to equalize the acquisition time and so forth.   Although using waveforms to stack-up plots will render roughly stacked y coordinates, the x is always a bit here a bit there. X is never the same for each interaction and therefore never where it should be. Also to build a waveform one can only pass a single dt - again, time invariant data acquisition presupposed – and not an array. If the variation on dt is small (a guess about 5%) the plots will be okay. Not nice but okay. But as soon as the each point acquisition drifts more than that  the plot ends up distorted. So I have to restart the sweeps and hope I can get at least enough of them in without a time variance between data points. I've been exporting the data and plotting using different tools.

Anyway, I've learned a lot about labview and how it makes incredibly complex tasks easy and incredibly easy tasks almost impossible.

Thanks,

Daniel