Handling HAL with Children Through Packages

[hooovahh]

Lets say I have a basic hardware abstraction layer for environmental chambers.

Here I have the parent Chamber class, a Simulate Class which overrides the required members, a CSZ, and an Envirotronics which are two makers of chamber hardware.  For this example lets say I want to distribute this as 3 different VIPM packages.  I have my Hooovahh Chamber.vip, which contains the Parent, and Simulate classes, and I have two others the Hooovahh Chamber >> CSZ.vip, and Hooovahh Chamber >> Envirotronics.vip.

On the palette I have the main functions all look similar to this.

My main question is about how people handle the Finding and Opening functions?  I want these drivers on the palette to be easy to use for my developers.  At the moment when you install the main Chamber package it installs the Parent VIs you see, and the Simulate class constant on the Class Constants subpalette.  Each child specific package then installs a new class constant in the subpalette.  Then when a developer wants to use the Find Chambers, they must wire to it an array of classes to use.  Here is an example:

Here we have a Find VI that is static dispatch on the parent, with overrides insides for each of the Chamber types.  It returns an array of found Chambers which is a cluster.  In the cluster is the class for the chamber found, which is used in the Overrides for Open and Close.  This works and is fine.  But I like the idea of hiding away the class constants, and having more self contained Find VIs for each hardware type.  In most cases we know the hardware we want to talk to and it isn't an array of classes on an array of COM ports, but instead the one hardware class we intend to use on the system.  What I think I would prefer is some thing more like this:

Here the developer gets a dedicated Find VI for each class which is a static dispatch for each child class.  They all return the same array of cluster (which would be a data type from the parent) and then that array of found chambers is used in the Parent Open which has overrides for each class inside.  In this design I would have the Find for each class installed on the palette under some kind of Find Hardware subpalette.  In this case I imagine there would need to be some kind method of keeping each Find from only using one COM port at a time.  Either through VIG or Semaphore of some kind.  Admittedly this is simplified in the previous example since the Parent would be doing the finding, and would know to only pass a unique COM port to one child at a time.

In all of these cases I imagine we have full control over the Parent, and all Children.  If anyone develops a new child class, we would roll it into the reuse library as another package which would go through the verification process.  Do developers prefer one design over the other? What pros and cons haven't I thought about?  Thanks.

[ShaunR]

I use a polymorphic VI. It basically just wraps the class constant for this purpose.The user can then have a single VI that they can choose the implementation method from a menu and that ripples down through the class functions. It means you only need 1 VI in the palette for the Open/New/Whatever and, once placed, the the user can change implementations without creating or deleting anything.

When there is a single type wired it looks much better because LabVIEW will show the class instance (see below) rather than the generic instance see (above).

The drawback is quick-drop (apparently) because you cannot choose a specific instance, only the polymorphic, but I ignore people that complain about that 

Edited 34 minutes ago by ShaunR

[hooovahh]

35 minutes ago, ShaunR said:

I use a polymorphic VI. It basically just wraps the class constant for this purpose.The user can then have a single VI that they can choose the implementation method from a menu and that ripples down through the class functions. It means you only need 1 VI in the palette for the Open/New/Whatever and, once placed, the the user can change implementations without creating or deleting anything.

The problem I have with that is you need a polymorphic VI that has all of the instances inside it.  That creates a dependency that all children are available and installed.  In my situation you may only install the Chamber package, and CSZ package.  Then the developer only has the parent, and that one child (well 2 there is the simulate).  So now where would that polymorphic VI live?  In the parent package?  Then that creates a circular dependency.  I did explore creating an XNode that would look at your current system and drop a VI that had whatever children were available for that target, but that got a bit messy.

The reason for having separate packages, is because some child classes, only work on some targets.  I may have one chamber that uses a Windows DLL to talk to it over USB.  This DLL wouldn't run on Linux RT, and I need to not bring along that child class as dependencies, because that will break the deploy or build, even when that child isn't being directly called.