Access a (delayed) Feedback node's internal memory, and make creating a circular buffer so easy!

[D*]

A feedback node is like a shift register.  Both elements can retain the past N values.  For a shift register you can access the entire internal memory by dragging down the left side terminals.  This is cumbersome if you just want a circular buffer. 

A feedback node is much more elegant for this task, however there isn't a way to access that memory.  If you could, you would make it extremely easy to make a simple circular buffer (oldest element is discarded, newest element is put onto the array).  It would be very useful, especially because the feedback node is polymorphic, and can take any data type.

[AristosQueue (NI)]

PS: What in the heck are you actually trying to do? Why does your caller need deep inspection into the buffer? Why can you not provide whatever that service is inside your action engine to avoid sending the data out? Everything you've posted points to use of code patterns that are things I generally teach as "bad ideas to even think about doing in LabVIEW". Your requests point to a poor delineation of responsibilities for various parts of the code, so I'm concerned that by helping you get this circular buffer idea working that I'm just helping you further down a dark, bad path.

[falkpl]

This mostly stems from a quick way of storing the last n samples of a given data type (any data type) with not spending much time implementing code.  Sometimes solving a prototype function quickly is economically the best option.  This is not the only solution to implementing this device, I almost always do this as a pre-allocated array stored inside of a functional global of a given type keeping track or read and write indexes, all very nice but this takes several minutes to implement.  Using a feedback node allows me to store a set of the last n samples - just would be nice to get a quick snapshot of what is in its history when needed.  This use case is tied to a loop and is not meant to be accessed in parallel so the use case i envision is not subjected to race conditions.  For me this is intended to solve a specific use case, where the primary goal is to minimize programming time especially during in the early algorithm design stages.  

[AristosQueue (NI)]

I see your use case.

Hm.

Generally, I don't like putting cruft that can end up in finished code into the product just to support debugging... it has a habit of ending up in finished code and then someone will complain that LabVIEW is slow (or, worse, they use those strategies and write benchmarks to prove LV is slow). *sigh*

Sometimes we add it anyway, but I always first try to look to see if a) we can get the IDE cost of the "right" solution down or b) can we add something that only works when debugging that satisfies the request.

In this case, I wonder if there is something we could do with "probing a node" that could show the circular buffer. There are several nodes that have state within them... we've discussed a probe on nodes instead of on wires that could show that internal state.