From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

G#

cancel
Showing results for 
Search instead for 
Did you mean: 

How to use Packed Library Plugins with G#?

I have an example from G# that should operate via plugin compiled as packed library (lvlibp) but is not due to a casting conflict. I am following a paradyme recommended by (or at least commended by) NI as the preferred architecture for lvclass plugins.  (https://decibel.ni.com/content/docs/DOC-19176)

Attached is my code that was derived from the G# Dependency Injection example ...

MyG#Class_class
Class acts as an interface for the dynamically loading subclass


MyG#SubClass_class
Class is 'dynamically' loaded.  This is compiled as a packed lib.

Running these examples using the "Get Exported File Path.vi" should load the object from file and create using the different DependencyInjection Constructor... however I receive a 1448 : Bad type cast.  LabVIEW cannot treat the run-time value of this LabVIEW class as an instance of the given LabVIEW class.

This is similar to attempting to use the "G#Object_GetClassPath.vi" on the PPL subclass constant... A wire class conflict indicates: You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes.

It seems that once compiled into a lvlibp, the object no longer correctly inherits from G#Oject.

J

0 Kudos
Message 1 of 6
(10,771 Views)

Hi J!

What LV-version is the PPL built in? I'm using LV2013 and thats the wrong version I can tell. Does anyone know how to see what LV-version a ppl-file is built in?

//Thomas

Certified LabVIEW Architect
0 Kudos
Message 2 of 6
(6,862 Views)

Hi,

Packed libraries and LabVIEW class inheritance is not the most simple thing to manage. The root cause of your problem is that your class from lvlibp is inherting from a G#Object class that is included in the lvlibp, but not visible to the outside world. A bit strange, since you actually inherited a class with public methods that should be publically available. I don't like NI implementation of this. As the "new" G#Object is included in the packed library, LabVIEW will treat your class as it inherits from another namespace and it is not related to "ordinary" G#Object and that is why you get a bad type cast.

The only solution I can think of is to first build a library named G#.lvlib (and include the G#Object, G#Interface and G#Debugger) and relink all your classes to use this lvlib instead. Then build a packed library of this. Next step is to relink your classes that you want to include in your own lvlib (containing some G# classes) to relink and use the new G#.lvlibp instead. (I haven't found any easy way of switching this in LabVIEW, maybe it is possible). If you build your packed library now, you will get two lvlibp in your build (your new and G#.lvlibp). Now you can use G#Object VIs from the lvlibp together with your own lvlibp.

I attach an example of this. I wish there was a better and much more simple way and I really hope NI makes it easier to work with packed libraries and inheritance in future versions of LabVIEW.

Best regards,

Mattias

By the way, the example are built in LV2012. You can always open the build project in a text editor to check which LV version is used.

Message 3 of 6
(6,862 Views)

Mattias,

Very informative response.  That confirms the necessity to compile G#.lvlibp if I intend to use G# within a Packed Library... (I had been doubting if that was a complication that I had incorrectly inferred from other sources).

With a little modifcation to your example, I am left with a plugin architecture that fails to correctly load and rather drastically crashes LabVIEW!

Here's what I've done...

I linked all G# calls to the included G#.lvlibp (but moved it into the root directory as source code)

I created an lvlib for MyBaseClass2

I changed the inheritance of MyBaseClass to inherit from MyBaseClass2

I build MyBaseClass2 into Base2.lvlibp

I build MyBaseClass into Base1.lvlibp

Each of these build specs copy the G#.lvlibp from the root directory into the build directory.

I am left with the following built files... Base1.lvlibp, Base2.lvlibp, G#.lvlibp

From now on I will only make calls to objects contained within the builds...

G#PackedLibTest.lvproj:TestPackedLib.vi

In this project I have added all of the built files and will attempt to use the object with direct call.

Attempting to call Base1.lvlibp:MyBaseClass object yeilds the following error "Private VI in packed library 'Base1.lvlibp'... This LabVIEW calss is missing at least one member VI." which prevents the code from running.

G#PackedLibTest2.lvproj:TestPackedLib2.vi

Attempts to load Base1.lvlibp:MyBaseClass object from a file reference then treat it as an instance of its parent Base2.lvlibp:MyBase2Class object.

This code can run but causes LabVIEW to crash with "Exception: Access violation (0xC0000005) at EIP=0x01CD3835"

Any insight as to why this fails to link/load?

0 Kudos
Message 4 of 6
(6,862 Views)

Hi again,

I got the same crash. I can't see any obvious incorrect in your code. The only small detail is that I can't seem to find the "G#Object_Create.vi" method implemented in your class. But if it is missing, the default inherited G#Object_Create.vi from the root class should be used and that obviously doesn't work as expected and causes a crash. Clearly a LabVIEW bug.

If I add an implementation of "G#Object_Create.vi" to your class and rebuilds the packed library it seems to work. However, it seems really strange that you can't use a base class method without overriding it, else LabVIEW crashes. I will see if I can isolate the LVClass bug with packed libraries and see if it still exists in LV2014 beta.

I attach an updated example.

Mattias

Message 5 of 6
(6,862 Views)

Thanks Mattias,

This really adds clarity to the crash.  I think that NI has more direct path to chase.  I have an open SR with them to help me further.

- Jonathan

0 Kudos
Message 6 of 6
(6,863 Views)