Problems with dynamic class load in executable

[DAD]

At the CLA summit this spring there was mention of using OOP to create a hardware abstraction layer.  After the summit I checked into it and have implemented OOP based hardware abstraction layers on a couple projects.  They have been working great during development, but turn into a bit of a headache when trying to build the executable.  I haven't had much luck finding good documentation on including dynamically dispatched classes in a built application (and from some things I've read in the forums, I'm not the first to run into this, but I digress...).

The current problem I'm experiencing has to do with a class that uses instrument driver VIs.  When I try to dynamically load the class I get a 'Library has errors' error (code 1498). 

In my real app, I've got two classes that are problems, one is for an Agilent 34401 DMM and the other is for an Agilent E363x power supply.

In trying different things I found that if I copied the E363x instrument driver hierarchy into the folder for it's HAL class, then the class would load without error, but that didn't work for the 34401.

The attached zip contains a simplified application (in 2011) and a single instrument HAL that uses the Agilent 34401 instrument driver included with LabVIEW.  The simulator class works fine, but trying to load the 34401 class fails.  I've tried different combinations of always included files with no success.

I'd appreciate any suggestions from OOP experts or anyone that's encountered this problem.  Thanks in advance.

Right now the HAL classes are a separate hierarchy on the disk.  My eventual goal is to get everything to be contained in the executable.  But I'll save that for later. 

[Izzzzz]

Hello DAD,

Just to clarify two points when you mean load do you mean opening the VI or building the executable? Also was this a project you built in LabVIEW 2010 and moved to LabVIEW 2011? 

Izzy O.

Applications Engineer

National Instruments  

[DAD]

Izzy,

By load I mean when the executable tries to dynamically load the class.  This project started in LabVIEW 2011.

[Brian_Powell]

There are actually several things going on here.  Note that I tested this with 2012f1, but I'm pretty sure the behavior is the same in 2011.

Your example is loading LabVIEW Classes by path.  You're essentially trying to create a plugin model where you can add new classes to a directory and start using them without changing your source code.  This is reasonable and you will be able to accomplish this.

However, if you want to build your top-level application into an .exe, you also need to have a build process for your plugins.

Your LabVIEW Project contains a Project Library which contains the HAL (parent, abstract) class, as well as the implementation classes.  So this isn't really set up right for a plug-in model.  You can't load the Agilent implementation class without loading its owning library, which in turn references the other classes.

So I would recommend breaking these up into separate classes (without an owning project library), then creating a "source distribution" build specification for this class.  You will also need to uncheck "Exclude instr.lib" to ensure that the underlying instrument driver VIs are included.  The reason you have to build the plugin into a source distribution is because the instrument driver VIs are set to separate compiled code from source.  If you just refer to the VIs in the main LabVIEW instrument driver directory, you will get error 1574...

1574	Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine. Contact the distributor of the file. The distributor must include compiled code in the file for it to run in the LabVIEW Run-Time Engine.

Once you've built the source distribution, then the destination path for the build is the path you should use in your top-level application for use with Get LV Class Default Value.vi.

Your top-level VI's project will include the abstract class.  When you build the .exe, those VIs should be included automatically, since your diagrams will refer to that class's VIs.

Does this make sense?

[DAD]

Eliminating the project library and breaking up the original class hierarchy into a separate hierarchy for each instrument type, then building a source distribution worked!

Thanks for the recommendation!

[Taylorh140]

I found that if you drop a reference to the class in the top level diagram it will usually be included. Of course I'm using LV2017, so mileage may vary.

[carlos_camargo]

---

@Taylorh140 wrote:

I found that if you drop a reference to the class in the top level diagram it will usually be included. Of course I'm using LV2017, so mileage may vary.

---

Thanks!  This solution is much easier than the approach suggested above.  While those very likely work, they require a lot of work and added complexity.

[wiebe@CARYA]

---

@carlos_camargo wrote:

---

@Taylorh140 wrote:

I found that if you drop a reference to the class in the top level diagram it will usually be included. Of course I'm using LV2017, so mileage may vary.

---

Thanks!  This solution is much easier than the approach suggested above.  While those very likely work, they require a lot of work and added complexity.

---

I've been using a pre-build script for this. This avoids forgetting to add a new child.

The pre-build script simply empties a VI and creates instances (references?) to it. Since this VI is placed in the main, all the classes will automatically be included in the executable.

It's not perfect, especially when you're doing major refactoring over class hierarchies that are shared across projects it can be annoying to have the references to all classes...

[wiebe@CARYA]

---

@carlos_camargo wrote:

---

@Taylorh140 wrote:

I found that if you drop a reference to the class in the top level diagram it will usually be included. Of course I'm using LV2017, so mileage may vary.

---

Thanks!  This solution is much easier than the approach suggested above.  While those very likely work, they require a lot of work and added complexity.

---

Those solutions do bring extra functionality.

Most importantly, they allow you to add classes without updating the executable.

Of course, if you don't need (or want) that, the simple solution it the best.