cRIO modules gone after reboot, variables in limbo

[Steffen01]

should I make 2 variable libraries, one for FPGA and one for real time?

[GerdW]

Hi Steffen,

as the FPGA doesn't have access to shared variables you don't need to create a special library for it...

[GerdW]

Hi Steffen,

please keep in mind: to upload your RTMain.vi is pretty senseless without the lvproj file and all those missing subVIs…

When the connection to the cRIO is lost, then (in my experience) mostly due to 100% CPU load on the cRIO. When this only happens for a short amount of time after starting your VI/RTEXE then most probably there is some initialisation involved. It only is a problem when this 100% CPU happens after some execution time of your RTEXE (maybe memory shuffling or memory leaks?)…

[Steffen01]

I think I found something. In the RT main vi FPGA is started first then Invoke Method funktion sends a reset. Sure enough it loses connection to the cRIO. See reset after start.gif. The startup.rtexe and FPGA bitfile is set to run on startup. So when I start the RT main vi it finds FPGA running on the cRIO and resets it. Thats why everything disappears and the cRIO loses connection, Eventually the cRIO somehow recovers.If I set the Invoke Method funktion to Run, the RT main vi keeps running.

Project file I have to clean up and delete company names, I attached a screenshot.

What if in build specs I set shared variable libraries to always included? Deploy network shared variables can only be included in build specs on the PC host Main vi.

[JensG69]

In my experience it is the usual behaviour that you loose the network connection during the start of the FPGA. A support engineer of NI once told me that the network is part of the FPGA on many cRIOs. Not sure if that's correct but at least it explains why you loose the network during the reset and start of the FPGA.

Regards, Jens

[Steffen01]

I will try today what happens without that "reset" bit. Putting a wait after that is maybe not a good idea, it took more than 10 minutes until the cRio appears again in MAX. Makining it "Run" gets an error 63001 FPGA is aready running, but I could get rid of that all together. The FPGA bitfile and the startup rtexe are running as soon the cRIO starts anyway.

[Steffen01]

erratic indeed. Compiled a new startup.rtexe and ftp'd it onto the cRIO. After reboot same again, no modules in MAX, Profibus module not working.

Played back the file from RAD utility and its back to normal. But when I ftp in, there is the latest startup.rtexe which I put there 10 mins earlier. Something happens when building a new rtexe......

[Steffen01]

I narrowed it down to the startup.rtexe. Some work and some don't. I just build several versions and ftp them on the cRIO and reboot.

I opened terminal to RS232 connection. The boot process is always the same. The trouble starts, when the startup.rtexe starts. Even the CPU load is identical every time. Seems the startup.rtexe is calling something and eventually gives up. This unfortunately does not show up in the terminal on the RS232 port.

[Steffen01]

found the problem. Startup.rtexe does not start FPGA does after reboot. If I run the RT Main vi which I posted earlier, deploys everything, then comes the 10s wait, then it starts the FPGA and alas, everything is working

Now I only have to find something how to trigger the FPGA I guess. This cannot be done from PC host, as the cRio is invisible to the PC until the FPGA is up.

Should this be a new thread?

If the startup.rtexe says its version 1.1.17 but the rest on the cRIO is from an image that had 1.1.15, would that make the cRIO ignore my startup.rtexe? Compile it as 1.1.15 just to try?

[Steffen01 · Accepted solution]

I mark this one as solved.

startup.rtexe does not start

Attached some snippets, put UDP sender into the RT main vi, compiled, not starting. When run from LV environment, it works. cRIO sender port should be 6000, worked for me