plc 5/60 1885 Enet really slow

Hi,

I'm trying to figure out why one of our plc's is really slow.

One switch in its path had autonegotiate enabled, and it throttled the switch to half duplex. I disabled autonegotiate, and It now shows as full. The plc shows full duplex as well.

I also noticed that the plc itself has a low baud rate, when all the other plcs are high. Other people in the office insist that doesn't matter because we use Ethernet, and not serial.

RSView32 is fine (OPC linked) but rslogix can barely stay connected.

Any ideas.

I take it you mean a 1785-ENET module? What series is it?

Could be the same road I've been down before. Searching this forum for 1785-ENET will give some tips but right off the bat...

A few quick thoughts while awaiting your confirmation:
- Only the series C will communicate full-duplex 100 MB.
- If you have a managed switch, make sure the port settings MATCH those of the ENET card.
- We've had faulty series C cards set up for full-duplex 100MB that will default to 10MB.
- New additional network traffic will sometimes reveal faulty card issues.

PLC-5/60 D/B - 1785-ENET 3.41

firmware 3.41 02-Mar-06 (C/B)

The firmware is a C

The same module worked far betting a year ago.

This tech note covers ENBT diagnostic counters for Ethernet Storm events, among other things. Basically, an Ethernet storm is when the card shuts down communications for a time period if it receives too many packets in a 10ms period. The ENBT has a built in web page which contains configuration info and diagnostic counters. Open up a web browser and type in the IP address to view this web page.

In our situation, we had multiple 1785-ENBT/C cards fail over time. Even though the Auto Negotiate box was checked and 10/100 Mbps Full Duplex/Half Duplex was selected in the configuration, the faulty module would only communicate at 10 Mbps. These were the only units on which we'd get the Ethernet storms & comm issues. Those modules ended up getting replaced. If you do decide to purchase any 1785-ENBT cards online, BE CERTAIN that you specify series C if you want 100 Mbps communications.

Our diagnostic files stop at word 43. It seems storm counters were added on a later model. Storm count could very well be the problem, but I have no way to diagnose it.

Can you ping the card? If so, you can use a web browser (Internet Explorer, Chrome, Netscape Navigator, etc.) and enter the IP address in the address bar. This will connect to the built in web page for the module. The web page contains the diagnostic counters, among other things.

Here's a screen shot of the diagnostic web page

Okay, I see packet storms at the bottom right.
We have zero.

I do have 3346 FCS errors.

Compass said:

Okay, I see packet storms at the bottom right.
We have zero.

I do have 3346 FCS errors.

Click to expand...

FCS errors are most commonly caused by noise on the data network. Network noise can be created by cabling located too close to noise sources such as lights, elevator motors or other heavy machinery. Cabling that has not been pulled and terminated in line with the appropriate specifications can also generate noise. Too much wire left untwisted at termination -- or runs that are too long or bends that are too tight -- can introduce noise from external sources or from crosstalk among pairs. Poorly manufactured components can compound such problems.

http://searchnetworking.techtarget.com/tip/Common-network-errors-and-causes

I actually fixed a duplex mismatch yesterday, and nothing changed. Is it possible that when the FCS counter reaches a certain number the speed gets throttled?

I don't want to lose information that I use to troubleshoot, but could it be as simple as resetting the counter?

Compass said:

I actually fixed a duplex mismatch yesterday, and nothing changed. Is it possible that when the FCS counter reaches a certain number the speed gets throttled?

I don't want to lose information that I use to troubleshoot, but could it be as simple as resetting the counter?

Click to expand...

I don't think so, but there's no harm in resetting the counter anyway. That will make it easy to see if you're still getting the errors.

Have you tried to disconnect the module from the plant network altogether and connect to it directly with an HMI or with programming software, to see if the problem persists?