wire Class into DVR

[James_W]

Have I missed something...

Is there a bug in LV 2020 that I haven't found on an issues list?
I've got some code. I'm looking to replace some clusters with a "ResultsData" class.

The data was being passed around previously by a DVR.

This document suggest I should be able to do this:
Reduce Memory with Data References - NI
however everytime I try to wire my class control into the "New Data Value function" I get a broken wire.
I can do this successfully for the output of the reportgen toolkit create report VI - but not my own class (with children).

(I'm not looking to have a debate about the whys of the program structure - it's evolving in the direction I want but it is not there yet).

What have I missed?

Thanks

James

[Kyle97330 · Accepted solution]

It's a class permissions thing.  Do it inside a class member, or go to the class properties and uncheck this box:

[James_W]

Thanks Kyle,
Wasn't sure if I was being totally stupid and missing something like that - or if there was an open CAR. (I had a vague recollection of seeing a CAR about it being broken in previous years - good to know it's just me!)
😁

[Mark_Yedinak]

Personally I prefer to put the class data into a DVR and include that DVR reference in the class private data. I just pass the class wire around and not a reference to it. The net effect is the same but I view it more a true encapsulation. One might argue that it is clearer that it is a by-reference class if you pass the class DVR around rather than a simple class wire. However, I prefer encapsulating the DVR rather than passing it.

[rolfk]

I would agree Mark. But just saw a neat trick yesterday from a colleague. If you have a DVR containing a class, you can use a LabVIEW property node directly on that DVR wire too to access the class properties. Certainly surprised me!

[drjdpowell]

---

@Mark_Yedinak wrote:

Personally I prefer to put the class data into a DVR and include that DVR reference in the class private data. I just pass the class wire around and not a reference to it. The net effect is the same but I view it more a true encapsulation. One might argue that it is clearer that it is a by-reference class if you pass the class DVR around rather than a simple class wire. However, I prefer encapsulating the DVR rather than passing it.

---

Depends if it really is a by-ref class, rather than just a class that in this specific application is being shared between components using a DVR.  The OP's description of "Results Data" "being passed around by a DVR" sounds like the later to me.  If the Class has no inherent reason to be by-ref, and the DVR is a design feature of the application, then it might not make sense to tie them together.  Another application, reusing the Class, may wish to use it by-value.

[James_W]

It's more about memory management...
I have alot of huge datasets
Passing around a DVR to the different modules (using the QMH - I don't need need to go down that rabbit hole James😉) seems to save me a memory copy between the enqueuing module and the dequeuing module.
Because the dequeuing modules all run at different speeds and do different things with the data, I can't use the same DVR for each data set (unfortunately) - so I need to pass the data by value eventually.
Classes allow me to share some of the common features that the pre-processed data has (such as timestamp of acquisition) and then have child classes of the processed data type. -which is then handles differently by different modules.

What I'm getting to now is cleaner than having a mega cluster of all data for single enqueues and arrays of the post-processed data for multiple enqueues.

- It's one of those challenges of picking up old code. 😊


Thanks for all the feedback

[Yamaeda]

---

@Mark_Yedinak wrote:

Personally I prefer to put the class data into a DVR and include that DVR reference in the class private data. I just pass the class wire around and not a reference to it. The net effect is the same but I view it more a true encapsulation. One might argue that it is clearer that it is a by-reference class if you pass the class DVR around rather than a simple class wire. However, I prefer encapsulating the DVR rather than passing it.

---

Which is exactly what G# does, with some added tools for garbage collection, icon generation and folder creation as part of creation or cloning. 🙂

[drjdpowell]

---

@James_W wrote:

...seems to save me a memory copy... 

---

By "seems" do you mean you have measured this, by benchmarking or something?  Passing an Object through a Queue doesn't inherently involve copying, and many reasons that due cause copying are not solved by using a DVR.  

[James_W]

---

@drjdpowell wrote:

---

@James_W wrote:

...seems to save me a memory copy... 

---

By "seems" do you mean you have measured this, by benchmarking or something?  Passing an Object through a Queue doesn't inherently involve copying, and many reasons that due cause copying are not solved by using a DVR.  

---

By watching the RAM usage of rhe program before and after the DVRs were introduced - the data sets are big enough to see a visible change.

I didn't believe my colleague when he told me I needed to either - but It's about not assigning huge amounts of memory to a queue that then won't be released until the queue is closed. by assignng the DVR to the Queue the queue memory doesn't creep up so much and the whole app is more stable memory wise.