Why can't I use a DVR from a dynamically called VI

[Ben]

---

@oenk wrote:

Hi Jarrod and Ben

thanks for your replies so far.

Actually I'm not having problems with the DVR per se but with a GOOP4 class. I just tracked the problem down to that...

I was trying to load a GOOP3 class dynamically which has a GOOP4 class as member but I wasn't able to do so. Maybe the guys at symbio already came up with a solution to my problem.

Also I thought as long as the ref to the VI isn't closed the data-space of that VI is kept alive

---

It used to but "not any more"!

back in about LV hmmmm... 5.0, if you failed to close aref it stayed open. Trying to re-run code rewsluted in resource not available ... re-boot to clean it up.

quoting myself (from many other threads like this one) ..."The LAbVIEW Clean-up routine is your friend", but like a and faithful dog, you just have to know what not to do to keep it from biting you.

Ben

[oenk]

Thanks for the update. I try to keep that in mind...

[JanK · Accepted solution]

Hi

The problem with garbage collect of references is well known. In GOOP4 we provided a solution for it. If you right-click on the lvclass in the project you will access all GOOP features. Select Add Design Pattern.

We use the concept of design patterns to add features to an existing class to minimize the code generated into the class from the start.

There is one design pattern called "Make Persistent" (or something similar, I don't have LV open now). Choose that. It will post the GOOP4 DVR ref to a VI running in the background and therebuy prevent garbage collect.

In GOOP3 we haven't a built-in solution but you can get the same problem. In GOOP3 each class has a repository built using un-initialized shift registers and to preserve the GOOP reference you need to make sure the repository is not unloaded from memory. This can be done for example by opening a VI reference to the class create method and make sure that that VI ref is kept in a running VI during program execution. If you are using inheritance it is sufficient to keep the create method at the lowest child level in the inheritance hierarchy in the memory.

In your case you may have to apply the solution to both the GOOP3 class (since you say it is loaded dynamically) and perhaps also the GOOP4 class. It depends on the scenario in which the GOOP4 object is created. But if you load a GOOP3 clas dynamically and it in turn creates the GOOP4 object then it should be sufficient to solve the issue for the GOOP3 class.

Thanks,

Jan Klasson

Symbio

[oenk]

Hi Jan

thank you very much for your reply. I took an early weekend last week, so that's why I'm replying so late.

With the GOOP4 class everything worked like you said. If only everything is as simple as that....

However I'm having some difficulties with the GOOP3 classes. I tried nearly everything to keep that class in memory. From your suggested approach to keep the reference of the create-method in memory to an action engine to keep the reference in memory. But it is not working. I'm opening a reference to a file in one of the dynamically loaded GOOP3 classes but I can't access it afterwards from a base class. Could you help me out once again?

thanks in advance

Christian

[oenk]

hmmmm, I can't edit my last post....

so I add a new reply...and edit it in here

---

@oenk wrote:

Hi Jan

thank you very much for your reply. I took an early weekend last week, so that's why I'm replying so late.

With the GOOP4 class everything worked like you said. If only everything is as simple as that....

However I'm having some difficulties with the GOOP3 classes. I tried nearly everything to keep that class in memory. From your suggested approach to keep the reference of the create-method in memory to an action engine to keep the reference in memory. But it is not working. I'm opening a reference to a file in one of the dynamically loaded GOOP3 classes but I can't access it afterwards from a base class. Could you help me out once again?

thanks in advance

Christian

---

I messed something up....it works like you described it....sorry for any inconveniences...

btw: GOOP rocks

Thanks to everybody who helped me: Ben, Jarrod and Jan

[JanK]

Hi,

Ok, well it may have to do with in which order you do the steps or that the VI ref is GC by LV, there are some pitfalls.

- So, before you run Create to create a new object you should ensure that a VI ref to the create method is persistently stored in your process VI. If you do it afterwards, LV may have time to off-load the GOOPkernel from memory or do GC on the GOOP ref.

- The process VI that should keep the Create VI ref in memory must always run. And, if you run the process VI with front panel closed you must prevent LV from doing GC on the process VI itself. LV detects that a VI is running with closed front panel and no other code refering to it and concludes that it doesn't need to run, so it will do GC of your process VI if you don't prevent it. The easiest way to avoid that is to have the process VI open a VI ref to it self!

I guess the quickest way for you to create this process or deamon code is to simpy create a GOOP4 class and add the active object design pattern to it. The active object design pattern adds a process VI to a class. You can select one process for the class or one process per object instance. Use this active object class as a persistent repository for your GOOP3 create VI ref.

Thanks,

Jan 

[JanK]

Ok, I just saw you already got it working. Good:-)

I agree, GOOP rocks.

Jan

[Rollin_McCarty]

Hi Jan,

We have a GOOP 3 "Descendant" class that inherits from a GOOP 4 "Base" class.

We started to run into the same error 1556 error when creating instances of Descendant from within a dialog running in a subpanel. The same code ran fine when the dialog was a normal popup dialog and not a subpanel. The issue was that at the end of the application some Descendant instances would return a dead DVR reference in the destroy method and we would get error 1556. I applied the solution you speak of (i.e. project: class > GOOP > Add Design Pattern: Adding Persistant Option for Class) to our Base class, but now I get error 1556 all the time, immediately after creating the Descendant class. The error occurs inside the Base_New.vi, in the No-Error/0/True case, titled "This object should be created in Persistent Mode.

I.e. a background spawning VI (Process) should create the object and send the reference back to this VI.".

Indeed "Preserve Run-Time Class.VI" is presented with inputs Object In = GOOP 4 base class instance, and Target Object = GOOP 3 descendant class instance, which generates this error:

"Error 1446 occurred at Preserve Run-Time Class in Base.lvclass:Base_New.vi:1->Base.lvclass:Base_Create.vi->Descendant.lvclass:Descendant_Create.vi:5->0_UnitTest_Descendant.vi

Possible reason(s): LabVIEW:  The class of object in did not match the class of target object at run-time."

Any help you could provide would be greatly appreciated,

Rollin McCarty

Contractor at 3M

[JanK]

Hi

Without looking at the actual error codes...

The tool prevents inheritence between mixed class templates so how did you get that working? Using inheritance and mixing GOOP3 and GOOP4 in the same class hierarchy isn't supported by the tool. The reason is that there is an interaction between sub kernels and GOOP3 and GOOP4 are totally different.

Jan

[Rollin_McCarty]

Jan,

Thank you for your reply. I learned from you that a Goop 3 class should not inherit from a Goop 4 class.

You also asked how I got a Goop 3 class to inherit from a Goop 4 class. I followed this procedure:

1. LV > TOOLS > GOOP > CLASS PROVIDER OPTIONS > "Endevo GOOP 400"
2. Create GOOP 4 class "TOP".
3. LV > TOOLS > GOOP > CLASS PROVIDER OPTIONS > "Endevo GOOP 300". Note also that our legacy classes are Goop 3.
4. New Goop Class "G3".
5. G3.lvclass > Properties > Inheritance > Change Inheritance > "TOP.lvclass": Inherit From Selected.

Notice now Goop 3 class inheriting from a Goop 4 class:

View > LabVIEW Class Hierarchy : TOP (Goop4) <---is a ---- G3    (i.e. ).

Rollin