cRIO-9056 vs cRIO-9066 RAD images

[andre.buurman@carya]

Hello All,

I have a customer that standardized on cRIO-9066 which we we're able to deploy out of teh factory with an RAD image and reship to the customer.

Recently we made an upgrade to use the cRIO-9056 and there we had some problems with the imgae/deploy scheme using RAD.

1. It seems that the new cRIO's have module configured as DAQmx by default and this information is not included in the RAD image (or it's not deployed). This means that the RAD deployment process got an extra manual step.

2. It seems that the new cRIO's modules aren't configured through the deployment of a RAD image like did happen with the cRIO-9066. Particularly the Thermocouple module was configured a K in the imaged system, but was configured J in the deployed system (default setting)

I can imagine that the first issue could lead to the second to happen.

I would have expected that the module mode configuration (1x FPGA, 5x Scan Engine) would be part of the image and reapplied like with the cRIO-9066, just as I wou;d have expected that from the Thermocouple module configuration as it was before with the cRIO-9066.

Please advise if this is regression or deliberate design.

I would expect problems like this when deploying a SystemLink state too.

[JoshuaP]

My assumption is that the problem is related to the fact that DAQmx stores some of their configuration based on the specific instance (serial number) of the device.  I would expect that if you created the image, formatted the target, and then redeployed it to the same system it may work.

As a work around you could try and see if the NI System Configuration Hardware Export/Import would work.  In some cases it is a little more flexible and may fix the issue as a post image deployment step, but I don't know for sure.

I agree, that the DAQmx driver should at least be able to apply the original configuration to the new modules based on the fact that they are the same model and are in the same location.

[andre.buurman@carya]

Thanks Joshua for your answer.

I tried your suggestions and compiled a screenshot showing the installed software.

The screenshots below show in order:

1. The installed SW and the module programming mode of Mod1 for the imaged system (no DAQmx installed as it isn't used)

2. The Export dialog showing it wants to export data for software that isn't installed.

3. The failure message, most likely due to the fact that DAQmx isn't installed.

In conclusion: Export and import isn't usable to correct the programming mode, I wasn't able to verify if it would also correct the default J type TC to the image's K type.

[JoshuaP · Accepted solution]

You may want to try and set the mode programmatically when your application initially starts up.  This way you don't have to reply on anyone to configure it from MAX.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kI1TSAU&l=en-US

[andre.buurman@carya]

Thanks Josh,

I think we will advise the customer that we modify the code so it will configure the programming modes at start-up and also reconfigures the TC module to use the proper type.

Do you think the KB will also be applicable to cRIO-9066 targets?