How to share resource between 2 objects of a child class and a dynamic class loading practice

[GoKu25]

From the Class diagram, I have a DMM class that is implemented as an interface. It's methods get dynamically dispatched by NiDMM methods. A connection is opened by loading NIDMM class dynamically and the reference is stored in the base device class' IVI session private data for later use with the loaded NIDMM class.

Now I want to create more objects of DMM Class.
1.Is there a way to share the opened IO reference with other objects?
2.In order to use the other objects to measure,Do I have to load the dynamic VI everytime to use it's methods or is there a better way to do it?

[wiebe@CARYA]

It seems there's a bit more going on here than what you're sharig... But here it goes anyway.

---

@GoKu25 wrote:

1.Is there a way to share the opened IO reference with other objects?

---

Splitting the wire creates two objects. So with normal (not by reference) classes, it would be trivial to create a copy of an object.

If you want a new object, but with a shared IO reference, you'll need to make a Get Reference so you can read it and then set it.

As a side note: IIRC, the Get Reference method needs to be public, or the new object won't be allowed to use it even if it's the same class calling the method. This is kinda weird because the objects private data can be read with an unbundle.

---

@GoKu25 wrote:

2.In order to use the other objects to measure,Do I have to load the dynamic VI everytime to use it's methods or is there a better way to do it?

---

There is no need to load VI dynamically. Dropping the class constant on a diagram will instantiate an object without dynamically creating it.

It's not really clear to me what you're asking here. Normally, you won't need dynamic loading at all. You'd only need it when for instance the objects are in some kind of plug-in.

If the class is not in a plug-in, you would be able to drop the class constant on a diagram, and for instance in a for loop instantiate as many objects as you want. No dynamic loading involved.

[GoKu25]

Hi Carya

I'll try to provide as much information as possible. The Class diagram that I attached earlier is part of a HAL Library that will ultimately be used in Teststand. The NiDMM is a Plugin class and the DMM is the Interface class. There is a Pre-exisiting Teststand Program where niDMM is loaded dynamically and the object is used throughout the program.

Addressing your answers with more information for 1 & 2,

 The code for opening a connection with DMM instrument lies inside the NiDMM class. Since NiDMM is a plug-in class, DMM Interface class is used to do all the settings and acquisition to be dynacally dispatched later. The new requirement is to create different objects of DMM with associated config settings. They would require access to the IO handle for settings and data acquisition. Correct me if I am wrong as I am new to OOP, when I open a handle with a child class object (obj1, for instance) and write to the Base Device Class' private data with accessors, it can't be accessed by other child class objects(obj2, obj3,...).

Here's what my implementation is like right now based on the idea above,

During Initialization in TestStand, I load the NiDMM plugin dynamically and store the Object(obj0) in an Action Engine. As I create new objects of DMM, I'll store them in the engine as well and use it to customize the settings. When I have to acquire data from DMM, I call obj0 (dynamically loaded), open a connection->use the connection other object(obj1)-> get settings-> write settings to instrument-> acquire measurement-> Close connection with the obj0. Redo it with every other object. 

Will this work?

[wiebe@CARYA]

---

@GoKu25 wrote:

  The code for opening a connection with DMM instrument lies inside the NiDMM class. Since NiDMM is a plug-in class, DMM Interface class is used to do all the settings and acquisition to be dynacally dispatched later. The new requirement is to create different objects of DMM with associated config settings. They would require access to the IO handle for settings and data acquisition. Correct me if I am wrong as I am new to OOP, when I open a handle with a child class object (obj1, for instance) and write to the Base Device Class' private data with accessors, it can't be accessed by other child class objects(obj2, obj3,...).

---

You can make anything available, even private data, through an accessor\get method. That is not recommended, because it would expose the implementation. But it is possible. And sometimes it is needed, or at least hard to avoid.

Not sure what "open a handle with a child class object" means.

---

@GoKu25 wrote:

Here's what my implementation is like right now based on the idea above,

During Initialization in TestStand, I load the NiDMM plugin dynamically and store the Object(obj0) in an Action Engine. As I create new objects of DMM, I'll store them in the engine as well and use it to customize the settings. When I have to acquire data from DMM, I call obj0 (dynamically loaded), open a connection->use the connection other object(obj1)-> get settings-> write settings to instrument-> acquire measurement-> Close connection with the obj0. Redo it with every other object.  

---

I'm not sure what kind of reference is used. That could be a problem. Not sure how Teststand deals with it.

In LabVIEW when you open a reference, the reference is automatically disposed when the top level VI of the hierarchy where it was created stops running. That would mean that if Teststand runs a VI that creates a reference, the moment it stops the VI, the reference is gone. I'd guess that problem is already solved, as you are already using the DMM device from Teststand.

---

@GoKu25 wrote:   

Will this work?

Other then the reference thing, as long as you are creating, reading, using and writing them properly, I don't see why it would not work.

[paul.r]

I still do not understand WHY you want to do this? Do you really want one object for every type of measurement you are going to have with that particular DMM? Are you going to use the same architecture on other DMMs as well? Why not have a generic method in the interface class that calls both 'Configure Instrument' and 'Take Measurement'? You pass in a string to the configure instrument, and the particular DMM instance knows how to parse that string into a configuration setup. From teststand, you just call the 'Configure and Measure' method. 

[wiebe@CARYA]

---

@paul.r wrote:

I still do not understand WHY you want to do this? 

---

Can't say I do.

Not sure if OP is trying to do something difficult, or doing something simple in a difficult way. The latter would be bad.