Showing results for 
Search instead for 
Did you mean: 

cRIO 9074 and NI 9144 behaviour and troubleshooting

T81, I see two other tasks you can try with the cRIO device.


a) what happens if you click “undeploy” in the target on the LabVIEW project? What happens if you deploy the configuration after this step? Does the same errors show?


b) you can always try formatting the target using NI MAX and loading the software one more time, to discard a software corruption in the cRIO:

0 Kudos
Message 21 of 38

I can undeploy without errors. Also after the procedure described on my previous (large) post, I am not able to reproduce the same messages again. I can deploy/undeploy without any error messages.

The situation now is the following:

  1. Under the working project, the Device0 (first EtherCAT) seems to have no problem. I can change between all modes under "Online Device state..." , and finally successfully enter "Operational Mode"
  2. Device1 (second EtherCAT) has the same problem as before. It cannot enter "Safe Operational Mode" therefore neither "Operational Mode". The error is the same:
    Error -2147138442 occurred at an unidentified location
    Possible reason(s):
    The module cannot be found. If the physical module exists, and the device is in FPGA mode, recompiling and downloading may fix this problem.

Any advice?

0 Kudos
Message 22 of 38

OK I believe we are coming to an end...
I replaced again the controller and added the EtherCATs in a new project.

They work as they should BUT I observe the following strange thing:
The second EtherCAT is imported in the project along with the FPGA and User-defined variables that exists only to the previous project!

When I remove the EtherCAT master from the project and re-import it, the first EtherCAT is imported along with the C-modules but the second device is unable to import any module... It is simply empty. Both are in Operational mode.
Then I toggle the controller from FPGA to Scan Engine and back. Now the device2 is able to import all the modules, without traces from the previous project, but cannot enter Operational mode, reporting the familiar errors.
I have tried with one EtherCAT at a time and device1 has no evident problem. It works without any problem and I can trigger DOs and read AIs. I can remove it and re-imported to my project without problem.
The second EtherCAT does not have this behavior, which leads me to the conclusion that it is malfunctioning.
In a week or so I will have a new 9144 and hopefully this will solve my problem.
I'll keep you posted.



0 Kudos
Message 23 of 38

Hi there again!
A new NI 9144 has arrived earlier today.

It has been replaced and I have recompiled the FPGA VIs.

While trying to run the project, the situation remains the same.
The EtherCATs cannot exit configuration mode.


On a new project when importing the EtherCATs, no errors occur.
But, when I am trying to deploy the C modules I get the same IAK_Shared error as described previously
and the situation rolls back to the same problematic situation...


I'll try again on Monday.


Best regards,

0 Kudos
Message 24 of 38

T81, I believe at this point the best option we have is to use that new project which works, and port your application there, so you don't have to spend more time troubleshooting trying to find a misconfiguration/corruption that seems to be hidden somewhere.


All the best,

0 Kudos
Message 25 of 38

As a mentioned above, it does not work even in a new project. The problem emerges after C modules deployment. I'll have to check them one by one I suppose. Is it possible a malfunctioned C-module render the slave inoperative?

0 Kudos
Message 26 of 38

Hi T81,


I didn't link the sentences about the new project not showing errors, and having troubles deploying the modules, too. I apologize!


I tried searching in the thread if we had already tried switching the computer you're using to program the devices, have you given that a try? Do you get the same errors?


I remember you already switched the cRIO 9074 controller and that changed the behavior of the system, correct? What happens with the "working" cRIO and the new 9144?


Just to recap, do you know which is the element in the system that causes the error (computer/code/cRIO/slave), or we are still searching for that?


All the best,

0 Kudos
Message 27 of 38

Hi Oscar,

I still try to figure it out. I am not sure.

I will try another computer too with LV2016. Currently this unit runs on LV2009.

But I think though there is a problem with LV2016 & Xilinx tools and it is not possible to compile fpga vis. Can you confirm this?

Next thing, I'll try to figure it out if a C module is responsible.

Nevertheles, currently I am dealing with the following behaviour:

In a new project, importing the controller and the ethercats shows no errors. Also creating a dummy vi with one DO and one AI runs as it should. I can trigger the DO and read the AI. But if I explicitly deploy all the modules then the system is crippled.

So I tend to believe that a C module is propagating the problem.


0 Kudos
Message 28 of 38

Hello T81,


You can find the  LabVIEW Version & Corresponding Xilinx Compilation Tools Support here: Compatibility between Xilinx Compilation Tools and NI FPGA Hardware.


I guess part of your test to discover which C series module is generating the problem will include the depoyment of invididual modules, instead of deploying all of them, correct?


Keep us posted. Regards,

0 Kudos
Message 29 of 38

Thank you Oscar for the link.

Indeed I am checking the modules 1 by 1. I have some results e.g I found a dead module (AI), undiscoverable by either EtherCATs neither by the RIO controller. I replaced it by a spare.

I'll post the summary in a couple of days since there are a lot of modules and I get kinda strange behaviour on some of them.


0 Kudos
Message 30 of 38