Circular Buffer with Reference

[mrsound]

I'm creating two measurement systems that will sample air with 13 and 10 instruments respectively. I communicate with the instruments through serial, MODBUS TCP, voltage and current. To be able to synchronize the data from the different instruments (that have their own data rates) into one data stream I basically need one circular buffer per instrument. I want to add to each instruments circular buffer in a separate loop for each instrument, and have a timed loop that saves the data to a file by reading all the instruments circular buffers. The circular buffers also needs to be able to give me data that is not the most recent data.

How can I create a circular buffer that I can add elements to in one loop and read from in another loop? I would prefer something that uses a reference that I can pass to both the instrument loop (producer) and the save data loop (consumer), just like the queue works in Labview, but I don't know how to implement this in a good way.

I use LabView 2010 Fall edition..

Thanks,

mrsound

[johnsold]

You can probably do what you want with queues.  To keep track of the number of elements in the buffer and to decide when to remove and replace an element you might create some wrapper VIs around the queue functions.

I have not worked much with classes (LVOOP) but I think they could be used.  Another approach is to use an Action Engine.  Search for Ben's Nugget on AEs for a comprehensive explanation of the concept.

Lynn

[tst · Accepted solution]

Native queues in LV 2010 allow you to create a circular buffer if you use the Lossy Enqueue primitive.

Caveats:

1. You have to specify the queue size when first obtaining it, so you can't resize it dynamically.
2. To read the buffer you need to use the primitive which returns the queue info and wire a T into the Return Elements? input (very important not to forget that). This will create a copy of the data in the queue.

[mrsound]

Great news, thank you very much!

[mrsound]

Is there an easy way to put the queue VI's in subVI's and have the terminals adapt to whatever format the data is in? Or do I need to create one VI per data type?

Thanks

[tst]

---

@mrsound wrote:

Is there an easy way to put the queue VI's in subVI's and have the terminals adapt to whatever format the data is in? Or do I need to create one VI per data type?

Thanks

---

No to the first and yes to the second. There are options, but none of them are probably what you want. You do need to ask yourself whether you need to wrap the primitives. This can have some great benefits, but isn't always necessary.

[Mark_Yedinak]

You can also use a standard message format which is a cluster containing a name/ID and a variant. This is a very flexible approach and can be used fairly generically. Only the sender and receiver need to know or care about the actual data. This works nicely in state machines since it can easily process different message types with different data types.

[ragu_C]

Hi,

My application is,

I am getting physical data for 'n' number of channels @ max of 2MS/sec sampling rate. I have configured one of my channel as triggered channel. Whenever trigger is captured, I should log the data for 1min (@max) before and after my trigger in a file. So here i have to store the required data in a buffer.

Existing Logic,

For creating buffer, I have used two number of queue (one is for before trigger and another one is after trigger) and while enqueue the data, i am using 'Lossy Enqueue Function'. Here before my trigger, i should have latest 60 Sec of data and after my trigger i should have first 60 sec of data. Once i receive the expected number of datas, i will flush the queue and log the data in TDMS format.

Data representation is 2D Single.

Problem,

If my queue size goes more than 500, LV gives 'memory full' message and aborts the operation. If i go with file storage format(for making buffer), i have to be taken care of some file merging operation to make sure the data for before trigger and i feel that it is very complex.

It would be really great, if anyone suggest some better idea.....

Thanks