Lessons learned from updating a cRIO

[Tim_S]

Still learning about the cRIO, but thought I'd share some of what I've learned recently. Some background on what was going on...

 

We had a driveline failure on two test stands out at customer site. There are sheer pins in the driveline designed to fail rather than send massive torque through a gear set in ways that is just BAD as it can lead to dynamic testing of the hard guarding (which is always fun!). Long story short, there was a failure more of the sheer pins that required detection of the sheer pins breaking. Worst case conditions is the break occurs at 6000 RPM and the only thing that we have already in the system is a 1 mm wide match mark on a 25 mm diameter disk. We found some laser sensors that could pick up the mark and bench tested the system. Everything looked good, so we integrated the bench test in the project, compiled everything and went to update the cRIO. This involved adding C series modules (electrician on site) and remote update of the cRIO application and bitfile through TeamViewer.

 

Lessons learned...

1. Install the NI-RIO driver on a PC connected to the cRIO before it is 1000s of km away. Transferring 4GB of installer over a flakey TeamViewer connection is not recommended.

 

2. Replication and Deployment (RAD) utility works well for the RT portion, but may not be able to install a bitfile to the FPGA.

 

3. The example "Get & Set Real-Time System Image" can work when RAD does not. Building the example into an executable that can deploy a selected file is very useful.

 

4. It is possible to create a image using RAD without errors from an identical cRIO that does not have all of the C series modules. There will not be an error, however the image will not deploy/set (sometimes without an error message).

 

5. Shared variables can function correctly with different LabVIEW versions (person helping me accidentally converted everything to 2015 for the image that did eventually install).

 

I'm sure I'm missing something, so would appreciate any insight people have.

[Jordan Kuehn]

1. I would download from NI directly or host the installer and download from there on the remote PC.  Not a direct transfer.

2. We have had no issues using the RAD for RT and FPGA updates.  What did you discover?

3. 

4. 

5. This has proven useful when we migrated several dozen tools from LV 2010 to 2013.  Host PCs were used as backups at times during the migration, and sometimes they were of differing versions between tool and PC.  Of course, other things may break instead...

 

Props for successfully making a change of this magnitude remotely.  We update our tools remotely, but always after testing the procedure on a couple that are in the shop for maintenance.  Not really an option for this application.

[Tim_S]

1. I would download from NI directly or host the installer and download from there on the remote PC.  Not a direct transfer.

2. We have had no issues using the RAD for RT and FPGA updates.  What did you discover?

3. 

4. 

5. This has proven useful when we migrated several dozen tools from LV 2010 to 2013.  Host PCs were used as backups at times during the migration, and sometimes they were of differing versions between tool and PC.  Of course, other things may break instead...

 

Props for successfully making a change of this magnitude remotely.  We update our tools remotely, but always after testing the procedure on a couple that are in the shop for maintenance.  Not really an option for this application.

Thanks. 

 

I would have downloaded from NI directly, but had to deal with the customer's network.

 

I don't have a reason why RAD didn't work. It would always fail when trying to flash the bitfile. I dug up the logs with the two error codes I was getting in RAD:

-2147220304 at nisyscfg.lvlib:Restart.vi -- NI System Configuration:  (Hex 0x800404B0) Timeout while waiting for reboot. System is offline.

-52003 at nirioFlashWriteBitstream.vi -- NI Platform Services:  An unexpected software error occurred.

The PC and cRIO have a direct connection. There are no physical network issues.

[Omar Mussa]

This is really good info, thanks for sharing your experience.  For #2, are you dynamically loading your FPGA Bitfile from disk (I'm guessing you are not)?  I have a feeling that if you did this, the RAD image would work (your bitfile would just be another file transferred via the image and the RT app would load the FPGA on startup from a known location on disk - I haven't tried this but I'm guessing this is how it would work).

 

Dynamically loading the FPGA might not be the best option for all deployment scenarios of FPGAs but it would probably insulate you from this issue.

[Tim_S]

For #2, are you dynamically loading your FPGA Bitfile from disk (I'm guessing you are not)?

 

That's a good point. I thought I was downloading the bitfile when the RT executable starts (using Download method), but was unable to locate the bitfile anywhere on the RT side.

[smithd]

if you have the bitfile opened using the normal FPGA open, it should be compiled into the rtexe. It should also work if you are referencing it by path. The error you posted relates to flashing it on the FPGA, which is only necessary if you want the FPGA to boot before your exe does.