1498 Error when launching plug-in actor

[CaseyLamers1]

I am looking for some help.

I am launching an actor by calling source (from a source distribution).

My motivation to do this in order to create a piece of code that I can edit and deploy quickly in order to do fast iterations. Building EXEs of all of my code (PC and RT Targets) takes several hours. Building this small piece as a plugin takes minutes.

I provide a path to the desired actor in a config file and then I launch the actor. I create a source distribution and everything works.

Then I edit my plug-in and create a new source distribution. Now it gives me a 1498 error at the "Get LV Class Default Value.vi".

I think what is happening is that working on the plug-in revs the parent and then trying to call it from the exe that is an older version of the parent causes the Get LV Class Default Value to fail.

In my project for building the plug-in I have the parent. Is my issue that I just wasn't careful enough with not saving something that might be in the parent? I think what I did this last time was I created a new override VI for a method that is in a Do.vi. I think this may have created a new version of the parent class.

I want to be able to edit my plug-in and not have to recompile my main code.

Any tips?

Thanks,

Casey

[tstahl]

Building an executable creates a copy of the object and places it in the EXE. This copy has some internal UID changed, so I'm surprised that you were able to get things working the first time.

I've not worked with the Actor Framework, but I have used plugins with executables. To get it to work, I had to create a packed library of the parent object to use in both the executable and in the child object/plugin. The packed library ensures a common object is used by both pieces. Any changes to the parent object requires recompiling of the executable.

The build for the packed library had enable debugging checked or I would get errors about compiled code in LV 2012.

[FabiolaDelaCueva]

tstahl wrote:

Building an executable creates a copy of the object and places it in the EXE. This copy has some internal UID changed, so I'm surprised that you were able to get things working the first time.

I've not worked with the Actor Framework, but I have used plugins with executables. To get it to work, I had to create a packed library of the parent object to use in both the executable and in the child object/plugin. The packed library ensures a common object is used by both pieces. Any changes to the parent object requires recompiling of the executable.

The build for the packed library had enable debugging checked or I would get errors about compiled code in LV 2012.

If you decide to go the route of PPL, I suggest you check out this post: https://decibel.ni.com/content/docs/DOC-19176

[CaseyLamers1]

I had seen a previous presentation on PPLs and decided that they would be too hard given the level of object composition I use. So I was going to just do a source distribution. I have it working but obviously can't tolerate having to rebuild the EXE if I edit the plug-in.

What I am looking for is advice on what actions require the EXE to be rebuilt so that I can either avoid or do a minimum number of times.

Thanks,

Casey

[tstahl]

I would recommend reading the article FabiolaDelaCueva linked to again. There is no need to recompile the EXE for a change in the plugin; only the plugin's packed library needs to be compiled. It's a good article that presents a solid method.

The EXE would need to be recompiled any time there is a change in the parent object only (which is the point of a plugin).

[AristosQueue (NI)]

Two ideas on what might be wrong followed by a trick for diagnosing.

What might be wrong:

I'm going to bet that something about your parent class inside the EXE is not the same as the parent class outside the EXE -- such as a typedef being disconnected maybe? Something is making it so that the child class or one of its member VIs needs to recompile when loaded.

Or you could have turned on source only during the Source Distribution? Source only VIs load broken in the runtime engine because they don't have their source code segment with them.

Diagnostic:

Right after your call to Get LV Class Default Value.vi, add some code that does the following:

1. If there is "no error" from the call, do nothing.

2. Otherwise, use the Application method "Open LV Class" to open the same path of which you tried to get the default value. Then loop through the resulting library reference and for each member VI, do Open Front Panel on it... repeat until you get a VI that is broken (will probably be the first one but you never know). MAKE SURE YOU SKIP THE PRIVATE DATA CONTROL ... the run time system cannot open control VI panels.

3. Once you have one of those broken VIs open, click on its run arrow to see the error list window. That should give you a much more detailed view of what is wrong.

If you couple this with remote debugging, then back in the dev environment you can open both panels and diagrams and get a lot more error information.

[CaseyLamers1 · Accepted solution]

Just an update.

I rebuilt the RTEXE and the EXE for my PC that call my 2 plug-ins last night. I made a change last night to a typedef enum to just make it a plain control. I had that enum in the parent for the plug-in. I expected everything to work this morning, but it didn't.

So I dug in to the build settings for the source distribution and got both plug-ins to work.

For the RT in the Additional Exclusions page I have the first 3 options checked:

Disconnect type definitions

Remove unused polymorphic VI instances

Remove unused members of project libraries

Previously the Exclude files from vi.lib, instr.lib and user.lib were all checked. I had to uncheck these to get the RT plug-in to work. The rest of the check boxes were and still are unchecked. So, something in one of those libraries was needed.

For the UI build I needed to check the first 2 options, but uncheck the Remove unused members of project libraries. I also needed to exclude files from VI.lib. It looked like most things from VI.lib were Actor Framework.lvlib items.

I have not tried every combination and permutation on this, but I was able to get both plug-ins to work.

Casey