LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get LV Class Default Value Error 1498

Solved!
Go to solution

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"

Possible reason(s):

LabVIEW: Library has errors. Fix the errors before attempting this operation.

 

Complete call chain:

Get LV Class Default Value.vi

Test.vi

LabVIEW attempted to load the class at this path:

g:\cal\devices\Digital300Meter\Digital300Meter.lvclass

 

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.

0 Kudos
Message 1 of 10
(12,316 Views)

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.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 10
(12,312 Views)

I see NI_LVConfig.lvlib in my dependencies.

How do I make sure this is included in my build?

0 Kudos
Message 3 of 10
(12,299 Views)

First you should move it to be specifically in the project (drag from dependencies to My Computer) then in the build add it to the "Always included" box.

 

alwaysinclude.png 

Message 4 of 10
(12,274 Views)
Solution
Accepted by topic author jpulley

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

 

0 Kudos
Message 5 of 10
(12,223 Views)

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?

 

Thanks,

Randy

0 Kudos
Message 6 of 10
(11,461 Views)

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.

 

Thanks,

Randy

0 Kudos
Message 7 of 10
(11,456 Views)

@Redrabbit wrote:
...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.


___________________
Try to take over the world!
Message 8 of 10
(11,431 Views)

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.

 

Randy

0 Kudos
Message 9 of 10
(11,417 Views)

Hello, Randy!

 

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!

Will Hilzinger | Switch Product Support Engineer | National Instruments
0 Kudos
Message 10 of 10
(11,389 Views)