Lots of problems building a large executable with LVOOP classes

[billings11]

I have a large project that makes significant use of LVOOP.  It is essentially a test executive that sequences lots of different types of tests in a configurable way.  I used to use a ton of variants in and out of these tests so they could be used interchangably in the archetecture of my application, but when LVOOP came out I rewrote my test executive to us an LVOOP class called "GTSTest".  Then I have about 10 sub-classes that inherit from the "Test" class.  Each of those sub classes are the actual specific tests.  Here is a shot of the project:

You can see I am creating a main class called "GTSTest" and that gives me polymorphism of any specific kind of test like "Torque Center.lvclass" and "AutoLinearize.lvclass".  It works fantastic in the development environment.

My problem now is I can't build anything with any of the LVOOP stuff into an executable.  I originally added all the classes as dynamic vi's because some of them pop up their front panels.  An application engineer suggested taking them out of the dynamic vi's section, but that didn't make any difference.  Here is the error I am getting:

TestExec Build error:

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 13 occurred at Invoke Node in ABAPI Dist read linkages.vi->ABAPI Dist Cmp Settings to Disk Hier.vi->ABAPI Get Settings From File2.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Rule_Editor.vi->EBUIP_CreateNewWizard_Invoke.vi->EBUIP_CreateNewWizard_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  File is not a resource file.

=========================

NI-488:  Sharable board exclusively owned.

Method Name: Linker:Read Info From File

O:\Software\MfgTest\Galvo Test Station (GTS)\Classes\Tests\Auto-Linearize\AutoLinearize.lvclass\AutoLinearize.ctl

Autolinearize.ctl is the alphebetical first class's private data definition.  So what's going on?  I made all the classes dynamic and it gives me the error.  I made none of the classes dynamic and it gives me the error.  But actually I know I'm going to need at least some methods of all the classes dynamic because a couple of the methods get subpanelled in the program so I need the front panels.

I've searched everywhere and I see no documentation at all about how to build LVOOP into an executable.  But clearly you need to do something special for this to work.  Can anyone help me? 

[billings11]

By the way I've mass compiled over and over and it doesn't help.

[billings11]

Another weird thing is when I generate a build preview it puts all the classes in separate directories in the support directory.  It is putting every method vi of every class in the support directory as dozens of seperate vi's in a directory structure according to class.  It won't include them as part of the exe like normal.  So there is something very different about the way classes are built into exe's.

Message Edited by billings11 on 07-26-2007 01:29 PM

[Wiebe@CARYA]

I haven't tried anything like this before, so this is a wild guess.


Have you put the build option in "Additional Exclusions" to "Do not disconnect type definitions or remove unreferenced members"?


It might help, but might as well do nothing...


Regards,


Wiebe.

[billings11]

Good idea!  But I just tried it and got the same error.  I'm starting to think I might be the first person who's ever tried this.  NI doesn't seem to evan have any internal documentation on how to do this, and I don't think any of their apps engineers have really used LVOOP before.  I'm not sure where to turn.  I'm on a dealine and my project is finished and I can't friggin build an exe!

Message Edited by billings11 on 07-27-2007 05:54 AM

[gmart]

Not knowing the specifics of your application, here is another idea to try. In the Advanced page, check the "Enable Debugging" option. Building with this option enabled has helped people who have run into problems with building applications with classes. While this will make the build process take longer and result in a larger executable, it would be interesting to know if you are able to build with this setting enabled.

Regarding the behavior you are seeing where class files are put in their own separate directories. Because of the way LabVIEW executables are built, there cannot be duplicate filenames in an executable. Since LabVIEW classes typically have dynamic VIs of the same name, the application builder detects this and places the files with the same name in their own separate locations on disk.

[billings11]

OK I figured out what is going on.

RULES FOR CREATING EXE’S WITH LVOOP

1.      Do not put any lvclass or any “dynamic vi” of any lvclass in the “Dynamic vi’s and Support Files” section of the source files tab in the build window.  Yes I know they are called “dynamic vi’s” in the LVOOP structure and one would assume you may need the front panels etc., but somehow they get loaded in automatically and if you explicitly include them as dynamic vi’s I think they conflict with themselves somehow.  If you do this you will get the following error:

Error 13 occurred at Invoke Node in ABAPI Dist read linkages.vi->ABAPI Dist Cmp Settings to Disk Hier.vi->ABAPI Get Settings From File2.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Rule_Editor.vi->EBUIP_CreateNewWizard_Invoke.vi->EBUIP_CreateNewWizard_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  File is not a resource file.

=========================

NI-488:  Sharable board exclusively owned.

Method Name: Linker:Read Info From File

O:\Software\MfgTest\Galvo Test Station (GTS)\Classes\Tests\Auto-Linearize\AutoLinearize.lvclass\AutoLinearize.ctl

In this case “Autolinearize.ctl” is the first class definition in the build.

2.      In the additional Exclusions section, you cannot use the “Remove as much as possible” option.  This disconnects typedef definitions, and I think it is misinterpreting lvclasses and trying to disconnect the class definitions, which breaks the application.  Of course, you don’t get any reasonable error message when this happens.  It will give you an error 1502 as shown below:

An error occurred while building the following file:

O:\Software\MfgTest\Galvo Test Station (GTS)\GTSExecutionMenu.vi

The VI became broken during the build process. Open the Build Specification and enable debugging to include the front panel and block diagrams.

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1502 occurred at ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> EBEP_Invoke_Build_Engine.vi -> EBUIP_Build_Invoke.vi -> EBUIP_Build_Rule_Editor.vi -> EBUIP_Item_OnDoProperties.vi -> EBUIP_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Cannot save a bad VI without its block diagram.

“GTSExecutionMenu.vi” was my highest level vi that included any lvclass wires.  Maybe that’s why it returned its name.  Anyway what is really happening is some screw up where it breaks any vi containing any lvclass.  If you enable debugging the application will work, but then if you connect to it from the development environment it will suddenly break and you can trace down and see the broken class vi’s.  To fix this, the “Remove unreferenced project library members” option worked for me to keep the LVOOP intact.  Of course it blows up your exe a lot bigger because you are now including every variation of every polymorphic vi instead of just the ones you are using.  You shouldn’t have to do this.  There is a bug in the “Remove as much as possible” option which removes LVOOP definitions that aren’t possible to remove without breaking things.  I hope this helps for the next guy that tries to use LVOOP.

[AristosQueue (NI)]

Good morning. Your post percolated up to R&D. I'm one of the developers for LabVIEW classes.

Before anything else, I want to say thanks for this comment:
> It works fantastic in the development environment.

My team worked hard to put out a quality set of features, but a lot of people have held off using
them because they found OO so foreign. I'm gratified that some folks (like yourself) are open
to trying out this new paradigm and that you've had success with it. Thank you.

Now... as for the Application Builder...

Do you have LV8.2.1? We fixed many issues related to LV classes in 8.2.1, some of which
impact AppBuilder. So before anything else, please make sure you have the patch.

Now, assuming that you do... I'm going to make some suggestions about handling classes in
AppBuilder. You're not the first to go down this path. The reason that there's no documentation
about classes in AppBuilder is that we thought it was pretty much the same as any other part
of LabVIEW in AppBuilder. A couple of customers who have gone down this path already have
taught us otherwise. ;-(

1) On the Additional Exclusions page of your build specification, change this to
    "Do not disconnect type definitions or remove unreferenced members."

    For many applications, this is sufficient. If that doesn't suffice,

2) On the Advanced page of your build specification, check the box for "Enable debugging".

Those are the two points that have fixed all known issues with Application Builder and LabVIEW
classes.

I am sorry for the difficulties you're having in the final stages of your project. I hope this helps. I
may not be available for further replies today, but other members of my team will be watching
the forums for your reply.

[billings11]

Aristos,

Thank you for your response.  If you check out my previous post, I basically figured this out - but after a lot of trial and error.  I have some concerns about your response.

First, no I have not upgraded to 8.2.1.  I have to maintain run-time engines on about 50 comuters that are running all different executables I've written in a manufacturing facility.  I know 8.2.1 is considered a minor patch, but because the runtime engines are not compatible with windows group policy installations through msi files, it is not an easy task to simply drop down an 8.2.1 runtime patch.  I have to upgrade a batch file and test it with the new 8.2.1 install.  Then there is always some kind of major headache if I just blindly do this.  For example, when I dropped down 7.1.1 over 7.1, then unknowingly installed an older app I had written in 7.1 that included the 7.1 runtime, the 7.1 runtime install broke the 7.1.1 runtime install.  And somehow nothing I wrote in either 7.1.1 or 7.1 would run on the machine anymore.  You have to understand the impact of a problem like this when it happens on 50 computers simultaneously in a manufacturing floor that expects to ship thousands of units that day.  I can't take any risk like that, and I've been burned enough times to know not to.  I have to treat even minor patch releases as complete upgrades by carefully isolating projects and making sure every single one works properly after the patch and every toolkit and runtime component isn't going to break some previous version or vice versa.  And something breaks almost every single time.  I've just barely finished this process for 8.2.0, and I don't have the time to do it in 8.2.1 all over again for a while.  Besides, I've already read on the forums about people who had problems with broken apps after an 8.2.1 install over 8.2.0, so I'm already dreading it.

But enough about that, I'd like to make some comments about your specific fixes for this problem:

 1) On the Additional Exclusions page of your build specification, change this to
    "Do not disconnect type definitions or remove unreferenced members."

I understand why I might have to do this, and this is how I was able to make it work.  Disconnecting type defs or something else may be breaking my LVOOP classes.  But I should not have to select this option for the build to work.  The app builder should be smart enough to not break LVOOP when I select "Remove as much as possible"  If I have to choose "Do not disconnect type definitions or remove unreferenced members"  it automatically includes every unused variation of every polymorphic vi.  I really hate that.  It blows my executable up much larger than necessary (mine was 22MB) and increases the loading time when someone runs the executable.  I know things could be worse, and I can break things down into more support libraries instead of one big exe, but we should get a better option in the next upgrade.  Why make us include stuff we aren't using?

2) On the Advanced page of your build specification, check the box for "Enable debugging".

I want you know know that if it is ever necessary for someone to do this to get an exe to work, that is a MAJOR bug by NI and should be considered unacceptable.  That is essentially saying the application only works if you build every front panel and every block diagram into the executable.  When I did that my exe was 37MB by itself.  My application loads 2004 vi's in the development environment.  Thats a lot of code, so I need to be able to streamline my exe as much as possible. 

The single biggest benefit of LVOOP is the pass by reference type of memory management, so I can pass classes around "in-place" without duplicating memory at every node in the block diagram.  When I had variants passed around instead of classes, I calculated that a single variant had it's memory duplicated about 80 times in my code, just from being passed through the vi hierarchy of a producer-consumer model state machine.  And the great thing was I was able to practically drop in a set of LVOOP classes where my variants used to be and hardly have to change any of my overall code structure.  It was awesome and I'm already  a big fan of LVOOP.  In my opinion LVOOP is the saving grace of labview 8.2.  It was the ONLY real benefit of my painful upgrade from 7.1, and the only thing that has made it worthwhile.  You guys should be proud of what you've accomplished.  I love that you can create queues of classes.  It lets me make what in effect are polymorhic named queues.  That simply awesome.  It will be an awesome way to pass between multiple reentrant threads with no memory space duplication.  It is a core part of labview for me now.  I'll probably never do a major app without it again.

Is there a list of issues that were fixed between 8.2.0 and 8.2.1 so I can figure out how necessary it is to upgrade again?

Message Edited by billings11 on 07-27-2007 02:24 PM

[gmart]

A partial list of bug fixes in LabVIEW 8.2.1 can be found here - http://digital.ni.com/public.nsf/allkb/CAB9E23506CA6A18862572B8001066C6