LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic dispatch and different return classes

Hello ThiCop,

 

Mayby I'm just plain stupid in this case but your approach has (in my mind at least) the same problem as I'm facing at the start of this thread.

The frontpanel of the "Get Childeren" would look like this:

2014-01-15 15_20_58-DSSP Modules.lvlib_DSSP.lvclass_Get Childeren.vi Front Panel on DSSP Modules.lvp.png

 

However can you show/tell me what the frontpanels of any of the dispatched (overwritten) childeren would contain as "Childeren" output. If this is not a DSSP but a child the overwritten VI breaks.

Or am I thinking in the wrong direction and do you mean actually this:

2014-01-15 15_28_47-DSSP Modules.lvlib_Reference Measurement.lvclass_Get Childeren.vi Front Panel on.png

(And I should remove the "Get Childeren" in the "DSSP class" of cource)

 

However in both options I have some issues figuring out what the block diagram would look like.

 

Can you give me some hints in that?

 

Tim

0 Kudos
Message 11 of 16
(1,133 Views)

Hello Tim,

 

For this specific case you do not have to use "to specific class" node. A class loaded from disk will know which class it is and will use the right Dynamic Dispatch method.

 

Here's a screenshot of what it looks like for my "grandfather" class. (Capture.png)

For completeness I also included an example of my Class Hierarchy. (Capture2.png)

 

Note: if you define a HAL with a DSSP parent and 2 levels/layers below it, then you should know the middle level/layer (type of instrument).
The Plug-Ins will generally come in the lowest level/layer (specific instrument).

 

The illustrated use case here only makes sense to retrieve your different available classes in a Dynamic Dispatch way.

Personally I would only use this method to know which "specific instruments" (level/layer 3) are available for a certain type of instrument (level/layer 2).

 

The "types of instruments" (layer 2) should normally be known in advance, so you should be able to define these types as "Class Constants/Instantiated objects"  in your DSSP parent "get children" method.

 

Kind Regards,
Thierry C - CLA, CTA - Senior R&D Engineer (Former Support Engineer) - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
Download All
0 Kudos
Message 12 of 16
(1,125 Views)

Hello ThiCop,

 

Somehow I still have some problems grasping that you are thinking about.

 

For a part we are on the same line.

My "grandfather" is indeed the DSSP mudule (level 1). Below this I have the "Types of instrument" (level 2). This is shown in the class hierarchy below.

LabVIEW Class Hierarchy 2.png

 

The "specific instruments" (level 3) have to be loaded at runtime. This trick: selecting the correct DSSP class (on disc as a LVLIBP (packed library)) and loading that specific class is somewhat hard to do for me.

 

One extra note about the location of the DSSP classes. Their path is unknown to me (at the moment). Although I am trying to put them to "<exe path>\Plugins\<DSSP path>\<DSSP name>.lvlibp" but I'm not shure if I'll manage this.

 

At the moment I added all the "Get childeren" vi's at the 2nd level but my problem remains.

 

A alternative would be to just return the required path and save this to a config file and load this file at start. If I wave to change the specific instrument (level 3) a restart is required but it will save me a lot of problems. (And if I find out how I can do this whitout restart I can add this later).

 

Hope you can help,

 

Tim

0 Kudos
Message 13 of 16
(1,087 Views)

Hello Tim,

 

My apologies for the late reply.
I was Out of Office due top sickness.

 

Do you have a piece of sample code that you can share to illustrate where you are exactly stuck?

Otherwise it might be difficult for me to see where you are getting stuck.

Kind Regards,
Thierry C - CLA, CTA - Senior R&D Engineer (Former Support Engineer) - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 14 of 16
(1,056 Views)

Hello ThiCop,

 

Sorry for the late reply (some other parts of my project where more demanding).

 

Anyway, I think my sample code is already here (post 1 and 3)

 

At the moment the exact implementation is still blank since I wasn't able to get this to work.

 

However, as stated before other implementations of this are welcome since I also need to find a way to grab the path of the loaded plugin and store it in a configuration file.

 

Tim

0 Kudos
Message 15 of 16
(1,040 Views)

Hello Tim,

 

Again the delays at my side have been quite long from my side.

Is this topic still active?

 

Somehow your instrument type class should know where to look for its children:

- If you can have a certain folder hierarchy, then adding a specific instrument of a new  type would just be as easy as adding a new folder (with the specific instrument class under the correct instrument type. Then you can just use the (dynamically dispatched) VIs that you have defined in your instrument type classes.

- As you correctly state you can also use a config file to achieve this.

 

Both have their positives and downsides:
- The first one requires you to follow a certain pattern and place everything in the right folder
- The second one requires you to be very precise about the paths that everyone enters in a config file.

 

Concerning sample code:
screenshots can be useful, but the actual code would allow me to do some tests and would allow me to experience where it is going wrong.

Kind Regards,
Thierry C - CLA, CTA - Senior R&D Engineer (Former Support Engineer) - National Instruments
If someone helped you, let them know. Mark as solved and/or give a kudo. 😉
0 Kudos
Message 16 of 16
(1,007 Views)