Data Value Reference - Is there any value to this methodology?

[DailyDose]

Please take a look at the photo. Yes, this is a garbage VI.  I'm just trying to make something that sums up what the end game Framework would look like.  Is there any value to making Data Value References out of References and then passing those onto asynch VIs where they can be accessed as seen?  There just seems something redundant about it.

 

[santo_13]

Not much value. You use Data Value Reference to pass large datasets without creating duplicates and to work on the original data source.

Since the control reference is a "reference" with no value, creating a reference to a bunch of references does not provide any advantage.

[mcduff]

Maybe something like this would be better.

[DailyDose]

---

@mcduff wrote:

Maybe something like this would be better.

---

So really, this methodology only useful for indicators and not controls. Just use regular references for controls? But then, the methodology in your VI, there's an ongoing loop that just reads data? Are notifiers required to avoid any race conditions?

[mcduff]

---

@DailyDose wrote:

---

@mcduff wrote:

Maybe something like this would be better.

---

So really, this methodology only useful for indicators and not controls. Just use regular references for controls? But then, the methodology in your VI, there's an ongoing loop that just reads data? Are notifiers required to avoid any race conditions?

---

No race conditions with DVR, like a FGV, do not support concurrent write/read access.

Only recently has parallel read access been added.

I know your example isn’t a real application, but what are you trying to do? You want to update a control from an asynchronous process? You could always read the DVR and update a local variable for your control.

[mcduff]

Here are a couple of screenshots for my DVR use cases:

Full Dataset is decimated and then scaled and put into a "PlotDVR". Using the the DVR allows me to send a reference to other loops rather than the full dataset.After the data is decimated, a message is sent to another loop to read the DVR for display purposes.

[DailyDose]

---

@mcduff wrote:

I know your example isn’t a real application, but what are you trying to do? You want to update a control from an asynchronous process? You could always read the DVR and update a local variable for your control.

---

In one of my applications I was updating an indicator and a control.  I guess I'm trying to figure out what exactly is the value/benefit of Data Value References over regular references if I'm having to create additional loops that will read it back in order to update the Front Panel.  

[DailyDose]

In the Object Oriented realm, could you make a DVR of the object and pass that around to all the Asynch VIs?  I guess I could see some value in that.

[mcduff]

I believe there are OOP objects that are based on reference rather than value, see

https://devs.wiresmithtech.com/blog/by-value-vs-by-reference-in-labview/

https://labviewwiki.org/wiki/GOOP_-_Graphical_Object_Oriented_Programming

[Mark_Yedinak]

A reference to a reference is never necessary. You are simply adding a second layer to access the data. If you are simply trying to interact with front panel controls and indicators then all you need is the reference to the desired controls or indicators.

Now for a more philosophical perspective, unless the subVIs or asynchronous tasks are strictly for working with the UI you should never pass references around that your lower level code uses to update to the UI.  All this does is create coupling between your code which makes reuse much more difficult. For example, some lower level code processes some data via some algorithm or transformation. The code doing this should ONLY do that. It should have no concept nor should it care with how that resulting data will be used. If it also updates some control or indicators on the UI than this code is forever locked to a UI with that same control or indicator. If this same code were used and rather than display the data you wanted to simply log it somehow it would be difficult to reuse the code. You would have to create dummy controls/indicators so you could pass them into the subVI.