LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application Builder and Corrupt VIs

Howdy All,

I'm developing a Medium-sized application in LabVIEW 7.0 used for instrument control. This application has grown over-time, and currently contains approximately 400 VIs. The basic structure of hte appliation is one main VI that has an instrument status display on the bottom, and a sub-panel on the top, into which all dialogs are loaded for user interaction. Each major task has it's own VI that is loaded into the subpanel as appropriate.

I've read a few stories on the developer exchange about VIs becoming corrupt. I thought these were freak occurences, because by and large, it appears that LabVIEW is fairly stable. However last week I had a VERY scary experience.

I was demonstrating to a collegue the properties of an XY graph control. We changed the colour of one of the plots, then hit cancel. LabVIEW complained of an internal error involving undo.cpp and proceeded to crash. I figured the crash was caused by some strange sequence of events, didn't think much of it, and reloaded my application. After making some changes, I went to the Application Builder to build the application. However the application Builder was complaining about a "missing board" in the DEFAULT build file. I knew immediately that something was VERY wrong. (When I say default build script, I'm referring the default script that is loaded when you press the "Build application or shared library..." button in the tools menu).

(As a side note, does anyone know why the LabVIEW application builder gives such terrible error messages? I always get that "missing board" error when either: one of my support files cannot be found, or one of my dynamic VIs is not executable. Since the error doesn't pinpoint a file, I neeed to go through the files one by one - which is a pain because I have a lot. Another question, why does the application builder ALWAYs ask if you want to save changes to build script, even if you haven't made any changes?)

After loading my build script for the application (which I've used HUNDREDS of times), I got the "missing board" error. I didn't think there was a problem with any of my paths or VIs, but I went throgh each included support file and dynamic VI in the build script to make sure it was there. Though there seemed to be no problems with any of the files, LabVIEW continued to complain.

I figured the problem was specific to the computer I was working on, so I copied the source to another development machine to complete the build. I was VERY scared to find that I got the SAME error on the DEFAULT build script! Also, my actual build script refused to load properly.

This was late at the end of a long day, so I decided to turn of my machines and go home. The next morning, everything worked fine - I was able to build the application, and I haven't had a problem since. (Maybe it was a bad dream, but I have clumps of hair on my desk from the night before...)

I found this experience to be UTTERLY TERRIFYING. Once I had to revert to an archived copy of one of my main VIs, because the current version refused to open, claiming it was corrupt. Since I don't know what's going on behind the scenes in LabVIEW, I'm afraid that tiny internal LabVIEW errors might be adding up. I back-up the source very regularily, since it is such a large project, however I have *real* way of inspecting the integrity of the source.

Does anyone know (A) why this might have happened - especially when the problem reproduced itself on multiple machines (B) has anyone had similar experience with internal LabVIEW errors or corrupt source (C) what sort of internal errors might be piling up that might cause a VI to claim it is "corrupt".

All input is appreciated.

WG
0 Kudos
Message 1 of 4
(2,780 Views)
Hello Victrick,

Did you undo.cpp error give a line number associated with the error? I know that several of the undo.cpp line errors were correcting in LabVIEW 7.1. As far as the �missing board� error goes, I�ve never seen anything similar to it, and was not able to find anything in our database.

If none of these suggestions help, or if I�m not correctly understanding your issue, please reply with comments or answers to the discussion above and any additional information that may help, and I�ll be happy to look further into it.

Have a nice day!

Robert Mortensen
Applications Engineer
National Instruments
Robert Mortensen
Software Engineer
National Instruments
0 Kudos
Message 2 of 4
(2,780 Views)
Hi Robert,

For the undo.cpp error, I got a couple different line numbers but didn't write them down. If I get them again, I'll be sure to get the specifics for you.

As for the "missing board", I also got that description a little wrong - the error I'm talking about is:

"Error 7 occured at Inovke Node in Dist read linkages.vi->Dist Cmp Settings to Disk Hier.vi->Build Application.vi

Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for hte operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Unix.
---
NI-488: Non-existent board."

As you can see, I meant "non-existent board". This error is very easy to reproduce - m
ake a build script and include some extra files. Save and close the build script. Move or rename some of the extra files included in the build. Reload the script. You should get that not very helpful error.

Now that I think about it though, maybe that NI-488 error refers to GPIB control, which I think I have installed, but don't have a GPIB card installed... hmmm... no reason that error should be popping up *there* though...

I could have *sworn* I would also get that error when one of the dynamic VIs in the build is not executable, but I can't seem to reproduce that right now.

Tying back to the original thread - what makes a VI corrupt? I imagine if you cracked the binary file open yourself and messed around with some bits you would probably make the VI corrupt, but I'm assuming that editing a VI normally (ie through LabVIEW) should NOT cause the VIs to become corrupted. Any information on VIs becoming corrupt? Is it somehow related to the undo.cpp errors?(when trying t
o undo some last change that wasn't recorded properly, the VI is modified improperly - after you save and close, it won't reopen?)

Victrick
0 Kudos
Message 3 of 4
(2,780 Views)
Victrick,

I agree that the error you get is cryptic and not very helpful. Error 7 can have two different meanings. The first is that a file cannot be found. I�m sure this is why you are getting the error. The second occurs if you are trying to access a NI-488 board that is not detected. Since both errors map to the same number, LabVIEW displays info on both of them. The second explanation is obviously not a problem in your case and can be disregarded.

You are correct that normal VI editing should not cause the file to become corrupted. LabVIEW will recognize an incorrect state and prevent corruption of your files. That is why it shuts down sometimes and throws .cpp errors. Shutting down is for the protection of your code. The only
situation where I have seen a VI being corrupted is when LabVIEW is calling external code. If LabVIEW calls a dll and passes some data to it by reference, and the dll then allocates new memory for that parameter, the new memory will overwrite LabVIEW memory and possible corrupt the VI. Any dll�s called in LabVIEW should only use the memory LabVIEW provides and not allocate any memory of its own; at least not any memory pointed to by the pointer passed by LabVIEW.

Have a nice day!

Robert Mortensen
Applications Engineer
National Instruments
Robert Mortensen
Software Engineer
National Instruments
0 Kudos
Message 4 of 4
(2,780 Views)