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: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9Y3SAK
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:
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.
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.
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,
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?
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,
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.
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,
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.