LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Data Value Reference always referring to control?

What I'm wondering is, can a DVR be self-contained? I tried using this setup:

 

ref.png

Some testing seems to show that this works, the reference does not become invalid. It does feel though like this is not how DVRs are supposed to be used. Comments?

 

Lars Melander
Uppsala Database Laboratory, Uppsala University
0 Kudos
Message 1 of 7
(2,918 Views)

Actually, I'm the one confusing this type of reference with other LabVIEW reference types, aren't I? It is supposed to be self-contained and work exactly as in the picture.

Lars Melander
Uppsala Database Laboratory, Uppsala University
0 Kudos
Message 2 of 7
(2,878 Views)

Lars,

 

maybe you should elaborate in detail what you try to achieve with this.

Do you try to create something like a linked list (which requires each element to store a "This" reference)?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 3 of 7
(2,871 Views)

DVR's have nothing to do with Controls or Indicators on a front panel.

DVR are a reference to a memory allocation. That is why you need to make a DVR, so that the memory for the data is allocated.

DVR's can be shared cross VI's and will not have any impact on the performance, as a reference to a Control or Indicator has when working with those.

 

As DVR's are not linked to a front panel object, when working on the DVR's data, the code execution is not moved to the UI thread.

DVR's also has build in security for reading and writing multiple places. You can only read or write to a DVR's memory one place at a time.

 

Does this help you?

 

0 Kudos
Message 4 of 7
(2,870 Views)

@Norbert_B wrote:

Lars,

 

maybe you should elaborate in detail what you try to achieve with this.

Do you try to create something like a linked list (which requires each element to store a "This" reference)?

 

Norbert


That's not really important. The only important part (for me) is that I connect any random wire to the "New Data Value Reference" function and it will always work. It was not clear to me how the actual value was stored, if it was guaranteed to exist until the reference was destroyed.

 

The way other references are handled had me a bit confused.

 

Lars Melander
Uppsala Database Laboratory, Uppsala University
0 Kudos
Message 5 of 7
(2,863 Views)

@LarsM wrote:
[...] The only important part (for me) is that I connect any random wire to the "New Data Value Reference" function and it will always work.[...]

 


That is exactly the point of DVR as it creates a handle to the original dataspace the data is located in (compare to a pointer in C).

OK, there are some specific exceptions, but New Data Value Reference will accept all other datatypes.

 

hope that clears it up,

Norbert

 

PS: Releasing the DVR does not necessary delete the original data. You simply remove the handle to it.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 7
(2,855 Views)

@dkfire wrote:

DVR's can be shared cross VI's and will not have any impact on the performance, as a reference to a Control or Indicator has when working with those.

 


It seems to me performance does take a hit. Accessing a value through a DVR seems to as much as 30 times slower than accessing a value directly. But yes, still much faster than a control.

 


@dkfire wrote:

 

Does this help you?

 


Well, it does confirm some of my thoughts. Thank you.

Lars Melander
Uppsala Database Laboratory, Uppsala University
0 Kudos
Message 7 of 7
(2,852 Views)