We are having a regular error "Error: "IODrvEthernetIP: Connection failure. (16#1)" "Extended Status: Target connection not found. (16#107)"" and last night the PLC crashed and this is the only error displayed in the log.
We have 6 identical Cube67+ BN-E V2 (Murrelektronik Gmbh) connect in 1 scanner.
The IOTask and ServiceTask still on factory default configuration (cyclic with 10ms and 20ms)
How can we solve this error and is it this error possible to crash the system? (It was necessary to restart the runtime and start the PLC again).
We are using the Codesys inside a Raspberry Pi 3 model B+
The software was completely updated 2 months ago, in the begging of the project.
Codesys v3.5 SP18 Patch 3+ (64-bit)
Codesys Control for Raspberry Pi MC SL v4.6.0.0
Ethernet drive v4.1.0.0
Ethernet/IP Scanner v4.4.0.0
I made the update of the EIP and all other packages that it's giving attentions flags to update.
Even with this update, the error still there and the runtime reboot one time in the last days.
There is already more than 3 weeks that I found this error and still not solved.
I fear for the possibility of a system crash during the full production of the machine.
Can someone give the an information or a way to debug this failure?
Hello Brazadio: Status 0x01 means connection manager error in EtherNet/IP. Extended Status 0x203 for Status 0x01 means connection timeout. For some reason the EtherNet/IP adapter stops communicating with the CODESYS Scanner. I do not think the probelm is in CODESYS, rather, ti seems to be that either there is a problem with the switch or cabling, or the EtherNet/IP adapter has a problem. Please see attachment. I think you need to take Wireshark traces to figure out the problem.
Problem found! The was to much overhead. Codesys was reaching 70% of cpu usage + codesysedge 10%. We also have nodered running. which was constantly keeping the CPU usage high. Increasing the time from 10ms to 500ms improved the performance and reduced the errors. Would be nice to define the niceness (priority) of codesys. Now it is zero.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is good. If the process tolerates it, if you increase the RPI (requested packet interval) this would also easy CPU use, because the EtherNet/IP scanner stack will be executed with less frequency, which should help with the CPU use.
Edit: I see, do you mean by "increasing the time" increasing the RPI? if so, your solution is what I am explaining. Good to know you fixed it.
Last edit: AlfredoQuintero 2023-04-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, since it's a slow process, we increase the RPI time from 10 ms to 100 ms (Maximum).
Also I noticed (using ping to all over the system) that it was normal (one time each 30 min) to have a response time of 35-45 ms between the systems, and with the RPI was default (10ms) and the timeout was default (4x RPI), it was easy to the system get this flag you lost communication.
Thanks for the help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We are having a regular error "Error: "IODrvEthernetIP: Connection failure. (16#1)" "Extended Status: Target connection not found. (16#107)"" and last night the PLC crashed and this is the only error displayed in the log.
We have 6 identical Cube67+ BN-E V2 (Murrelektronik Gmbh) connect in 1 scanner.
The IOTask and ServiceTask still on factory default configuration (cyclic with 10ms and 20ms)
How can we solve this error and is it this error possible to crash the system? (It was necessary to restart the runtime and start the PLC again).
We are using the Codesys inside a Raspberry Pi 3 model B+
The software was completely updated 2 months ago, in the begging of the project.
Codesys v3.5 SP18 Patch 3+ (64-bit)
Codesys Control for Raspberry Pi MC SL v4.6.0.0
Ethernet drive v4.1.0.0
Ethernet/IP Scanner v4.4.0.0
Thanks for you atttention.
Last edit: brazadio 2023-03-16
try to update to EIP 4.4.1.0
https://www.codesys.com/fileadmin/data/Images/System/Releaseinformation/Teaser-Note-CODESYS-EtherNetIP-4410.html
I made the update of the EIP and all other packages that it's giving attentions flags to update.
Even with this update, the error still there and the runtime reboot one time in the last days.
Error in attachment.!
Hi,
There is already more than 3 weeks that I found this error and still not solved.
I fear for the possibility of a system crash during the full production of the machine.
Can someone give the an information or a way to debug this failure?
Thanks.
Hello Brazadio: Status 0x01 means connection manager error in EtherNet/IP. Extended Status 0x203 for Status 0x01 means connection timeout. For some reason the EtherNet/IP adapter stops communicating with the CODESYS Scanner. I do not think the probelm is in CODESYS, rather, ti seems to be that either there is a problem with the switch or cabling, or the EtherNet/IP adapter has a problem. Please see attachment. I think you need to take Wireshark traces to figure out the problem.
Brazadio, por favor revisa la captura gráfica anexa. CODESYS te reporta estaus 0x01 y estatus extendido 0x203. Como te muestor en el extracto de la especificación CIP, este estatus extendido siginifica que el adaptador deja de comunicarse con el scanner CODESYS. Yo no creo que esto sea problema de CODESYS. Puedes estar teniendo problemas con el adaptador o con el switch. Tienes que tomar capturas con Wireshark para ver por qué termina la conexión.
Problem found! The was to much overhead. Codesys was reaching 70% of cpu usage + codesysedge 10%. We also have nodered running. which was constantly keeping the CPU usage high. Increasing the time from 10ms to 500ms improved the performance and reduced the errors. Would be nice to define the niceness (priority) of codesys. Now it is zero.
This is good. If the process tolerates it, if you increase the RPI (requested packet interval) this would also easy CPU use, because the EtherNet/IP scanner stack will be executed with less frequency, which should help with the CPU use.
Edit: I see, do you mean by "increasing the time" increasing the RPI? if so, your solution is what I am explaining. Good to know you fixed it.
Last edit: AlfredoQuintero 2023-04-05
Hi.
Yes, since it's a slow process, we increase the RPI time from 10 ms to 100 ms (Maximum).
Also I noticed (using ping to all over the system) that it was normal (one time each 30 min) to have a response time of 35-45 ms between the systems, and with the RPI was default (10ms) and the timeout was default (4x RPI), it was easy to the system get this flag you lost communication.
Thanks for the help.
No problem. Let/s hope the project goes smooth from here.