No need to give respect to disagree with me. I'm basing my broken VI hypothesis from this
Quote:
"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