cant build

[MartinB]

LabVIEW Data\Robot Project Final\Autonomous Iterative.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_Build.lvclass:Build_from_Wizard.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.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_RTEXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi -> AB_UI_FRAMEWORK.vi -> AB_Item_OnDoProperties.vi -> AB_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

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

Please help we can not build the code to the crio.

[Greg McKaskle]

This error means that the VI in your project named Autonomous Iterative is broken. Open the VI from the Project/Team Code, click on the run arrow and see if you can correct the issues with the VI.

Greg McKaskle

[rellimcire]

Originally Posted by Greg McKaskle

This error means that the VI in your project named Autonomous Iterative is broken. Open the VI from the Project/Team Code, click on the run arrow and see if you can correct the issues with the VI.

Greg McKaskle

With all due respect, Greg, no it doesn't mean the vi is broken. I'm getting the same error, except for us it's our Teleop.vi. I can save it fine manually. I can run it on the cRIO just fine. There are no errors anywhere. But when we try to build we get the 1502 error.

Martin:

ni.com/ask has several threads about this. What worked for us is enabling debug info. Right-click on your build spec, then select properties. On the property panel left side select Advanced, then click the box to Enable Debugging. According to stuff on ni.com, debugging forces the diagram to load which overcomes the problem.

What's disturbing about this is loading debug info on a competition robot. I'm trying to figure out a way around it. Anybody have any ideas? Plus, why the heck does LabVIEW need to save a vi during the build that I've already saved manually?

BTW, ni.com had a couple of other ideas, neither of which worked for me. Perhaps one will work for you. One is to open the offending vi before you build so the diagram is available. Another is to shorten the build path -- apparently path names can get over the 255 char limit on some (all?) Windows platforms (the build path is also on the build spec properties panel.

[Greg McKaskle]

No need to give respect to disagree with me. I'm basing my broken VI hypothesis from this

"Possible reason(s):
LabVIEW: Cannot save a bad VI without its block diagram.
"

That pretty clearly shows that at the point the app builder was attempting to add/save the VI into the .out for the cRIO, that VI was broken. If it wasn't broken when the build began, it was broken during the targeted load/compile/save.

I really really don't like the error messages from the app builder, and I'm doing what I can to see that the thing is redone in the future. In the meantime, if you can send in a project and collection of VIs that reproduce this, I'll see that it is looked into. I don't really know that there are too many issues with including debugging info on the cRIO app, but clearly it is an odd workaround, and it doesn't explain what the original problem was.

Does the save terminology make more sense now? The way the app is built is that an application context describing the code format, alignment, etc is built. VIs are loaded into the context either from memory or from disk, not sure how it is done these days. After the VIs are loaded, they are compiled with the appropriate compiler settings for the target, and the code is now in the VI. Additional passes are then made to remove diagrams simplify libraries, etc. Then the VIs are saved into the EXE. It may seem odd that the save method is used to put into the EXE, but in fact even for temporary execution, the VIs are saved into a memory stream and the memory stream is sent to the cRIO.

PM and I'll give my email address for sending in the VIs. Thanks in advance.
Greg McKaskle

[rellimcire]

OK, I kind of owe Greg an apology. I did find an error, but I think my explanation is instructive. At least I didn't find this anywhere else.

First, although enabling debug allowed me to build, it turns out it wrecked my deployment. I'd build, then deploy. LabVIEW says all is OK. But after deploying the code would not run on the cRIO. The only way to run was from LabVIEW.

So I went back to the most recent version that built without enabling debug. (Lesson: I was saved a lot of grief because I make daily or more often backups of our project.) That version also deployed so the two problems are linked.

Since LabVIEW gave no clues, I took the current project and went back to the Teleop.vi that worked. Then I retraced my steps bit by bit until I found the step that broke it. Finally after a couple of hours I found it was caused by a new sub vi. That vi referenced the drive motors (specifically arcade drive) which is a logical conflict with the reference in Teleop.vi. Cleared that up and everything builds OK and deploys OK. WHEW!

I started by saying I "kind of" owed Greg an apology. He was right that something was wrong. However, LabVIEW gave no clue as to what. Only the build failed. I could run from LabVIEW despite the problem. The wrong thing is what I normally think of as a runtime error, not a build time error. So, yes, something was wrong, but it's not real helpful to have to disassemble code blindly hoping to find the problem. Plus, it's surprising that the LabVIEW build and deploy pick up a runtime error, but running my code in debug mode through LabVIEW completely misses the error.

Glad I found the problem. Hope this helps someone else.

[rellimcire]

A little more info. I didn't read Greg's last post before my recent post, so mine may be a bit out of sync.

What Greg said made sense about the saving.

I tried to put together a simple deviation from the standard robot project but it didn't produce the error. Obviously the problem is more subtle.