AB - Generic Ethernet/IP Module Timeout

Greetings to those of you reading this,

I am using a 1756-L62 with RSLogix 5000 to implement a new drive interface for a customer. The drives are not AB drives so I had to create generic Ethernet Modules for each drive. Each drive has a total of ten words in and ten words out.

Everything has been working smoothly but my two simulator drives time out. Communication between the PLC and Drives stop for a total of four seconds before resuming. This is across all I/O data on the drive.

Using wireshark I can see that this happens right after I see a TCP RST request.

I don't really see any settings in RSLogix that I can adjust and I'm not even sure it is cause by the PLC. The only devices on this network are the two drives, my laptop and the AB PLC.

Has anyone run into a similar problem?

I would start by increasing the RPI rate, could be running to quickly to get all the data. Default is 10 or 20 ms, take it up to 80 and see what happens.

Paully's5.0 said:

I would start by increasing the RPI rate, could be running to quickly to get all the data. Default is 10 or 20 ms, take it up to 80 and see what happens.

Click to expand...

That was something I had thought of. It was initially 20ms, so I tried 200ms then 500ms. Same issue.

First I need to mention the obvious but still critical basics.
100% sure all IPs on network are unique?

Disable all PC firewalls.

Next Replace your router/switch with a different one and recheck.

"Simulator" drives? So you are not working with the actual hardware?

It is actual hardware, but without and\y of the actual high voltage hardware. So all of the low voltage hardware with simulated high voltage bus, etc.. All boards are the same as complete drives.

I will check again for duplicate IP addresses.

I have tried multiple switches. My original assumption was that the switch was performing a function known as smart packet detection. This can cause TCP RST's. But no dice.

I've taken everything off the network besides the drives and controller, but I will retest after checking IP addresses once again. Unicast is enabled on the ethernet modules, I'm assuming there is no reason to bother changing that to test.

The drive's are set to 10Mbps just like the controller's ethernet card, but I cannot make the drive's run half-duplex like the card. I'm actually not sure if they are running full or half duplex. Potential issue?

Is a firmware update on the ethernet card a bad idea?

The duplex and speed mismatch is a potential issue. Ideally, everything involved (PLC, switches, drives) would all use auto-negotiation and run at 100/Full when conditions are nominal.

Do you have a specific reason for wanting to run at 10 Mb/sec ?

Do you mind specifying what make and model of drive you are using ?

I think if you look upstream in the Wireshark capture you'll witness the connection failure happening. The TCP Reset is just the ControlLogix module attempting to do a graceful shutdown of the TCP connection.

What you will probably see is a circumstance where the drive fails to send a reply packet for more than 4x the RPI interval.

How long does the connection stay in a Running condition ? Does the drive ever actually start and begin putting out power ? Is the connection failure periodic, or predictable ? Do you see a fault code in the Connections tab for the Generic Ethernet Module object in Studio 5000 ?

Can you ZIP a portion of the Wireshark capture and post it here (or on a Google Drive or Dropbox link ) ?

sjepps said:

The drive's are set to 10Mbps just like the controller's ethernet card, but I cannot make the drive's run half-duplex like the card. I'm actually not sure if they are running full or half duplex. Potential issue?

Click to expand...

Im not sure but Rockwell Tech Support told me it is best to set All devices to AUTO speed negotiation to prevent "issues"

Paully's5.0 said:

I would start by increasing the RPI rate, could be running to quickly to get all the data. Default is 10 or 20 ms, take it up to 80 and see what happens.

Click to expand...

Ken Roach said:

The duplex and speed mismatch is a potential issue. Ideally, everything involved (PLC, switches, drives) would all use auto-negotiation and run at 100/Full when conditions are nominal.

Do you have a specific reason for wanting to run at 10 Mb/sec ?

Do you mind specifying what make and model of drive you are using ?

I think if you look upstream in the Wireshark capture you'll witness the connection failure happening. The TCP Reset is just the ControlLogix module attempting to do a graceful shutdown of the TCP connection.

What you will probably see is a circumstance where the drive fails to send a reply packet for more than 4x the RPI interval.

Can you ZIP a portion of the Wireshark capture and post it here (or on a Google Drive or Dropbox link ) ?

Click to expand...

I will post a copy of the wireshark data tomorrow. The drive's are running at 10Mbps. I don't believe there is a specific reason, aside from not needing more than that.

GTUnit said:

Im not sure but Rockwell Tech Support told me it is best to set All devices to AUTO speed negotiation to prevent "issues"

Click to expand...

It is set to auto, but I'm not sure what the drives are actually doing. I'm assuming the ethernet module is smart enough to know. I just can't confirm it

AUTO speed negotiation to prevent "issues"

Click to expand...

I will add "unless there's a good reason and you know what you're doing".

Good reasons include the presence of media converters or end devices that only support fixed duplex and speed.... and not much else.

Bad reasons include "the cables are all too long and and poorly terminated and submerged in a lagoon and we have an alligator problem."

Just a couple of weeks ago I was investigating a system where several of the managed switch ports had been hard-set to 100 FULL, but the connected devices didn't have the ability to have Auto-Negotiation disabled.

My conjecture is that the switches were intended to have Ports 1 and 2 used as the link-in and link-out daisy-chain ports... that makes sense with the way the machine is laid out. But cords got moved and plugged into the wrong ports, and nobody went back to change those port settings.

The problem is that devices that use Auto-Negotiation don't just "auto sense" that they're running at the fastest speed. Some of them will still probe periodically for link rate and duplex by dropping the link and re-sending the negotiation commands. No big deal on an office PC network. Big deal on a cyclic I/O connection.

We changed the ports back to Auto-Negotiate and reset the error counters, and there hasn't been a single error in two weeks.

Ken Roach said:

I will add "unless there's a good reason and you know what you're doing".

Good reasons include the presence of media converters or end devices that only support fixed duplex and speed.... and not much else.

Bad reasons include "the cables are all too long and and poorly terminated and submerged in a lagoon and we have an alligator problem."

Click to expand...

I was just yesterday teaching someone how to set up a Stratix 5700, and they asked under what circumstances you would (and would not) disable auto negotiate.

I wish I could have that time over again, so I could use this answer. That's the best thing I've read all week

Updated firmware on the ethernet card. Three major revisions different.

Things seem to be doing well now.