Goodmorning,
I am reaching out to seek your assistance regarding a recurring technical issue we’ve been experiencing.
Every day, our customer encounters an error that appears to happen randomly, making it difficult to identify the cause.
The error manifests as Ethercat Master remains stuck at 'Init' and not able to switch to 'OP' any longer.
This happens with no apperent cause. Also with drives standstill no torque, no power and no user input.
At this moment, when stuck, we wish we had more information about devices and master itself, but due to the need to avoid interrupting the client's production, our customer simply reboot the system to start again. This made it challenging to gather more data during the error occurrences.
Therefore no relevant advisory of problems comes form PLC functionBlocks to diagnose Ethercat master and slaves or from the CtrlX log.
Unfortunately, SynchUnits we added in the intent to narrow down the problem didn't help.
To provide some context, our architecture consists of 49 nodes ( see Fig 1 ) : mostly RTA Drivers + 3 X Hub Odot + ADF_Web
CtrlXWorks : 1.20 Ctrl-Core : V1.20 App EthercatMaster : V1.20.1 ( see Fig .3)
When possible, we’ve conducted a few tests to gather some clues and here's what we discovered :
- When scanning the network, all the devices are scanned with no problems making exception for the 3 x Odot Hubs.
This case only Hubs are being detected. No children detected as yellow warning displays.
ESI files are presents. It takes an additional scan to fetch Odot's children modules.
This is the reason why our customer at first commissining manually added every and each device on the CtrlX-IO configuration. - Removing last device ( our case Tastiera 3 en=>Keyboard 3 ) solves the problem.
Odot's children scan works at first shot. Switching to OP was much faster ( about 30 sec. ) compared to the previous case ( 1-2 minutes )
This is very reassuring as the problem hasn't shown for 2 days now.
The bad part is that "Tastiera 3" is required. So this can only be a temporary solution.
We have planned to :
- make some tests to pinpoint the root of the problem by switching positions and replacing devices with focus on the last one " Tastiera 3".
- prepare a backup CtrlX-Core updated to 1.20.13 to replace the actual one limitating the impact on production.
In addiction, we've enabled Ethercat tracing for all severities. ( Fig .2 )
In attachment,
230020_CtrlX-Mater.zip contains both EthercatIO and PLC Project.
ODOT.zip contains ESI files and product documentation
Despite these efforts, I admit it is not easy investigate as long as the machine is in production and each suggested test is deemed irrelevant.
I would greatly appreciate your opinions and any suggestions you might have on how to further investigate or resolve this issue.
Thank you for your time and assistance. I look forward to your insights!
Best regards,
Massimo Grattieri