cRIO-9074 Replication problems

[nblume]

I have an application developed for a cRIO-9074 and want to deploy the same application to several more identical cRIOs.  I am using both NICs on the controller.  When I use the NI RT replication tools to image the disk of the first cRIO and apply the image to the remaining cRIOs, I have two problems:

1) The secondary NIC on the target cRIO is disabled, even though it was enabled prior to imaging, and the secondary NIC on the source cRIO was also enabled.

2) The scan engine on the target cRIO does not work.  I can do nothing with the I/O modules.  It is as if they are not even there.

The only way I have found to recover from this is to reformat the target cRIO, reset the network settings of both NICs, install the NI-RIO software, and redeploy my application manually (directly from the project explorer).  I have a very hard time believing I am the first person to replicate a cRIO-9074, but I cannot find anyone else who seems to have this problem.  There has to be a way to deploy an application to several cRIOs at once.  What am I doing wrong or missing here?

[ErnieH]

I tried the replication tools with no success. End up bringing them to my development PC and doing it manually. The software seems to be designed as if you are always next to it with your development system with little or no thought on how to support these devices when you send them out to the field. Also running out of memory with a fairly small program on 2009 is an issue with us now. The tools need some major improvements. here is a link to an idea exchange item

http://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Complete-installer-for-Labview-RT-Targets/id...

[jkurtw]

The RT System Replication tools do not copy over bit files for the FPGA.

There are separate tools for that here. 

In a typical cRIO application the bit file is contained within the FPGA Open Reference VI on your RT VI diagram. If you are using scan mode, this is not the case, since you don't use that VI. The bit file is implicitly downloaded. Therefore, one workaround would be to compile an FPGA VI that has the correct number of scan mode slots in it and manually deploy that scan mode bit file in your RT VI. This way your bit file that powers scan mode can be shipped around with your RT VI.

Make sense? This paper explains what is going on as far as the bit file goes when you are in scan mode: RIO Scan Interface Under the Hood. 

To configure the second Ethernet port you will need to manually handle  /ni-rt/system/ethernet/netconf.ini  which contains the MAC addresses of a target. These MAC addresses are applied to a target along with the image, which can cause issues if you are replicating a target and not restoring one. This is a known issue that needs to be addressed.

Message Edited by jkurtw on 05-21-2010 09:38 AM

[nblume]

So if I understand you correctly, since I am using scan mode, I don't need to copy the FPGA bitfile explicitly.  After I posted my original message, I found a Real-Time Deployment Utility and gave it a try.  It worked.  I dug down into the VIs and don't see what that utility does that is different from what I did, but it worked nonetheless.  I still want to know why my own program to replicate cRIOs did not work.

The part about the secondary NIC make sense, but is rather cumbersome.  That definitely needs to be addressed by NI.

[jkurtw]

The replication utility you used must have included a step for copying the FPGA bit file that is stored in flash.

On cRIO, you have two ways of loading a bit file to the FPGA

1. Automatically when the chassis is powered on (bit file is stored in flash next to the FPGA)
2. Dynamically at runtime using the Open FPGA Reference function

When you are in scan mode, the first option is what happens. The scan mode logic for the FPGA is stored on flash and auto loaded. This bit file must be flashed onto the new cRIO as well, if you are going to be using scan mode. When you are developing, this step normally happens when you put the chassis in "Scan Interface Mode" and deploy those project settings.

If you are loading your own bit file with an Open FPGA Reference function, you don't have to worry about this step, because the bit file is stored in that function on your diagram. 

Make sense? 

[nblume]

When you say "new cRIO" do you literally mean a new one straight out of the box, or any cRIO being programmed via the imaging method?  I am trying to apply the image to cRIOs that have already been used in scan mode.  Wouldn't that mean that the FPGA bit file is already in the flash memory in the target cRIO?

[jkurtw]

I guess I mean any cRIO that is not being configured from the LabVIEW Project deployment process.

By applying an image to the controller programmatically, you wipe the project settings that were previously deployed. The scan mode IP for the FPGA is still present on disk once you apply the image, but the chassis may not be in Scan Interface Mode.

[nblume]

I used the Real-Time Deployment Application found at http://zone.ni.com/devzone/cda/epd/p/id/5986 with success, but I do not see any FPGA bitstream loading being done in this program.  Maybe it is because I don't know what I am looking for.  Can you tell/show me where this is being done in this program?  Why is none of this mentioned in the CompactRIO Developers Guide?

[jkurtw]

nblume,

We are continuing to update the CompactRIO Developers Guide over time. Looks like this would be a good topic to expand on. System Replication is covered in section five of the guide. Are specifically referring to the difference in bit file management being in the guide?

I looked at the utility you are using and I don't see anything specific to bit files, as you said. The project setting that tells the chassis it is in scan mode must be included in one of the configuration files that the utility includes in the RT disk image. 

How did you go about trying to build a replication utility yourself? Were you using the RT System Replication VIs included with LabVIEW Real-Time 2009?

[nblume]

"How did you go about trying to build a replication utility yourself? Were you using the RT System Replication VIs included with LabVIEW Real-Time 2009?"

Yes, I was using those VIs, the ones shown on page 209 of the guide.  The same ones used by the downloaded utility.

 "Are specifically referring to the difference in bit file management being in the guide?"

 If loading a bit file is required, even in scan mode, this should be mentioned in this section of the guide.  The only mention of bit files in the guide is as follows:

"NI-RIO System Replication Tools offer additional support to Real-Time Replication Tools by providing a LabVIEW API with functionality to programmatically download the FPGA bitfile to flash memory on the backplane. This is useful if you have a deployed application where the FPGA code needs to start running immediately and cannot be loaded in the standard way from the real-time code. With these tools, you can erase and download an FPGA bitfile to flash memory and set how a VI is loaded from flash memory."

I don't need any of those features or abilities, so when I read that paragraph it sounds as if I don't need to do anything related to loading an FPGA bit file.