Jump to content

Issue with plug-in architecture using hardware drivers in runtime environment


Recommended Posts

As the description states, the issue I'm having is with an application I've developed which utilizes class "plug-ins". I've also posted this issue on the main discussion board at NI (http://forums.ni.com/t5/LabVIEW/Get-LV-Class-Default-Value-Error-1498/td-p/1129973) but I thought I'd get it over here as well since from my experience this board is more finely tuned to LVOOP development.

In short, the plug-in architecture works fine in development environment or if the plug-in doesn't utilize any hardware drivers (i.e. mxDAQ, Fieldpoint, Serial) in the runtime environment but if I try to load a class which contains a hardware driver in the compiled program it throws a 1498 error. What I've traced this error to is that the class cannot be loaded because it appears to be broken (even though it loads fine in development). I've tried different methods of compiling, including classes, hardware drivers, etc but cannot seem to find a solution. If anyone has any thoughts or has conquered this issue in the past I'd appreciate the wisdom. If you want to get a simple example of what I'm talking about, I attached one to the discussion linked above.

Thanks,

Randy

Link to comment
  • 3 weeks later...
  • 2 weeks later...

Boy Id sure like to see the answer to this myself! I hope its a simple one!

Anyway, I hope my experiences relate to this thread.

I once had a heck of a time transferring an EXE using FP to another machine and there was no LVOOP at all involved.

I had to install LabVIEW as a Hacker's fix just to get by the problem.

I have learned that FP and DAQ mx and other resources like that are unique and need special treatment in programming

LV for executables to be loaded on to target machines.

WHat to do to make these resources allocate and initialize in an executable is a very good question.

Link to comment

See this thread: http://lavag.org/topic/15369-packed-libraries-break-inheritance-relationships/

Basically, my understanding is that the problem with loading a class at runtime in an exe is that the dependencies of the class (such as items in vi.lib, user.lib) are not available without the development environment. With the introduction of packed libraries, the class and all its dependencies are compiled into a binary avoiding this situation. The problem is, that packing all the dependencies not only packs the target plugin class, but also packs up the Parent. This means that your plugin architecture will be destroyed. The accompanying thread links to a ni thread which details a procedure from removing this behavior. (its really obtuse IMHO, that doesn't mean I wont do it, it just feels like a highly irregular and obfuscated way to code)

Here is that link to the NI website:

https://decibel.ni.c.../docs/DOC-19176

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.