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.

[chris_d754]

I like the idea of having the history function added to the feeback node. Potentially useful. I wouldn't want it as an array output, but have it like the shift register with a expandable drag with each item separate.

[tst]

If you want a circular buffer today, you can use a queue of a fixed size and use the lossy enqueue function. You can read the data using the queue status function with T wired to the return terminal. The syntax isn't as minimal as what you propose, but it does have the advantage of allowing multiple writers and readers more cleanly.

[crossrulz]

There is also the Data Queue PtByPt.vi that does the circular buffer for you.

[AristosQueue (NI)]

D* --

I don't know you and you don't know me in real life (I don't think), so please be aware: my intent is to criticize this code, not your skills as a developer overall. This code you have proposed is a pretty bad design and adding your requested output would make it worse.

a) That circular buffer you've drawn doesn't have a way to do a dequeue without enqueuing more data. That's just a delay pipe. A circular buffer needs to be able to dequeue down on its own.

b) The picture you've drawn is also horribly inefficient -- makes a full copy of the circular buffer every time that VI runs in order to populate that array output.

There's no way I would ever turn to the shift registers as a way of creating a circular buffer. I certainly wouldn't make it worse by having a circular buffer that has to make a copy of its full contents on every iteration. That negates the value of the circular buffer -- you might as well just do an array in a shift register at that point.

As the others point out, there are ways to write actual circular buffers in LabVIEW. I suggest you investigate them.

[falkpl]

I like it:

On AQs critisim  (1a) you can easily access the data from this structure without enquing using the enable input, set this to false you now have an read history feature.

1b yes this is a bad picture and not how D* would implement it (I know him personally and is an exceptional programmer) I am sure he would have a preallocated array with read write pointers this takes a few minutes to implement for each data type.

Yes point by point does a circular buffer but only for numerics,  what about clusters and complex data structures.  Labview doesnt let us greate generic functions like the <Templates> in some languages so utilizing the feedback is quick and dirty.

As for queues, how do you access all elements in the queue at once?  I know how to peek at the front of the queue and get the status but this doesnt give me all data in the queue.

[falkpl]

I will look into the Queue for returning all elements.  I still would like to have access to the history of the feedback node.  I  Find this a very nice function that is much quicker to implement than the queues, the queues do have alot to offer.

[AristosQueue (NI)]

> As for queues, how do you access all elements in the queue at once?  

Flush Queue function.

[chris_d754]

Get Queue Status will also return all the elements. But you must wire a TRUE to the get "return elements (F)?" terminal.

[falkpl]

Flush Queue would remove all elements, not necessarly what I was looking for, but queue status seems to do the trick.

[AristosQueue (NI)]

Just be careful with Queue Status. I've seen many people code themselves into a race condition. They check the queue to make sure X is true and then, before they can act on that information, parallel code dequeues or enqueues such that X is no longer true. I generally waive people off of that function for anything other than debugging.

Also, Queue Status (when the "get elements" terminal is wired true, but only when it is wired) does make a full copy of the contents of the queue (because it will be hit in parallel so it cannot just use the copy inside the circular buffer inside the queue). So you do take quite a hit on large queues when looking at that information.

Flush queue avoids both the data copy and the race condition dangers by moving the contents of the queue out into a separate buffer for you to consume.