LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

debugging a factory pattern LVOOP plugin

I've done plenty of plug-in architectures with non-LVOOP before, and am now trying to get the Factory Pattern to work as a plug-in. I'm basing my attempt off of Elijah's well-documented Measurement Utility architecture, specifically using this page as my reference. I've made some progress, but have gotten stuck at one of critical steps. (That being, getting it to run!) I created the required projects and builds, altered the calling program slightly so as to find the plug-in when it is an .exe, and built everything. After debugging the path issues for where the plug-in is when it is called by an .exe, I'm at the point where the calling program reports error 1498 (Library has errors) when 'Get LV Class Default Value.vi" is run (in the factory initialization).

The library works fine as LV source code. I've re-checked Elijah's recommendations for how to do the build. Yet the class is broken in the source distribution when used in the .exe. I know I've got the path to the source distribution right, because before I did, I got a different error indicating that the library couldn't be found.

One thing I would do in non-LVOOP would be to open the plug-in from the source distribution in a new project and see if it was broken or missing something. I tried this now, and I found two things, both of which I think are normal. E.g. for the library to open in the new project, I had to add the parent class to the project first. (As per the recommendations, the parent is "Always Ignored" in the build for the plug-in and is included explicitly in the .exe build.) I also had to add a library that defined a shared variable. That library is also included in the .exe build. So I don't expect that to be a problem when the plug-in is loaded from the .exe. (I'll try removing the shared variable completely as my next test, just to be sure.)

I'm a bit stuck on how to debug further. There is no error up to the "Get LV Class Default.vi". There is an error on its output. So the library is bad. But the library in source code is fine. And the library in the source distribution seems mostly fine, except for the known dependencies that the .exe should take care of.

Any suggestions on how to debug further?
(The code base is huge and under NDA, so I can't share it.)

TIA,

     DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 1 of 34
(919 Views)

@Dave_Thomson wrote:
And the library in the source distribution seems mostly fine, except for the known dependencies that the .exe should take care of.

I don't think this is true.  Are you compiling the plugins into a packed project library and do you include the dependencies of the plugin in the lvlib? 

aputman
LabVIEW 2017
LabVIEW Programming
0 Kudos
Message 2 of 34
(897 Views)

Putnam - no, I'm not using PPL's at all. The architecture described by Elijah is a distinct alternative to PPLs. (See the link in my first message.) But I'm not quite sure where you are going with this... Are you suggesting that proper use of PPLs could be the problem, or the solution?

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 3 of 34
(892 Views)

I don't see the fundamental difference between what Elijah recommended and PPLs.  I prefer PPLs because the library turns into 1 file instead of many with their block diagrams removed.  But I will state that PPLs have to be build from libraries.  They cannot be built from classes.  The classes will have to be inside of libraries.  Then there is the slight mess of trying to keep track of dependencies.  NI claims all of this will get cleaned up at some point in NXG when they get packages figured out.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 4 of 34
(879 Views)

I've tried tackling the LVOOP and plugins problem in the past and had some big trouble with the dependencies involving the EXE and the Packed Libraries, so I ended up using non-OOP plugins. Apparently, even if you have the same class being referenced in the EXE and in the LVLIBP, when each of these gets packaged, they create an internal copy and reference that. So, when you try to use the packed library within the EXE, the dependencies don't match and the program throws an error. 

0 Kudos
Message 5 of 34
(873 Views)

Felipe, Putnam,

      I appreciate the feedback.

      To clarify, there is a fundamental difference between Elijah's architecture and using PPLs, that being that Elijah's architecture does not use PPLs! Precisely for the reasons Filipe mentions. LVOOP plugins with PPLs have serious issues with dependencies. By using Source Code Distributions, Elijah shows how to manage those dependencies to avoid the problems. In fact, when I started this project, I used an existing, very simple Factory Pattern LVOOP project I had to test it. My project had no plug-ins, but I added one, followed Elijah's rules, and made it work in the .exe. Unfortunately, now that I'm working with the bigger, more complex project, I'm running into dependency issues that are proving difficult to debug. Argh...

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 6 of 34
(869 Views)

@felipe.coutto wrote:

Apparently, even if you have the same class being referenced in the EXE and in the LVLIBP, when each of these gets packaged, they create an internal copy and reference that. So, when you try to use the packed library within the EXE, the dependencies don't match and the program throws an error. 


That is why you have to have the PPLs built in a separate project and have the EXE project use the PPL, not the source code.

 

Back to the original issue: One weird thought I am having is maybe the VIs are still saved with separated from source code enabled.  If so, the distribution would not be able to run in the RTE.  It is a long shot, but that is the only thing I can think of right now.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 7 of 34
(859 Views)

Do all of your plugin classes get this error? Or just this one?

 

Have you tried building a dummy .exe that does nothing but load plugin classes? Does the problem still occur? 

0 Kudos
Message 8 of 34
(844 Views)

Thanks for the suggestion. This is the kind of thing I was hoping for!

First, I did try the reverse. I tried opening the class from the Source Distribution by rewiring the path in the Factory loader to point there instead of pointing to the original class in the source. It worked fine. This tells me that the source distribution copy is somehow inherently OK. (I also removed the source copy first, to make sure it wasn't loading that by mistake somehow. It really was loading the source distribution copy.)

Then I tried your idea. I wrote s super simple factory loader that just loads the class. First I ran it in LV and loaded the original class in the original source location. Then I ran it in LV and had it load the same class but from the source distribution directory. That worked too. Finally, I built it into an .exe and ran it, with it again getting the class from the Source Distribution directory. It put up a "loading" window, found a bunch of stuff, and the gave up with the same error, 1498. Library has errors. Fix the errors before attempting this operation.

 

From these tests, I think the general conclusion is that the build is OK, but that the .exe is missing some dependency that the build is also missing. So the question becomes, how to identify that dependency?

 

I tried to watch the loading dialog as it was skimming through dozens of VIs, finding, and loading them. I got some idea of what the last one to appear is, so that may be a starting point. But is there a more robust way to figure out which dependency or which VI it is having a problem with?

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 9 of 34
(806 Views)

I've done a few more tests and gotten a few more clues, but still no resolution.

My simple test caller worked from inside LV, even when pointed at the plug-in in the Source Distribution. But it failed as an .exe.

I then added the parent class constant (parent class of the class being called as a plug-in) onto the block diagram. Didn't do anything with it. No wires. Just dropped it there. Built it. And the .exe worked. So I took the class constant off the block diagram, and built it again, but this time with the parent class added to the .exe build spec as "Always Include". This build did NOT work.

So... Some dependency is definitely missing when I use the .exe and the Source Distribution copy of the plug-in. Still trying to figure out what it is.

And adding a class as "Always Include" to an .exe build is, apparently, not the same as adding the class constant to the diagram. The first does not bring in the required dependency. The second does.

 

Any further suggestions would be much appreciated.


TIA,

    DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 10 of 34
(787 Views)