CRIO Deployment

[Etarkleson]

Hello.

In the past (and present) I have had a lot of issues with deploying my CRIO 9081+9144 ECAT, so I thought I would post my frusterations and findings here.

The problem has to due with modules deploying to scan engine when they are not supposed to (used in FPGA).

My Hardware

CRIO9081 in hybrid mode (Scan Engine + FPGA)

ECAT 9144 Extension Chassis

   I use the FPGA for high speed waveform aquisition and control. The scan engine handles all other IO.

Problem

Trouble with deploying CRIO project when using Hybrid Mode (FPGA + Scan Engine).

    A variety of errors can occur, RSI Module Errors, Missing module, CIE or CVT errors.

Why is it happening

This appears to happen because the Scan engine, when deployed, will find all modules inserted into a chassis and add them to the scan engine. If some modules are being accessed directly by the FPGA they can get added to the scan engine anyways. If you have this problem you will see something like below when you look at deployed channels in Distributed System Manager.

Note: Module 1,2 and 4 are my FPGA high speed channels and are set up correctly in the project, but the channels get deployed anyways (with wrong titles and channel names).

My Solution:

-Uninstall and Reinstall the Scan engine drivers on the RT target using MAX.

-remove modules used in FPGA from chassis temporarily

-Disable Autodeploy variables. Right click CRIO device in project explorer, select "disable autodeploy variables"

-Set Chassis settings to FPGA.

-Deploy project

-Set Chassis settings to SCAN Mode.

-Individually deploy each scan mode module by right clicking and selecting deploy.

-deploy ECAT chassis

-Deploy Project again.

-Reinsert FPGA modules.

So in other words, once you have "accidentally" deployed your modules that belong in the FPGA there doesnt seem to be a way to undeploy those modules without deleting them from the project (this is a problem if you have a high channel count system and dont want to rebuild the project). So you have to delete the scan engine driver and start over. Manually deploying each chassis should work, but I also remove the modules I dont want deployed because I found that sometimes they would be deployed anyways when deploying the chassis.

the trick is to use DSM to check the state of each module.

This has been a frustration for me for awhile so I figured I would post what I have learned and hopefully start a discussion as to why deployment can be tricky. I would also love to hear what some of the RIO experts have to say on this subject. Maybe there is something  I am missing.

Anybody else have this frustration? Anybody have a better, quicker solution?

Eric

[AndyClegg]

Eric,

We too have experienced some inconsistent deployment issus when using the Hybrid mode (some modules in Scan Interface, others in FPGA mode). However, when we did get a stable system and follow a consistent deployment process for both RT app and FPGA it seems to work reliably. I don't think we ever got a definitive view as to what aspect of the deploy was causing problems, and maybe your findings will help.

However, this is what we "observed":

1. Deployment seemed to get inconsistent when moving from a application that was fully Scan Interface mode, to one that was Hybrid.
2. Clearing the Build Cache seemed to help sometimes when a deployment failed (LabVIEW Project Explorer, Tools | Advanced | Clear Compiled Object Cache …)
3. Other times just repeating exactly the same build process a couple of times, would eventually give success.
4. We we creating a headless system, so using Run at Startup, and sometimes doing "Unset at Startup" before the deployment seemed to help

[Etarkleson]

Hi Andy,

Thanks for telling us your experience here. My hope is that we save someone time in the future. This made me think of a few things

1: When I initially build a project from ground up I will typically build the FPGA project section and then deploy that before adding scan mode modules and deploying those one by one. This usually works fine.

2: Where it gets frusterating is when you try to either change modules, or switch hardware. In my case I recieved a duplicate set of hardware to set up and redeploying the old project to the new hardware is what began causing trouble.

   I think using the RAD utility should help prevent this in the future.