EtherNet Issues And a Question

You guys have been helpful in the past and I have an issue that has come to light today.

I have a canning line that has 3 SLC505's controlling the conveying lines. I didn't do the install but the guy before me liked to play with ethernet communication and I believe got carried away.These processors communicate with each other via "read" messaging.No "writes"


Anyway the company hooked up a data collection system that is on their business ethernet and communicates with the plant ethernet through a gateway address.

Now since they did this we are getting random communication errors "634" on the main panelview. The panelview communicates with all 3 PLC's.

When they disconnected the data collection system the problems seem to have gone away.

Question:
Is it possible that the data collection system was slowing down the ethernet causing the plc communications to fault???

Is there a way to visually (thru a program) see what's happening???

Capacity and Performance

Ethernet networks are typically so fast that the network is not the bottleneck. It's either the controller's capacity or performance that is the problem, or a bad physical link or configuration problem is degrading communications performance.

The SLC-5/05's Ethernet daughtercard performs all the link and TCP/IP functions for the controller, but the controller has to process all the MSG instructions and external data exchanges during the housekeeping section at the end of the controller scan.

You can trade scantime performance for communication performance by setting bits in the Status file. Look at the Channel 1 tab in the Status File data table view for the "Comms Servicing Select" and "MSG Servicing Select" bits.

Examine the MSG instructions in each controller. Often inexperienced programmers write them to re-trigger just as soon as the previous message is complete, which permanently occupies a communicaiton buffer. Stack up a few of those MSG instructions in the same program, and you're going to have the controller's outgoing buffers so full of MSG instructions that there's no room for replies to commands from PanelView and datalogging applications.

Link configuration and performance

PLC-5E and SLC-5/05 controllers for many years had a 10 Mb/s Half Duplex Ethernet port. Modern ones (PLC-5E Series F and SLC-5/05 Series C hardware) have 10/100 Mb/s Full Duplex auto-negotiating ports.

It is not uncommon for an unwary installer to connect an older half-duplex SLC-5/05 to a switch that doesn't handle a mix of 10 Mb/s and 100 Mb/s devices well, or doesn't handle a mix of Half Duplex and Full Duplex devices well. If you have a managed switch, check the Port status and make sure that the switch port has the same Speed and Duplex as the controller.

Diagnostic Information Collection

I have a strong recommendation for determining Allen-Bradley Ethernet interface performance and status: use the built-in HTTP server.

There's a freeware utility called "HTTrack", that you can point at the IP address of the SLC, and it will create an offline file that includes all of the status web pages in the SLC. This is a great way to get all the status information about how many packets/second, and how many TCP connections to what devices the SLC is currently connecting to.

I understand what you're saying.

But why when the data collection system is removed and the link to the business ethernet is broken do the errors disappear?

Ken

Channel Configuration Screen:

I noticed that the Auto Negotiate box is not ticked and the port setting says "10 Mbps half Duplex Forced"

Shouldn't this be ticked???

All his PLC's are set the same way.

check what your switch can do

if it can do 100mbit Full duplex force that

auto is fine but might as well force 100 if it can do 100FD

As I'm implementing a scada system for my location I've been checking and changing IP's to be part of the vlan for the scada and every time I see 10HD forced I force 100FD as it was already forced so I try to minimize changes

The guiding principle for configuration of speed and duplex of an Ethernet port on any controller is to match the connected switch or hub.

If the SLC is connected to a 10 Mb/s half-duplex only hub, hard-set it for 10Mb/s HD. If it's connected to an autonegotiating switch, set it for autonegotiate.

The problems I usually see with speed and duplex are when the SLC is hard-set for 100 Mb/s Full Duplex, but the switch mistakenly autonegotiates for Half Duplex. Collisions galore ensue.

I don't think that's what is happening on your system. I think that the addition of the business system traffic is taking up some of the SLC's connection resources (like TCP connections), which leaves the controller juggling connections and disallows the PanelView traffic.

Post more about the switches you are using and what sort of diagnostic capabilities they give you.

It's negotiation, not detection.

Important: I do not think this is the heart of the problem in this thread, but it bears mentioning.

I learned the hard way that Autonegotiation is a feature that *both* devices on an Ethernet link need to support for it to work.

When one device support Autonegotiation and the other does not (or it's been turned off), the principle of parallel detection takes over. This very often results in a duplex mismatch.

A good article on this exists at wikipedia:

http://en.wikipedia.org/wiki/Autonegotiation

It was said that when the data collection system was disconnected, the errors went away.


Sounds to me like someone needs to review the messaging within the SLC's. Make sure that they only transfer on data change. Also ensure that all the data being transferred is in continuous data. It very well may be that the system works fine in a stand alone configuration because all the connections available is the limit being used and when the data collection system is connected, the available connections is exceeded thereby creating errors on the network.

What is the data collection system? How is it configured?

The reason I would go with forced 100FD if the switch supports it is
on as router to switch link both ends being gig interfaces it would run at 100 the fix was to force the router to gig and the switch was auto

I have some networks with a mix of 10 and 100 devices. Moving to a managed switch cleared up some issues. Upgrading all the CPUs wasn't an option. I think that may be coming, though, as we're going to have to tie in all locations to LAN.