03-25-2012 03:30 PM
Hi there.
I have come across bug in the LabVIEW programming enviroment.
I have a project that consists of about 600 VI's... ie very large.
The project compiles and runs perfectly fine and I can create an EXE in Windows 7 or Windows XP using LabVIEW 8.5 that works perfectly fine.
I can then take take this project and import it into 8.6, 2009 , 2010, or 2011 (after a very long time manually opening most of the vis and saving them - as the automatic method causes it to crash) - but once imported and updated the project runs fine in each of these newer versions of labVIEW.
The problem arises when I try to compile the project into an EXE...(using any labVIEW 8.6 or higher)
the first error (or feature? who knows) is that instead of creating an EXE with the project name it instead creates a FOLDER witht the project name and proceeds to copy all the vis into this folder,... - i assume it must be part of the newer compile features and that after 5-10 mins it might delete those when it finally creates a EXE... but instead at the end it gives me a compile errror message saying it cannot save a Vi with a bad or missing block diagram.. (but the vi in question is fine when I open it, and it runs fine...no missing diagram etc)..
Normally in 8.5 I get the *.EXE and an *.alias file, and a *.ini and a folder called data with some dlls in it...
but in any later labview version the EXE fails to compile and I get random errors...
The 1502 error is the the most common..
but I get others too, haven't saved them all -
but error 6 has occured a few times...
Errors Codes
===============
Possible Reasons
================
An error occurred while saving the following file:
C:\[Calibre Backup]\02-OPC\2012-03-21- 8.6 US-58-OPC-F\Ecoustic Grader sub-vis\Ecoustic Grader grade board.vi
Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
<APPEND>
Method Name: <b>Save:Target Instrument</b>
Details
=======
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 AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: Cannot save a bad VI without its block diagram.
============================================
03-25-2012 03:32 PM
P.s - There is Nothing wrong with any versions ability to build an EXE, as I have made many test exe's, the problem just lies with my large project, even thought it works fine in 8.5, it just won't compile in any later version
03-25-2012 03:52 PM
The one message gives you a clue when it says "Cannot save a bad VI without its block diagraCannot save a bad VI without its block diagram."
And since the automatic upgrading is giving you a problem too, it is probably hanging on the same VI.
03-26-2012 11:35 AM
Hi labview4steve,
I agree with Ravens Fan, it sounds like there is an issue with the VI that is generating that error. I understand that you don't want to rebuild your whole project, but have you considered rebuilding the VI that gives you that error and then readding it to the project? Can you even open that specific VI in any of the later versions of LabVIEW? From the error, it sounds like the upgrade process caused some error in the VI after it was upconverted, but it does sound like it may have only been one VI. I would suggest recreating that VI in a later version, i.e. 8.6, and check to see if that error still occurs.
03-26-2012 04:36 PM
Thanks for the help guys, but its still not a solution.
What do you guys mean by "rebuilding" the vis' - is there a function that does this? or do you mean just recode the vis? ie start with a blank vi and draw all the wires and code back in?
Even the subs vi's are big (with muliple sub vii's) and I would prefer not to spend hours doing things that that may not work anyway...
If i have to i will, but i would prefer a better option - and besides - why would I have to do this? - it works in all versions of labview
There is NOTHING and i mean NOTHING wrong with any of the files in the project whether in 2011, 2010, 2009, or 8.6 - the entire project runs fine.
ie it accesses hardware, and does everything its supposed to do, and there are no errors..
the vi in question that it complains about (ie bad block diagram etc - there is NOTHING actually wrong with it....
I can open it, I can save it, i can move things around etc etc....it runs fine in development mode....
NONE of the entire projects 500 odd files has a broken arrow anywhere, but its only when I try to make an EXE of the project that it runs into trouble..
An NI engineer told me to enable debuggging because it allows more memory when compiling and memory may be an issue, and to disconnect the type definitions when compiling into an EXE....
but all this did was allow the project to finish compiling ie it cleaned up the EXE folder and made an exe - but it wouldn't run ie. the EXE won't work, and the error message that pops up says something meaningless and stupid..ie
"you must use the full development version of Labview and not the runtime version to fix the broken arrows..
but NONE of the vis has a broken arrow.
Is there an major issue with code that runs on 8.5 - did labview change something major between 8.5 and all other versions that would prevent them compiling.?
03-27-2012 09:58 AM
Hi Steve,
Unfortunately there are a lot of reasons for getting errors, and because you are getting more than one error, and because you aren't getting the same error everytime this isn't something where we can point to cause and say for sure what is causing the issue. However, based on what you have said, it sounds to me like you have a corrupt VI. Error 1502 states "The VI became broken during the build process". This can occur for a variety of reasons, ranging from having sections of code that never execute (i.e. a case structure with a constant wired to it) to something more simple as a version upgrade that caused a minor corruption that may not prevent execution in the development environment. Either way, there is obviously some sort of corruption somewhere.
A couple of things that can help get your project to compile are, as you mentioned, to enable debugging, but there are also other things that can help. Disconnecting type definitions, and also removing usused members of the project libraries. These options are both under Additional Exclusions.
Error 6 that you are seeing typically comes from having too long of a file path in the project. To address this error, take a look at KnowledgeBase 52BF05ZY: Why Do I Receive Error Code 6 When Building an Executable?
If you can these errors to go away, we can keep working on sorting through the best way proceed to get this to compile.
03-28-2012 10:59 PM
Hi everyone, thanks for the help, but its getting rediculous for me....
I've done EVERYTHING that NI engineers on the phone and others have said..
in every permutation and combination as well...
I'm pretty sure the problem lies with labview not my code...
I've recoded the "problem" vi code from scratch... it runs fine in development mode..there are no broken arrows anywhere, and no missing block diagrams.
So as far as labview is concerned there shouldn't be a problem....
There must be a fundamental change from LabVIEW 8.5 to the other versions on the way the project gets built because this code works perfect in 8.5, but results in an error in later versions ONLY when Building - NOT WHEN RUNNING in DEVELOPMENT MODE....
Also there cannot possibly be a "conversion" error as some have suggested from earlier LabVIEW versions because I hand coded the "problem" vi from scratch in labview 2010 sp1 in case there was some sort of corruption with the vi the error code mentions.
There are no unused parts of the block diagram or code that does nothing as people have suggested..
(BTW the exact same issue happens in 8.6.1, 2009, and 2011 regardless. I just perfer to work in 2010 because its the last version of Labview that the same version of DAQmx will also work with 8.5)
When I go to make an exe of the project it again complains of the same error.
except this time it says the "grade board v2.vi" is the problem - the one that I rebuilt in LabVIEW 2010sp1
(BTW I do get this same error code 19 times out of 20)
Is there someone that knows exactly what this error refers to?
is there some way that the build process has changed from 8.5?
When I enable debug mode, this doesn't help as the final exe has a broken arrow
03-29-2012 02:55 PM
If you take this VI and put it into an executable by itself, do you get this same error? There was a fairly lengthy discussion forum about a very similar issue, specifically going from 8.5 to 8.6. Something obviously changed, but pin pointing what that is will probably be an almost impossible task. If you are curious, you can see that discussion forum here.
Try to build that VI by itself and let us know what happens.
(BTW I do get this same error code 19 times out of 20)
Is there someone that knows exactly what this error refers to?
is there some way that the build process has changed from 8.5?
What error do you get the other 1 time? The error has to do with the block diagram getting corrupted during the build. There are quite a few examples of the cause in the discussions forum above. Would you be willing to post that trouble VI?
03-29-2012 03:01 PM
Have you tried a mass compile on your project. It will help pinpoint the problem. This is a good chance that some version of the Labview VI are depreciated and replaced with a new one. Until you locate the VI that is causing the problem, you can not build the project.
03-29-2012 06:02 PM
I did a complete forced rebuild (ie shift- control run etc) and ended up rebuilding half of the standard labview installed vis....
Still to no Avail...
after reading the last ni forum link i found that the project now completes the compile and manages to build an exe...
to get it to do this...
I UNTICKED the option "remove unused members of the project library" under "additional exclusions..
and I UNTICKED enable debugging........
so the only thing I really changed was to KEEP OPEN THE OFFENDING VI.... ie
the "grade board.vi" that was indicated in the errror list
Bizaare......
So its definately a labview issue...
But this is STILL NOT A SOLUTION as the program only opens for 5 seconds now and then crashes....
But we are getting further along...
thanks for that forum link - it provided a few insights..