My first post here and hope I can get some insight to an issue we are having at one of our facilities.
We recently upgraded all of our un-managed 10M/HD switches to 10/100M/FD managed switches and encountered an issue that has stumped others and an integrator we had on site.
The communicating equipment is a Modicon M340 and an Eaton VFD drive with a Modbus TCP adapter (OPTCI card). There are 12 devices in this comm path, and 6 are having issues talking back to our PLC. All on the same switch, the local switch is a N-TRON 7900 series managed switch 10/100 / non Gb.
Previously, all 12 Eaton drives had a similar issue. Although we were able to force a duplex mode on 6 of the Eaton drives (Using a different model Modbus TCP card), and the issue stopped. We forced a 10M/FD mode on both ends and comm issues ceased.
With the other 6 drives, we are unable to force the duplex modes (appears to be an issue with a software revision or firmware with talking to Eaton), and those 6 are the ones giving us trouble. Eaton claims the auto-negotiation should work fine, although I have read that there is a possibility some manufacturers have different implementations of "auto-negotiation".
It appears the 6 drives are in "auto negotiate mode". But when we set both sides to auto-negotiate (we can set this in the switch and we assume the drive is auto-negotiate/we can not see or change this setting), the drive fails to communicate and the switch claims a 100M/FD mode. I am assuming I am seeing a Duplex Mismatch (in my wireshark capture), although I can not confirm this.
Is there any chance someone can take a look at my capture and provide some feedback?
Thanks all and if more info is needed I can provide it asap.
Here is a link to my capture --
The older VFD's are probably not auto-negotiating Ethernet speed. Set their switch ports to just 10 Mb/s, as per the old switch.
You don't need the potential faster speed and they probably only talk at 10 Mb.
Thank you for the reply.
It turns out the speed and duplex settings for the Eaton Modbus OPTCI card was not accepting the changed settings values (on the switch side) until a power cycle of the comm card takes place.
After finding this out with much trial and error, we have cleaned up comms on our local subnet...
Modbus TCP - Dup Ack/FCS/Retransmit - Cycling the Power
Just some general comments about this. Many, if not most, microprocessor based devices only scan dip switches and jumpers when they power up. Also, some diagnostics are only run on power up. There are some PLCs which will not recognize new cards or rack configurations, until the rack power has been cycled. When you make changes in a microprocessor based device and the changes are not recognized, cycle the power. There are some other times where cycling the power may also be appropriate. If you are having strange effects in a microprocessor based device or in a computing device, cycling the power is always a good idea. Also, if you are testing your SIS devices, cycling the power on the SIS devices, particularly on the SIS logic solver, is a good idea (makes sure you test on the latest configuration and power up diagnostics are run).
William (Bill) L. Mostia, Jr. PE
ISA Fellow, FS Engineer (TUV Rheinland)
Winner of the 2018 ISA Raymond D. Molloy Award
Sr. Safety Consultant
SIS SILverstone, LLC