Efficient way to use DVR in DQMH modules

[AdarshaPakala]

Hi,

I need to transfer large streaming data from Hardware DQMH module to Processing DQMH module and to Display DQMH module. The data comes in as one large size data packet, let’s say one data packet is 1500 samples X 8 channels for every 50mS and its continues.
I’m planning to use DVR for transferring the data packet between DQMH modules. Can some one suggest me the efficient(resource and execution speed) way to use the DVR and which would be the better approach;

1. Create and close the DVR for every data packet(every 50ms)

2. One DVR and write the data packet to same DVR (every 50ms), provided data overwritten is taken care.

Thank you

Adarsh

LabVIEW from 2006

CLA from 2014

[drjdpowell]

I've been looking into using DVRs like this recently; go with Option (1).

[Olivier-JOURDAN]

Definitely Option #1.

I managed to stream continuous data from a 3,7 MHz DAQ board for multiple channels using this method. It's very efficient, and you don't have to bother with DVR overwrite.

Bonus tip: you can use the Time node in the event structure to know if you are processing data fast enough

That being said, before going that way, I'd try to use a usual broadcast to transfer your data. Depending on the performance of your computer, I think events can handle this amount of data.

[joerg.hampel]

I guess that it's alright to send the DVRs via plain old broadcasts, right? Seeing as it's only the reference we're sending, we don't need to be concerned about the data copies which the event system creates ?

[Olivier-JOURDAN]

---

@joerg.hampel  a écrit :

I guess that it's alright to send the DVRs via plain old broadcasts, right? Seeing as it's only the reference we're sending, we don't need to be concerned about the data copies which the event system creates ?

---

If creating a broadcast with an array in the first module and registering the second module to listen to the broadcast is not performant enough, it's fine to replace the array with the DVR ref. I'm not aware of any data copy doing that.

The trick of option #1 is to set the value when you create the DVR and retrieve it. When you destroy the DVR, you never have to read or write the value.

[AdarshaPakala]

Thank you all for your reply! It is really helpful.

The trick of option #1 is to set the value when you create the DVR and retrieve it. When you destroy the DVR, you never have to read or write the value.

this looks like a neat method.

Im interested to know DVR create and destroy time, how does that grow with data size? Has anyone got a chance to examine that ?

Thank you

[Taggart]

It's basically just a pointer, so I imagine it doesn't care at all what size the data is.

[drjdpowell]

Note: if you are going to broadcast DVRs, where you aren't 100% sure someone is listening for them, you might want to put in a guard against a memory leak, such as this code which will prevent more that 10 DVRs existing:

[Ozfarmboy]

Is the constant allocation/deallocation of memory occurring because DVRs are being constantly created/destroyed going to create a determinism issue?  I am think especially for RT here. 

Or does the DVR have this problem anyway, since it's just a pointer?

[T.L.]

Hi,

if you want to use DVR's for transferring large data and want to use the same data in multiple places like shown in the image, a simple DVR will not be sufficient.

Only 1st Receiver of DVR will get the data...

With a single DVR a handling of receive acknowledgment is required.

Or each receiver gets its own DVR. But i guess this will result in data copy.

best regards
Thomas