To more specific and to more generic classes

[Ramya12]

Hi all,

Can anyone tell me when to use "to more specific classes" and when to use "to more generic classes" and how does that work? being new to LVOOP I find i very difficult to understand.

Thanks for the help in advance.

[Norbert_B]

These two functions are older than LVOOP. In fact, they are often used for VI Server usage.

To more specific class is mandartory when using LVOOP in Plugin Architecture. The loaded class (Device Specific Software Plugin, DSSP) is verified against the 'API' (parent class: Application Separation Layer, ASL).

You also use these functions if you want to call dynamic dispatch functions from specific "layer levels".

Norbert

[ijustlovemath]

As mentioned, they're often employed when you're doing something with the VI Server, eg property nodes and invoke nodes. As an example, let's say you're doing User Input and want to have a tab control with two subpanels, but each subpanel's VI depends on the instance of a class. Subpanel 1 has a "Controller" VI embedded in it, and Subpanel 2 has a "Model" VI embedded in it. Controller and Model are abstract classes, just frameworks for more specific implementations (eg PID Controller, MPC Controller, Differential Equation Model, Neural Network Model).

So you open a VI reference (using the "class name" VI) to the class you want's "User Input.vi" method, and embed it in the subpanel. Save these references into a cluster, and run the VI. Now you have tabs with subpanels whose contents change dynamically depending on which subclass you have when the User Input main VI is run.

So now your user picks some specific settings for the Controller and Model you have, and wants to continue. One way to do this is to have the user stop each individual VI in each subpanel, but that's cumbersome. A much more seamless way is to stop the VI by reference, (using the references we saved earlier), read off an Indicator using the Ctrl Val.Get method, and get a variant. The variant is a Controller object or a Model object, but isn't much use as a variant. So in order to turn it into a useful object, we use the "To More Specific Class" vi. Wire the "Controller" abstract class to the VI where you get the controller object, and LabVIEW automagically keeps track of the actual subclass of the controller you receive, which is useful when later you want to do some dynamic dispatching.

Kind of a contrived example, but I use it personally and find it works really well.