Turck I/O block communication fault

Hello Expert,
I am just wondering if someone can help me with my current situation.

I have 5 robots controlled by 1 Allen Bradley PLC. It's a material handling application so each robot has a gripper on EOAT. we are using Turck I/O block on each EOAT to connect my clamp, unclamp and overtravel sensors for the grippers.

On my PLC side, I am using a generic ethernet module in I/O tree to add my turck i/o block and all the turck blocks for each robot configured in the same way.

Now, One of the Turck block on EOAT having a communication issue with my PLC, seems like connection timed out or module status: fault and after a couple of seconds (between 5 to 30 seconds), it makes a connection itself.


I thought it could be a problem with my M8-RJ45 ethernet communication cable, so I replaced that but it didn't help so eventually, I replaced the Turck block but still having the same issue.

I research online and found a couple of posts related to this issue people faced in the past and they were talking about maybe some packet loss during the communication because the module is not configured properly but my another 4 Turck i/o blocks on other robots are configured exactly same way and they all are the same model and never had suck issue with them.

I am also thinking about to replace the power cable because I am thinking my power cable might be flickering.

If anyone can help or give your opinion, I would appreciate

Thank you,

Is the fault-and-reconnect cycle continuous, or does it eventually make and sustain a connection for a period of time ?

The first thing to do is to figure out the nature of the fault. Highlight the device in your I/O tree and look at the connection status at the bottom of the I/O tree, and look for a fault code. 16#0204 is going to be the most common timeout failure.

You can use GSV (Get System Variable) instructions to get the connection status for that device in logic (look at the GSV/SSV Objects entry in the Help system) so you can create logic traps for the error code and to determine how long the failure is.

If this is a configuration problem you're going to see the same cycle of connect -> failure -> disconnect -> reconnect again and again.

Ken Roach said:

Is the fault-and-reconnect cycle continuous, or does it eventually make and sustain a connection for a period of time ?

The first thing to do is to figure out the nature of the fault. Highlight the device in your I/O tree and look at the connection status at the bottom of the I/O tree, and look for a fault code. 16#0204 is going to be the most common timeout failure.

You can use GSV (Get System Variable) instructions to get the connection status for that device in logic (look at the GSV/SSV Objects entry in the Help system) so you can create logic traps for the error code and to determine how long the failure is.

If this is a configuration problem you're going to see the same cycle of connect -> failure -> disconnect -> reconnect again and again.

Click to expand...

Hi Ken, Thank you for the reply.

So I am getting two fault

16#0204
16#0203

It disconnect first, attempt to reconnect and make a connection again and then connection sustain for a while sometimes for 1 hour and then disconnect again and attempt to reconnect and make it again.

So it always make a connection after the interrupt,

But just wondering if it is a configuration error then why my other 4 I/O block is not having this problem? they are configured same way as this one and same number of sensors connected to individual I/O block.

Any thought?

Thank you for the input again, much appreciated