LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

8.5 FPGA VI Refs and Instability

Hi Folks,

I've started running into some instability in one of my projects, and I'm wondering if anyone else has encountered this.  To summarize everything below, I've got what appears to be a corrupt FPGA VI reference that causes LabVIEW 8.5 to crash frequently.  For the gory details, please read my five paragraph essay below (sorry it's so long).

I have a VI on my RT target that initializes an FPGA target, meaning it opens the reference, writes a control or two, and then runs the FPGA VI.  I passed the FPGA VI ref out and used it later in the code.  Eventually, I made this ref into a typedef so that I could easily update it throughout the code.  Since I made the typedef, I've changed my RT app a lot, and now when I open the VI above where everything gets initialized, LabVIEW crashes.  I also noticed this behavior in another subVI in my RT code - whenever I open the front panel or right click, LabVIEW "encounters a problem and needs to close."  Unfortunately, I don't get a cpp file and line.  The common factor seems to be the FPGA VI reference.

Okay, so I removed my typedef to see if that would help.  I still get similar behavior - this time I right clicked the "open reference" node and clicked on "select VI" (there was already a VI selected - not from scratch.)  This crashed LabVIEW immediately.  Sometimes if I try to open the initializing VI from the project explorer, the same thing happens.  If it's any help, the FPGA VI was compiled before, but isn't compiled now - I feel like that shouldn't matter in opening a reference, though.

The only way I successfully avoided the crashes was to open each VI that uses the FPGA VI ref outside of the project, remove the offending code (diagram disable didn't stop crashes), and make a stripped down version of everything for debugging the RT side.  I'm thinking of just rewriting from scratch the parts of the code that access FPGA controls and methods next.

Lastly, I can't post my code on here (it's proprietary), but it's already uploaded to the NI FTP site for an unrelated support ticket.  It's very possible that someone could check this firsthand.

Any thoughts or similar experiences?

Thanks in advance,

Jim
0 Kudos
Message 1 of 4
(5,241 Views)

Hi Jim,

It sounds like you have some very odd behavior. The only thought that comes to my mind is to delete all your FPGA references and then replace them with fresh ones. I have had broken arrows that didn’t go away until I had done this.  Also, rather than referencing the FPGA VI, see if you get the same crashing when referencing the bit file. I don’t believe the type def is the issue. It seems that there is a spider web of referencing in your project.

If you could build a simple, non proprietary, project that I could see crash on my computer, I would be very interested. If this is reproducible, I would like to file a Corrective Action Request.

 

Charlie M. CLD
0 Kudos
Message 2 of 4
(5,068 Views)
Hi Charlie,

Thanks for your input.  Based on the earlier lack of response, I'm guessing that nobody else has seen this.  I was thinking of a simple way to reproduce it, but I'm really not sure which sequence of actions generated it.  I have the project available on the FTP server if you'd like to have a look...  (feel free to email me - I'm not sure if you have access to my address via my profile)

Yesterday I started carefully removing all the references and FPGA nodes and starting over, and that seems to have done the trick - I don't get any crashes anymore.  It strikes me as kind of similar to the  "insane objects" errors - the best way around it is to backtrack or isolate the problem area and remove it.

I appreciate it...

Jim

0 Kudos
Message 3 of 4
(5,060 Views)

Howdy Jim,

It sounds like you’re on your way to fixing everything up. However, I understand what a pain this is. I actually don’t have any information on you (there are a lot of Jims in our system). The best way for NI Support to look into this is for you is to make up a new service request regarding this issue.

Charlie M. CLD
0 Kudos
Message 4 of 4
(4,872 Views)