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

[Gray Thomas]

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

[Joe D.]

Hi Gary,

Something appears to be messed up, would you mind attaching your vi so I can take a closer look. Also what are your version of LabVIEW, LabVIEW RT, LabVIEW FPGA, and NI-RIO?

[Gray Thomas]

I'm using LabVIEW 2009 SP1 Full Professional Edition, FPGA Development 2009 SP1 (I re-installed with sp1),  LabVIEW RT from the time of LabVIEW 2009, and RIO from the same time period. If you can get this attachment, it contains the code. Load Fish Architecture.lvproj and try to compile FPGA Main.vi. It gives me error 1000, which seems to be some sort of generic failure. Now if you remove the bundle by name that I've hidden in Full Bridge Module and replace it with an anonymous bundle it will compile. Donovan Buck told me that this can be fixed by deleting the typedef from the global and then adding it back.

[David_L]

I checked your code (which btw, you should probably just post a zip since some might not be able to open up 7z) and I don't see any bundle by name functions.  Only standard bundle.  Did you try doing as Donovan mentioned and did it work? 

[Gray Thomas]

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.

[RavensFan]

---

@Gray Thomas wrote:

And this code is in 7z format because my zip file did not meet the maximum file size requirements of the forum.

---

Then use a higher compression in your .zip file (if possible).  Or break it up into two zip files.

[Gray Thomas]

Ok. Pardon my inexperience with the zip format, I spent an hour and a half on this and I still haven't learned how to increase compression ratio or split zip files evenly. This is just a work around for that: this first file is the file structure and the following one is the two modules that I pulled out of the folder Code Trunk/FPGA code/Modules to make the size restriction on the first file. you are going to need to unzip them and then move the modules back inside the code trunk for the program to work.

[Gray Thomas]

And here is the next piece. These are the two modules.

Hopefully, now everyone can share in the experience of receiving error 1000

[JÞB]

This sounds related to CAR 183991

Seen as "not- funny" by several observers.  Would an NI AE elaborate on the current investigation findings and scope of this CAR?  Or if it is not related, post a new CAR#

[Joe D.]

Hi Gary,

Sorry I have not replied sooner, but I have been out of the office sick. It appears that you were working with Brain and he has already filed a CAR #239244 on this, but I would like to continue to work with you to solve this problem if that is ok?