External DVR?

[Stobber]

http://zone.ni.com/reference/en-XX/help/371361L-01/lvscript/datavalrefnum_isexternal/

 

I just found that by accident while clicking around in a class typedef that contains a DVR. What does it do?

Edited March 20, 2016 by Stobber

[MikaelH]

I’m as puzzled as you.

When ticking External, the wire becomes of a differnt type.

But I can't understand how you could create an "External" DVR.

[PiDi]

According to this: http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/external_data_val_ref/#EDVR

 

Storing and Reducing Copies of External Data

External data value references are similar to data value references except they work directly with data owned by components external to LabVIEW, like the direct memory access (DMA) buffer of a device driver that controls a data-streaming device. You can work with this external data without incurring a copy to bring the data into LabVIEW. If a device driver supports an external data value reference, you can interact with the external data similarly to the way you interact with data value references. You also can use the Advanced TDMS VIs and functions to interact with external data value references.

I've never used it, but I know at least one place where they're created: the DMA read/write to FPGA (http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqwrite/ and http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqwrite/). And then you can use them with Advanced Data Reference I/O from TDMS pallete. It seems like the code in the following picture might have some magical properties, like reducing the memory usage, or enabling really fast data transfers from DMA to files... Has anyone ever used this?

[ShaunR]

Oooooh. Memory mapped files as a DVR?

[hooovahh]

The TDMS use is the only one I can think of too.  Basically if we have data on an FPGA and we want to log it into a TDMS file on the host side, then the old method would be to transfer using a FIFO over from the FPGA to the host (making the data in two places), then write it to a TDMS file.  The DAQmx VIs have the ability to log directly from hardware to disk.  So this means instead of reading an AI from the hardware (which makes a copy) we can log directly from the DMA of the hardware, and log it to disk.

 

This FPGA external DVR is apparently the same thing.  Log directly from the memory on the FPGA to disk, without making copies, without extra data transfer, and reducing that load from host operations.  Personally I've never done this but it is a neat concept if you have lots of FPGA data and just want to log it, of course in practice I think I'd want to do more than just log it.

[Stobber]

Definitely sounds like another language feature hacked in to support the improvement of NI-internal APIs. I wonder if there's any intent to publicly document it better with examples of creating, say, a DLL that uses this feature to share data with a LV app.

 

I also wonder whether the Scan Engine exposes a similar feature to NI-RIO that lets me post scanned values directly into a file!

[ned]

This could be useful for transferring data to an FPGA, not just from it. I wanted to use an external DVR on a project that involved an sbRIO, but unfortunately the board didn't support the Acquire Write Region method. That project involved driving an inkjet printhead. The FPGA tracked encoder counts, enabled individual nozzles in the printhead, and triggered the printhead to fire. The image to be printed came in over a TCP connection. One major problem was there was no way to avoid making multiple copies of the image in memory, even though the actual content didn't change. First, converting the string (from the TCP connection) to integers (DMA FIFO format) incurred a copy, and then a second copy occurred to copy the integer array into the DMA FIFO. Direct access to the FIFO memory area would have eliminated the second copy (and if this idea were implemented, it would have avoided the first one). I benchmarked the performance carefully, and each copy of a multi-megabyte file turned out to the be comparatively time consuming.

[Stobber]

One major problem was there was no way to avoid making multiple copies of the image in memory, even though the actual content didn't change. First, converting the string (from the TCP connection) to integers (DMA FIFO format) incurred a copy, and then a second copy occurred to copy the integer array into the DMA FIFO.

 

Honestly, the solution to that problem is to write a C application using the NI-RIO C API instead of LabVIEW.