LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Fox_Mccloud

Data Value Reference (DVR) implementation in DAQmx and TDMS

Status: New

Hi Guys!

My idea is quite simple. What I would like to do is to use DAQmx Read and Write to accept a DVR as input so that I can read/write data directly to memory. This would be really appriciated if it could be applied on a TDMS read/write also (i know that there is a feature like this in TDMS now but it is only applicable on external dvrs).

 

 DVR.png

 

Pros: Everything

Cons: None

 

🙂


Sincerely,

 

Andreas

 

 

 

8 Comments
Yamaeda
Proven Zealot

Yeah, it'd clean up some code instead of having In-place elements all over. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
ConnerP
Member

I know this is an old post, but I am curious: what would be the advantage of this compared to acquiring a DVR reference directly after the read? I would expect the obtaining of a DVR to an array has approximately zero overhead. The only advantage here would be if the DAQ processed received the DVR from outside and automagically pushed the data into it for another process with a copy of the DVR to receive. Or am I missing something?

wiebe@CARYA
Knight of NI

A DVR after the read would require two (potentially large) arrays in memory.

 

Accepting a DVR would enable reuse of excising memory that is also shared by parallel running VIs.

 

So I guess, yes: "The only advantage here would be if the DAQ processed received the DVR from outside and automagically pushed the data into it for another process with a copy of the DVR to receive. ". But that could make a big difference.

ConnerP
Member

I don't see how there would be two instances of the data if the wire goes directly to the New Data Value Reference VI without branching? Surely that does not create a copy. I admit, if you want to push the new data into an existing DVR, this would be a bit cleaner than the In Place Element directly after the read, but otherwise I don't see the advantage?

wiebe@CARYA
Knight of NI

There will be data in the DVR (e.g. from a previous cycle), and the data read by TDMS. That is two sets of data... I never said "copy".

ConnerP
Member

Okay, so you are assuming a single long lifetime DVR for this piece of the program. In that case, could the goal of this then not be accomplished by doing the read operation inside of an in place element where the old value is not wired?

wiebe@CARYA
Knight of NI

>Okay, so you are assuming a single long lifetime DVR for this piece of the program.

 

Yes

 

>In that case, could the goal of this then not be accomplished by doing the read operation inside of an in place element where the old value is not wired?

 

Yes. I think the idea is we won't have to do that anymore.

ConnerP
Member

Okay. Gotcha. It does seem useful, albeit for a very specific and, likely, less than common case.

I am just getting into using DVRs now since I'm doing extending DAQ in the 10s of MHz rates and moving that payload around a lot. As such, I'm not so well versed in them yet. I wasn't trying to shoot this down, just trying to understand the context and DVRs in general a bit better. Thanks for the discussion.