Class Data inside DVR being deleted

[chris754]

I have a strange issue. I have a queue with class data. On an event, I dequeue a class element and put it into another array (for historical purposes). While in this event the data in the class is fine, I can read it. However, once the event ends, the data is lost. However, I can prevent this from happening if I use "Always Copy." Is this a bug? No where else in the code do I destroy the class data.

[chris754]

Note that the first image does not work, and the second does. The "Copy" VI is simply the "Always Copy" function.

[LogMAN]

I don't see any obvious reason why the data should be loss, however from these pictures it is hard to get many clues.

 

Did you check if there is any awkward call to your "Destroy" VI, that could lead to your situation? -> Check any parallel thread.

How does your "copy" function work? -> I assume you are building an entire new DVR.

What is the scope of the queue you want to add the element? -> As far as I know, a DVR is valid until no VI makes use of it anymore. Check if the references are valid and at which time they become invalid.

Last but not least: This is not standard LabVIEW OOP, as it would be impossible to wire a DVR directly to a class method. Are you using GOOP?

 

Could you provide a code sample, so we would be able to confirm that behaviour?

[drjdpowell]

Your images show neither the creation, destruction, nor actual use of your DVRs, so it's hard to be of any help.

As far as I know, a DVR is valid until no VI makes use of it anymore. 

Like other LabVIEW references, the DVR will be tied to the VI hierarchy that created it, and will be destroyed if that hierarchy goes idle.  However, unless the OP is using dynamic launching of asynchronous VIs, there will only be one hierarchy, so that wont be an issue.

[chris754]

I will try to make a test VI to show what is happening. The destroy VI only gets called on a shutdown event, and I'm sure that that has not been triggered. As far as implementation I take a labview class and stuff it inside a DVR and pass the reference around, I am not sure what the name is for this type of implementation.

[Neil Pate]

 As far as implementation I take a labview class and stuff it inside a DVR and pass the reference around, I am not sure what the name is for this type of implementation.

I think could be called "the more popular implementation of ByRef LVOOP"   or TMPIOBL, it just rolls so easily off the tongue

[LogMAN]

I think could be called "the more popular implementation of ByRef LVOOP"   or TMPIOBL, it just rolls so easily off the tongue

 

Yes, give me a tongue twister

My guess would be: "Data Value Reference Paced Object Oriented Programming" short: DVRPOOP

 

I am not sure what the name is for this type of implementation.

 

Trying to get back on topic: It's just a ByRef implementation of OOP, so no popular or super fancy name to it. The standard implementation would be ByVal.

[chris754]

Indeed, just plain-old byref oop. Anyway, I have found the error (sort of). I make a copy of the original data and put that data into the generate event VI. If I put the original data into the generate event, the problem goes away. I now just need to find a way around this. The data must get destroyed by labview at somepoint, however, I do not know why this is because the data was placed on a shift register, and therefore was still in use. Still working on a test VI for this (busy time of year right now).

[drjdpowell]

For reference, if you put some data into a DVR, it will continue to exist until:

1) you explicitly release the DVR.

2) the owning VI (the top of the call chain that created the DVR) goes idle (stops).

3) you access the DVR with an IPE structure and change the data.

 

LabVIEW will not destroy/change the data for any other reason.  It does not matter if you DVR reference (which is just a number) is in a shift register or not.

 

If you are "losing" your DVR data, you are either doing one of the above three things, or (4) you are losing the DVR reference number somehow.  

BTW, from your description I would guess that whatever code is receiving your "event" is releasing the DVR.  Thus if you make a copy it solves your issue.