cRIO deployment fails

[jareds]

Did reformatting the device help? Can you test the deployment with only one FPGA VI, so that you can try the fix in the KnowledgeBase?

[rex1030]

First off, that's not a fix. It's a rediculous workaround. As I said before, trying to apply that workaround to my project won't work because I am loading multiple bit files at different times during runtime. "I am weary of the workaround suggested in the knowledge base article because we are loading different bitfiles at different times because the fpga doesnt have enough gates to hold it all at once. This results in broken reference wires if we try to place any of the FPGA functions into subvi's. The workaround for the broken reference wire issue involves creating reference constants binded to a specific bitfile. Obviously this will not work either because we are loading different bitfiles at runtime." If I didn't have to statically bind the FPGA reference controls and indicators to a specific bitfile, making the subvi bitfile-specific, then your subvi workaround might be feasible. But as it stands, moving the fpga vi's to subvi's breaks the reference wires and the static bind fix isn't possible in this situation so cannot use subvis on the FPGA stuff.

Please pardon my frustration. I am just frustrated that the project works fine in 8.6 and then I upgrade to LabVIEW 2009 with the more "advanced and upgraded" realtime version and the project doesn't work because "It is not possible to determine the size of a VI in memory or if the FPGA nodes are in memory beyond the 64 kB boundary." If that's true, then don't require it to determine the size of the VI in memory and simply display a warning that it was unable to determine it's size. It worked fine before with 8.6 and older RIO and RealTime versions. What's the problem with LabVIEW 2009 and why wasn't it fixed in SP1?

How will deploying a different project with a different VI with an fpga vi thrown in a subvi will help me get my project working, unless you mean just to test my system configuration to see if it is a bad software load on the devices or something?

I reformatted the devices and loaded the latest RIO versions and full load without scan engine support and I am still having the same issue. I will load up an example project or something and see if that deploys, because you asked me to.

[christian_w]

Hello, I have a similar problem with broken reference wires in my project. Maybe describing it here will help to find the bug.

Over the time we replaced the NI9104(VirtexIII) chassis by the new NI9114(LX50). To prevent the copy of my source files I referenced all files under a second target in my main project.This allowes me to develop the project on different target FPGAs using the same source files. We use the cRio-9014 RT controller with both chassis.

FPGA: I compile identical sources under different targets.

RT : I bind my FPGA reference to a type definition and use this FPGA_TypeDef.ctl  as a Global variable for my RT sub VI's.

The only thing left to do when building my RT exe is changing the FPGA target reference (Property of OpenFPGARef)  in my RT main VI.

And that's the point the FPGA reference get lost in a broken wire.

I think there's no reason for a broken reference wire due to the fact that my type definition is the same for both chassis as well as my FPGA code. 

My workaround is to make a delete and re-insert step of the  FPGA_TypeDef.ctl on the RT Global variable VI.  I don't know why this works.

Best regards Christian

[jkurtw]

rex1030,

Have you worked with Applications Engineering to send over your example that reproduces this issue?

If you don't have an active service request, you can create one at ni.com/support to call in. We have an FTP server that you can upload it to.

This issue was supposed to be completely resolved with SP1, so if you are still seeing the same issue I would like to reproduce this issue for R&D and find the root cause.

Kurt Williams

Product Manager

LabVIEW Real-Time

[rex1030]

Thank you for your help jkurtw. I'll open a support ticket in the next couple days. Should I send you my 8.6 version or the one I was trying to upgrade to 2009?

Christian_w you would have better luck getting help by starting a new thread. Some people call asking a completely different question on an active post "thread hijacking" lol. You will get a lot of help by posting your question in a new thread. Everyone that uses the RIO FPGA interface has run into the same broken reference wire problem as you and none of us know why we have to do that workaround to be able to use FPGA vi's in subvi's. The fpga subvi broken reference wire problem has existed since LV 8.5.0 or before and it still isnt fixed. Its a problem I have to deal with every day and it sucks.

[jkurtw]

The 2009 SP1 version that still reproduces the issue would be best, since that one should be working.

Then we can look into why it is still happening.

Kurt 

[rex1030]

Well it's fixed. I have to say I am always very impressed with the support engineer's help whenever I contact NI. With the help of Applications Engineer Caleb Harris, my project deploys and my program runs just fine. I finally get to start using LabView 2009 on this project and I am excited about that.

rex

[deepforge]

rex1030 - could you please describe what the finally steps to resolve were for the rest of us.  I've been dealing with this issue (among others) since installing LabView 2010 and upgrading our previous 8.6.1 project.  With the exception of conditionally loading FPGA vi, we're in the same boat as you were, and running SP1 doesn't fix the issue.

[rex1030]

Well I apologize for not keeping this thread updated. At the time I had replied, it appeared everything was just fine when in fact it was not. We have not been able to use LabVIEW 2009 for that project.

It turned out that basically the cRIO was running out of RAM and not indicating it well. The build specification had been pushing the limits of the amount of memory we had to work with on the cRIO. It turned out to be impossible to use LabVIEW 2009 with the project we had because basically the default load of RIO 3.4 for 2009 takes up a lot more memory than the older rio versions we had been designing the project under. I had been working with an app engineer and even he could not come up with a slimmed-down RIO install (only installing exactly what we needed) that would work with the project. He was actually able to get his hands on the same hardware we are using (rare for them to be able to do that), and determined it was in fact a memory issue.

We have had to stick with 8.6 for this project because of this. There simply isn't enough memory on the 9012 RT controllers to run our big project and the new rio versions. I had to switch gears here and work on a more pressing project for our lab, but when I come back to this one I will be optimizing the project to identify ways to reduce the size of the program, though I am not sure how I will accomplesh that effectively without reducing functionality to be honest.

My suggestion is to put in a service request and work with an app engineer to be sure that you are having the same issue as me, and not something else that could be solvable. Also, try to experiment with different custom RIO loads and see if you cant only load what you need and nothing else. There is a ton of stuff loaded on there that we never needed for our project and it may be the same way for you. You may not be as close to hitting the wall on memory as we are so that could be all you need to make it work.

Sorry I couldn't be more help. I will have to massively reduce the size of the build I am loading onto the crio to be able to use Labview 2009 with this project. I am not sure it is worth the time.

[rex1030]

I should also mention that RIO 3.4 for 8.6 was causing all kinds of crazy errors with our code that had been developed about a year ago on older RIO versions in 8.6. Basically labview started bouncing off the walls and tripping over the furniture when I upgraded the crios to the latest RIO version. It would give indescript errors like error 1, which is the error labview throws when it has no idea whats wrong (I hate that error, it might as well have a skull and cross bones laughing at you lol). I actually missed an important deadline at work because basically I had loaded RIO 3.4.x default load for LV 8.6 and thats when all the problems were happening. Basically stuff I had tested and verified was now not working, the week of the code being reviewed by others, which made it look like it was never working and I had just not tested it properly. It was extremely stressful to say the least. 

Due to the memory problems and the new RIO version compatibility issues, I literally had to load the old version of RIO that we had developed the project on, and I mean old. I think it was the first RIO version that 8.6 was shipped with or something near that. It was too little to late though as my deadline had passed and the damage was done.