Is it true that bundle by name can cause FPGA compiles to fail?

Question

Dear forum,
I have attached a full log of my experience with this apparent bug, but I will summarize it here:
I attempted to compile a labview robotics project for cRIO 9074. The code was all on the FPGA, and I'd tested it all before attempting to compile--much of it was skeleton code proving that the self test system would turn on blinky lights on the front panel. My first attempted compile received a strange failure message in stage 3 of labview's pre-xilinx compilation interface, and the message was strange mostly because it was so intensely vague. It read "An internal software error has occurred. Please contact National Instruments technical support at ni.com/support with the following information: Error 1000 occurred at an unidentified location. Possible reason(s): LabVIEW:  The VI is not in a state compatible with this operation."
It being Tuesday the 6th of July 2010, I was unable to reach either the support staff who were on holiday or the web service, which was down for maintenance, so I began disabling pieces of my code using my debugging conditional disable statements. Eventually I found one skeletal code module, one to interface with analog flood sensors, which did not fail to compile. I compared this with another skeletal code module which did fail to compile, and after several tests noticed that adding a bundle by name from a strict type definition (but not an un-bundle by name or a standard anonymous bundle) would cause the vi to fail the compile. With several more tests I confirmed that while the vi would fail to compile with the bbn, with a standard bundle it would compile successfully all the way to the xilinx stage (by which point I didn't care, the bug was definitively pre-xilinx.) 
So tonight I will be going into my code and doing a lot of replacing bundle by name blocks with anonymous bundles, but I am still haunted by the extreme vagueness of the error, and by the fact that bundle by name is usually a solid part of the FPGA development platform. It was clearly intended to work. Why didn't it?
Gray Cortright Thomas
Franklin W. Olin College of Engineering
Engineering: Robotics
Class of 2012
Needham, MA
Gray Cortright Thomas
Franklin W. Olin College of Engineering
Engineering: Robotics
Class of 2012
Needham, MA
Attachments:
gtlog2010-07-06-18-24-00.txt ‏7 KB

Answer 1

So I did as Donovan suggested, and this worked for the code example which I posted. But when I started trying to put more of the bundle by names back in this solution stopped working. I then went on to solve a seemingly unrelated problem with the version that had compiled using only anonymous bundle: it had been unable to run some while loops that were in subvis. When I took the code from these subvis and put the loops on the back panel of the main vi, to my utter horror, they began to function again in the compile (running on the hardware). I was afraid that it was subvis themselves that were causing this failure to run, but was relieved when my next test proved this not to be the case: I took that loop on the front panel where it worked and used edit>create subvi to put it in a subvi. It still worked. Thus I was left to search out the difference between the subvi that successfully compiled, and the subvi which compiled but didn't run--and this was that the failed subvi was part of a library. I placed the new, working, subvi in the same library and the code once again displayed the same symptoms as when it had been tested the first time: the loop would not run even once and the flow of control would never finish with the loop--it just delayed forever. This might be a problem with the way I had used the libraries, but I think everything within them was public. My guess now it that the Libraries don't behave the same way they do on the FPGA as they do on the FPGA simulator, and this is why the vis seemed to work when I simulated them. So... I took all the vis, typedefs, and globals out of the libraries and into virtual folders of the same name and... Everything works! Even bundle by name!
The implementation of project libraries in the FPGA compiler may be suboptimal in some respects, but I probed only as deep as necessary to run my code.
And this code is in 7z format because my zip file did not meet the maximum file size requirements of the forum.
It is also very possible that I misunderstood the functioning of the libraries, and the FPGA simulator was blowing sunshine up my nose when it showed them working properly in simulation. Either way, it is probably worth looking into. This weekend I might try to find the simplest project file that shows these symptoms just to prove I'm not crazy.
Gray Cortright Thomas
Franklin W. Olin College of Engineering
Engineering: Robotics
Class of 2012
Needham, MA