![]() |
Labview Build Errors
We are seeing the following build error, does anyone know how how to resolve this?
An error occurred while saving the following file: C:\Documents and Settings\Jwagner\My Documents\LabVIEW Data\Team1676\20100220a Pele - Jim Working\Pele\Teleop.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_RTEXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller <APPEND> Method Name: <b>Save:Target Instrument</b> |
Re: Labview Build Errors
Quote:
The strange thing is we went for weeks just deploying the code to RAM with no errors; we only had problems when we performed a Build. Good luck - this could be a tough one to fix. |
Re: Labview Build Errors
FWIW, had the same problem (Error 1502) occur again yesterday. This time the supposedly offending item was "Begin.VI". The solution I found was to revert to an older copy of Begin.VI that had been successfully built in the past, build it (successfully), re-implement the exact same changes, then build it again (successfully). This is the second time this approach has worked. Solution time: 4 hours including the time spent trying to diagnose the problem. Once I gave up trying to find an actual error in the VI, the time spent to backtrack and re-implement was only about 20 minutes. This will be my preferred approach in the future, obviously.
As before, the code could be deployed w/o any errors generated or issues in function, but wouldn't successfully build. It would *supposedly* build OK (no errors were generated, at least) when the "enable debug" setting was checked under the Advanced tab in the build options, but after uploading to the cRIO it resulted in a "No Robot Code" condition. Experimentation showed that the issue was not related to file or folder permissions, nor file or folder path length. |
Re: Labview Build Errors
We had an issue earlier this year where we could use the RUN function to execute code, but when we did a build, we would get an error. I don't remember the code, but it looked much like the one in the first post.
NI looked at the problem and found that it was caused by a known bug in LV. We had some debug code that we were disabling by putting a case statement around it and setting the control to FALSE using a constant. Changing the case input to a control rather than a constant fixed the problem. |
| All times are GMT -5. The time now is 08:18. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi