Allen-Bradley PLC-5 ethernet controller question

I know almost nothing about PLC's (I'm a network engineer), however, I have a question I'm hoping someone might be able to answer for me... as it has been placed in front of me as "my problem". We have an Allen-Bradley PLC-5 that runs a convayer system. The triggers for the PLC come from a database and they are connected via ethernet through a standard ethernet switch (Cisco Catalyst switch, Layer 3 switching). It is all local area network, there is no issues as far as latency from a WAN. The problem is the PLC-5's ethernet interface seems be dropping data packets and not re-transmitting them. Is this a common thing for them to do?? If so is there a way to fix this? Our convayer system vendor is blaming our network for the dropped packets, however, as hard as I try I can't seem to stop the device from dropping packets. I've gone through a few of the AUI to RJ45 tranceivers on the PLC itself, that seems to fix it for a little bit but then it's back to normal. I can't figure out why I have no problem with any other devices on the network except those that talk directly to the PLC. The entire network itself is less then 6 months old. It's gotten so bad that it's sometimes loosing large chunks of data (i.e. barcode information from the items on the convayer belt aren't being transmitted to the database). Any help would be greatly appreciated.

Thank you,

Bradley D. Walter

Help me understand which way data is going between the database and the PLC. Are database functions triggering writes to the PLC, or is the PLC using message instructions in it's logic program to write to the database (or both !). Do you know which direction the data transfer is failing ?

What kind of driver is the database using to interface to the PLC-5 ? If it's RSLinx, then you can expect some help from Rockwell. If it's "we wrote our own but we're certain it's A-B's problem", then maybe a little less help.

How can you tell that the ethernet interface is "dropping packets and not re-transmitting them"? Maybe you can expand on the symptoms and how you're measuring them.

See if you can also learn the firmware revision of the PLC-5 and any version information you can get from the software vendor.

You don't say, but we here need to know:
Is the ethernet onboard the PLC 5, or is it a module of its
own, mounted to the right side, in the rack/chassis?

If its a module to itself, you might have to update the
firmware in that module. (There was an update within the
last 2 years).

Also, check to make sure the rack/chassis is properly
grounded. There is a threaded stud on the far right side.

PLC5

I take it that you are using the PLC5E (ethernet PLC) and not a
side card module or an ENI module based system.
If you use RSLinx, which again I presume you are, you can monitor
the Ethernet packets to see if you are losing any.
I have had a situation with 1756-ENET module where if I hooked it
up via one router it worked OK and when I used another it went through hick-ups. To this day I don't know what was wrong other than
that there was a timeout.
Make sure that your routing uses smart switching and not just hubs.
PLC5 uses TCP/IP for message delivery. I don't know what the TTL
is set at. You may want to sniff it out, socket port #44818.
The other thing you can do is to prove that in fact the PLC5 outputs
the data as it should via the Ethernet. Provide local E-net connection
first, disconnect it from the backbone.
Last thing, 80% of all problems on networks are caused by a poor
connection, runs that are too long or too noisy, in other words
related to the physical medium.
Good luck.

First off, thank you all very much for your suggestions, I'm amazed at how quickly you got back to me. Now, to answer some of your questions to help you help me.

>Help me understand which way data is going between the database and the PLC. Do you know which direction the data transfer is failing ?

Data is going in both directions, the PLC reads and writes data to the database. And from what we can tell the majority of the dropped packets are when the PLC logic writes information to the database, however, less frequently we sometimes have a small problem with database reads on the PLC.

>What kind of driver is the database using to interface to the PLC-5?

Homebrew by our vendor, and they're saying "Until you clean up your network, we refuse to look at our software as the potential source for the problem" (basically turning this into a support ****ing match). I'd hopefully like to try everyone's suggestions so I can place it back in their laps.

>How can you tell that the ethernet interface is "dropping packets and not re-transmitting them"?

I use Network Solutions "Sniffer" software to sniff out dropped/runt packets, connection errors, transport errors, etc.


>Is the ethernet onboard the PLC 5, or is it a module of its own, mounted to the right side, in the rack/chassis?

It's the onboard AUI connector with an AUI to 10Bt tranceiver (which has been replaced multiple times).

>Also, check to make sure the rack/chassis is properly grounded.There is a threaded stud on the far right side.

Engineers are looking at that as we speak, I will update you when I hear from them. I asked them to check all grounding.

>Make sure that your routing uses smart switching and not just hubs.
>Last thing, 80% of all problems on networks are caused by a poor
connection, runs that are too long or too noisy, in other words
related to the physical medium.

The building and all the equipment is less the 6 months old. Our network core is two Cisco Catalyst 6509's connected to multiple Cisco Catalyst 2948xl's via redundant gigabit fiber. The entire network was certified by Krone (our cable vendor) for Catagory 6 less then 6 months ago. All of the equipment in question is isolated on a Layer 3 switched VLan. This is why I am having a hard time believeing this is a network issue. But the vendor is saying dropped packets are indicative of a poor network (again, the support ****ing match).

I am currently looking into some of the solutions you have provided me with. My next step is to sniff out the network and send the data to one of our head network engineers to pick apart, he might see something I don't. I do appreciate all your suggestions as I think the vendor is "picking on me" because of my limited to non-existant PLC knowledge, and ever little bit of information I get from you and try is one more thing I can say "I checked that..." to.

As I find more information I will post in here. Once again, thank you for all your help.

Bradley D. Walter

Hey Brad,

I may be making this way too basic, but gotta ask the obvious, is the signal 'dropping'? ie, is the length too long for the signal to contain it's info?

maybe a simple repeater will help....

Hoot

Here's a thought. Set up a small local network right at the control cabinet housing the PLC with just a hub, the PLC in question and a computer with the database.That should eliminate the question of distance, noise, etc. I'm just guessing here without knowing how everything is being handled.
Another area to look is how the message rungs are set up in the PLC program. I had a problem with a SLC500 PLC a while back that had too many messages in "Que" waiting to be sent. PLC 5's might not have this kind of problem. If you can post the message rungs maybe someone can spot what needs to be fixed.
I'm wondering also if this problem just started recently or if it has been going on since the conveyor system was started up. Recent problems point toward hardware.

The PLC programmers can give you some help, too. When a PLC-5 sends a message out from one of it's network ports, there is a corresponding "MSG" instruction in the ladder logic program of the controller. If a message is not acknowledged by the device to which it is sent, or if an error occurs in the data link level (like if the network is unplugged !), or if the receiving device cannot understand the message and replies with an error code, the data file associated with the MSG instruction stores an error code.

Point your PLC programmer to page 16-22 of the PLC-5 Instruction Set Reference manual.

Publication 1785-6.1

This contains the error code table for PLC-5 message instructions. Maybe this will help correlate with information you get from your Sniffer software to identify the reason for these communication errors.

The TCP port you want to watch is probably Port 2222. This is the Port used by "classic" PLC-5 Ethernet communications, not the newer ControlLogix-based EtherNet/IP on TCP and UDP port 44818.

I am very curious about how Sniffer works and what it shows you. Can you tell us about what you're seeing with that software ?