I am calling Get LV Class Default Value.vi to dynamically load a class.
This was working fine until I added Open Config Data.vi to read from a .ini file.
The application works correctly when I press the RUN button while in the LabView development environment, but when I build the executable with Application Builder and then run it, I get:
"Error 1498 occurred at Get LV Class Default Value.vi"
LabVIEW: Library has errors. Fix the errors before attempting this operation.
Complete call chain:
Get LV Class Default Value.vi
LabVIEW attempted to load the class at this path:
I have narrowed the problem down to having Open Config Data.vi included in the application, not in the class. I do not have to call the Open Config Data vi to get this error.
I have a subvi called "SelectDevice" which references Open Config Data. In my main Test.vi, SelectDevice is in the True case of a True/False case structure which is set to False.
If I put a Diagram Disable structure around the Open Config Data vi, I do not get the error.
I suspect that including Open Config Data includes a VI in the application which interferes with Get LV Class Default Value.
Solved! Go to Solution.
If Open Conf file is from the config file VI set, they are now part of a LVOOP library themselves so make sure they are included in your build.
Thank you, this works!
I also set the Additional Exclusions page as follows:
Disconnect type definitions - checked
Remove unused polymorphic VI instances - checked
Remove unused members of project libraries - checked
Modify project library file after removing unused members - NOT checked
I know this is a rather old post but I'm running into a similar issue and I was hoping for guidance. I understand how including these vis in the build would have the affect of "making it all good" but what I'm sticking on is if you want this to be an "add-in" object situation (i.e. you compile one main program and then later dynamically load objects as they apply) how can you know which libraries/files need to be put in the compile? Specifically in my case, I'm loading "Hardware" objects, now today I know that I'll be using mxDaq devices, some serial, etc. but down the road I may need to create an object which supports Fieldpoint, is there anyway to create the object (or change an ini file) which allows me to use the previously compiled code which doesn't have the Fieldpoint specific drivers in the compile?
As a follow up, I tried including the associated hardware drivers in the build and still had no success. I'm posting a small example of the application, with source code and multiple compiles (trying different inclusions to see what works). The source is in LV2010SP1, when you start the runtest.vi it will show a screen with a path control, when the path control changes (to one of the classes) it will try to load and execute the run method of the class. In development environment this works on both the generic and serial class but in runtime not so much (fails on the serial class). Any pointers would be appreciated as this is a major hold up for my project.
...is there anyway to create the object (or change an ini file) which allows me to use the previously compiled code which doesn't have the Fieldpoint specific drivers in the compile?
Sure, but the main problem you have is correctly packaging the new plugin so that it has all the dependencies it needs and (ideally) that those dependencies don't clash with other code which is already used by the app.
Personally, I never had to build such a system which would actually load the plugin at run-time, but there are certainly multiple references to such plugin architectures on line. Here's one example, but you can find other examples by looking both here and on the LAVA forums.
The link you posted indeed gave me some good direction towards a solution, it definately worked for the small example I posted but I'm having difficulty implementing the packed libraries in my specific application. I'll continue to search and hopefully find another way to get the same results. I appreciate the input.
It looks like tst has provided you with some good advice. Please let us know once you've had a chance to work more with your specific application, and we'll be happy to answer any further questions!