LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

OOP Dynamic Dispatch Terminals

I'm fairly new to OPP.  I am coding a Parent Class with 3 Children, each child is a .NET controlled instrument from a different vendor.

I have inherited code for one of the instruments.  In that code, a DVR is used to hold the .NET reference, I'm assuming this is to avoid memory leakage, this is important to us as the application must run for many months of manufacturing and be robust.

When I add the DVR control to the Class .ctl cluster, the DVR does not appear when I unbundle from the Class wire.

 

Is there a design guide for this scheme?  It's not practical for a Class wire to run between all the VIs in the large project, so I do need some type of Functional Global that will allow me to access the Class information without the wire present.

I do need the wire where I use dynamic dispatch to correctly select which instrument is installed. 

 

DVRcall.JPG

DVR.JPG

 

0 Kudos
Message 1 of 5
(420 Views)

A DVR holding a .NET reference does nothing to avoid memory leakage.  Memory leakage happens when a program allocates memory for a task but either doesn't deallocate it when done with it and/or continually grows in size.  If you want to avoid memory leakage with .NET over a long time, you need to make sure that you run LabVIEW's "Close reference" node on each .NET object that you are done using, plus any "close" or "dispose" or other similar methods are offered by the specific .NET classes you are using.

 

A DVR does two main things in LabVIEW.

 

First, it allows the same set of data to be accessed and modified in divergent code branches even after a DVR wire has been forked, in contrast to LabVIEW's usual "by data" style of information transfer over wires which would normally make separate copies.

 

Second, it provides a built-in system for preventing race conditions when used properly.  When an "in-place" structure is used to get and then set the value of a DVR at any particular moment, no other instance of that DVR can be running at this time.  This prevents parallel code from trying to do two "read then modify then overwrite" operations at the same time.

 

You only post screenshots, so I can't see what's going on with your class control and what's in the other case of the case structure, so it's hard to be completely sure what's going on.  So this is a bit of a guess.  I would also note that I see zero ".NET" wires in the screenshots so it's impossible to give advice there.

 

What it looks like is that a DVR is being created, then turned into a Variant, then stuffed into a named Notifier.  Then, whenever it's needed in the code, the DVR's notifier can be obtained by name and data type only, removing the need to run new wires everywhere.  If used properly this can work, but you have to be sure that you do it correctly.  "Correctly" in this case means that it needs to create the named notifier once, then re-use it as much as needed until done, and only at the end destroy it.

Message 2 of 5
(398 Views)

@Kyle97330 wrote:

What it looks like is that a DVR is being created, then turned into a Variant, then stuffed into a named Notifier.  Then, whenever it's needed in the code, the DVR's notifier can be obtained by name and data type only, removing the need to run new wires everywhere.  If used properly this can work, but you have to be sure that you do it correctly.  "Correctly" in this case means that it needs to create the named notifier once, then re-use it as much as needed until done, and only at the end destroy it.


A much simpler way would be to hold the class DVR in an Action Engine.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 5
(371 Views)

Many thanks for the replies, I am keen to get the architecture correct before I spend more time coding.

The full project is 188MB and can be download from this link

https://we.tl/t-gY7MHTjCnr

Link expires on 21st of June 2024.

 

I want to access the ClassData and the .NET references in a way that does not require continuous wiring.

A typical VI that uses motion might call 5 VIs, wires between those 5 are okay.

I need to avoid issues with memory leakage or too many references open as it's a manufacturing application that must be reliable.

I understand the concepts of OOP & Functional Globals.  The concept behind ACTOR and how to design and implement is new to me.

 

0 Kudos
Message 4 of 5
(295 Views)

More recent version of Project here for service request# 03033363

https://we.tl/t-XNLJwui11t

 

0 Kudos
Message 5 of 5
(240 Views)