Code breaking after one execution

[Tim_S]

NI tech support has filed a CAR on this; I'll post it when they send it to me. The CAR is about the breaking after execution and not what is causing the breaking; we're still working on the root cause.

I've been trying to convert some working LV2011 code to a plugin structure using the method found at http://lavag.org/topic/14212-how-to-call-a-plug-in-object-from-an-executable/page__p__85600#entry85600. The code can execute once during which loading the plugins produces errors. The code terminates and is now broken. All of the plugins are now in memory with no way to unload them except to close the project and open it up again.

I pulled out the load portion of the code and had no problems loading a plugin and converting it to a more specific class. I added a VI from the base class after the conversion and ran into the same break-after-execution.

I don't have a version of the code I can post here, however would appreciate any ideas that could help us figure this out. The plugins are to perform analyses (max, min, span, kurtosis, etc.) on waveforms.

Tim

[Tim_S]

Here's an update on this. I recreated the base object and plugins from scratch and, I thought, identically. The recreated code worked without issue. Tech support's response was:

"With the first version of the code you sent me, we found that the problem was caused by the fact that you were typecasting a class that was embedded in the packed project library to a class that was outside of a packed project. library. By packing all of your classes into packed project libraries as you did in your rewritten plugin code, the error was no longer present."

I'm not sure how I created this condition as I've not reviewed the code yet. Tech support is filing a CAR related to this in addition to the CAR on the broken VI after one run.

Tim

[Tim_S]

UPDATE: Still in communication with NI tech support. Tech support tells me that there have been problems with packed libraries and solutions are going to take some time.

I've been able to boil down the issue I'm seeing to the attached code. Child 1-3 contain the plugin code. Child Library contains the packed library plugins and the "TEST LOAD.vi". Parent Library is the packed library of the parent object. Parent Object is the source for the base plugin (parent object).

Child 1 and 3 load without errors. Child 2 loads with an error 7, which is a bizarre error as the file and name can be verified and, the class and containing VIs are not broken.

Child 1's "Parent VI 1" has a One Button Dialog inside of it.

Child 2's "Parent VI 1" has a subVI which is part of a class with a One Button Dialog inside of it.

Child 3's "Parent VI 1" has a subVI which is not part of a class with a One Button Dialog inside of it.

Tim

Loading Plugins.zip

[Tim_S]

It's taken a long time, but I've gotten a response from NI about why the plugins were not loading:

I have received an explanation regarding the program you sent us that

demonstrates your issues with loading classes from packed project

libraries.

In the description of the

LV

Class Default Value VI, it states:

"Returns the class data for the class whose path you wire to

the path input. If the class is not in memory, LabVIEW attempts to load it

from disk..."

The important part to note is the second sentence. The first thing this VI

will do is to look at the LabVIEW class name that is in the path. If that

class is already in memory then it will load the one in memory. This is

both a speed benefit as we don't have to read from disk but it is also a

language benefit. This prevents us from loading two classes of the same

name into the same application.

What is happening in your application with loading classes that work is

that the main application already has them in memory. If the main

application doesn't already have the class in memory then it tries to read

it from disk. Unfortunately you cannot use file paths that are inside

build specifications (e.g. exes, dll, lvlibps). When Microsoft introduced

Windows Vista and extra security measures we had to stop allowing our VIs

to look into build specifications for file paths. This is why you are

getting an invalid filepath error because the file path is looking inside

an lvlibp.

If you want a plug-in architecture you will need to have the

LV

classes

available on disk.

For a really good example of a plugin architecture using classes take a

look at our Hardware Abstraction Layer example, found below:

http://zone.ni.com/d...a/epd/p/id/6307