LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error while building in LV8.2.1

I have a .bld file from LabVIEW 7.1. I'v converted this build script into a LV8.2 project. and I can run my program's VIs. When I try to make an exe build, LabVIEW goes through the build process. It's a large project and takes about an hour to build. After it loads and adds all the VIs and support VIs it finally get to the "Building Application" step and after a few minutes atthat step I get the following 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 2 occurred at Invoke Node in ABAPI Dist Build App from LLB.vi->ABAPI Build Application.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Memory is full.
=========================
NI-488:  No Listeners on the GPIB.

Method Name: Build:Application


I googled it and found some information and increased my virtual memory to 4GB and tried to build again, to the same results. Has anyone else run into as issue such as this? The build worked in LV7.1 just fine and the conversion process was about as painless as could be expected. Are there any known causes and, more importantly, fixes to this?

Gary
0 Kudos
Message 1 of 3
(2,870 Views)
I can't give any specific help, but can offer a couple random musings. First, this error looks suspiciously like the one you get when you do unprotected division and then use the result to do something like initialize a buffer or set the number of iterations for a loop that is autoindexing one or more outputs. What happens is that because of an error or similar situation, the division ends up doing a divide by 0 operation which results in NaN. When this output hits a node expecting an integer (like the N on a FOR loop) this NaN is converted to a Very Large Number - something like 2.4 billion. In any case, LV then tries to preallocate enough memory for 2.4 billion iterations, runs out of memory and blows up.

My suspicion is that given the massive size of your application, you hit a limit in the builder that generated a similar scenario to the one above. BTW; how many VIs are there in your build?

A second alternative is that there is something in the code itself (besides its size) that the builder doesn't like - perhaps a remnant of the conversion from 7.1 to 8. This has caused problems in past migrations. (Version 5 was an absolute nightmare...)

Unfortunately, because NI locks the code for the builder about the only thing you can really do is report the problem to NI and hope they can duplicate it and get around to fixing it.  In the mean time, you can do some experimenting and remove portions of the code until you get something that builds. The resulting application doesn't need to be able to actually run, just build successfully. Once you have something that builds, start adding stuff back in a bit at a time and try to gauge whether the failure occurs as a function of the number of VIs in your application to the presence of a particular VI in your build.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 3
(2,852 Views)
I just had a similar error in LV 8.0.1 (Error 2 while building -- memory is full).  Turned out that I had an Insane Object (corrupted object) in one of my VIs.  My application is probably not as large as yours (only about 1000 VIs), and I didn't port from 7.1 to 8.2.  However, I would guess that your error is not really a memory error, but is something else that the builder doesn't like, such as a corrupted object or some feature that was supported in 7.1 and has been changed in 8.  I had a similar problem porting another application from 8.0.1 to 8.2, in that a Library file (.lvlib, not .llb) that was perfectly fine in 8.0.1 was flagged as corrupted in 8.2.  I guess 8.2 does more internal checking and found something wrong with this .lvlib that 8.0 didn't.


Suggestions for tracking this problem down:

1) If you haven't already tried, make sure the application runs correctly in LV 8.2.1 (e.g., in "source-code", not as a built application).
2) Make a very simple application in LV 8.2 and make sure you can successfully build it (to ensure your 8.2 install is clean and functional).
3) Try a force-recompile of your application in 8.2 (e.g., hold down the Shift key while clicking the Run button).  This may bring up whatever problem there is within your code.  Make sure to do this for any VI Server-called VIs as well.  Then do a Save All.
4) Break your application up into smaller chunks and try building them separately (e.g., make some new top-level test VIs that call chunks of your larger application).  If there is something corrupted, this should help you isolate it.  This may be painful, but will be a heck of a lot less painful than trying to rebuild the full application in 8.2.
5) If it worked fine in 7.1, leave it in 7.1.  Don't try to fix things that ain't broken.

Message Edited by Joe Gerhardstein on 06-07-2007 05:29 AM

Joe Gerhardstein
Viasat
Certified LabVIEW Architect
Certified TestStand Developer
Certified Professional Instructor
http://www.viasat.com
0 Kudos
Message 3 of 3
(2,802 Views)