PLC-5 Ethernet running very slow!

Hey guys, just wanted to know if maybe something happened or if I need a new Ethernet sidecard. Lately rslogix 5 has been super slow.. It wasn't like this in the past when we first installed the card, and it seems as if it has been gradually getting slower and slower.. the ladder that spins is extremely slow.... all the other PLC's on the network seem fine and are very fast....

Little info about the system and network...

Fiber ran from front office to switch,
PLC 5/40 series E with Etherent Sidecard
i have 8 MSG going out through Ethernet from this PLC (maybe that could be the issue)

as for the program itself...its fin, scan time is very fast,
its more with making edits and such... it takes forever.

So you are using the sidecar for both software comms and explicit messaging?
Where are the MSG instruction routed to/from? A Logix system by any chance? Where is the messaging ladder logic implemented? PLC5 or Logix CPU?

The msg instructions are in the Plc-5 logic... They are sending messages to 3 different micrologix 1400 PLC's.. And yes the sidecars is hooked up to a switch, I connect to the machine network at my desk through a different router.

Could be a network issue.

PLC5s can only connect at 10M half (or full can't remember) but important thing to remember is they can't auto-negotiate. So if the port on the switch it is connected to is set to auto-negotiate this can case issues as it constantly tries to get an auto-negotiate response, this floods the the communications with garbage. So if you have not already, make sure the switch port is setup to match the speed/duplex of the PLC5.

Now-a-days, auto-negotiate is the norm, but you have to be aware of older equipment that can't respond to the request.

Paully's5.0 said:

Could be a network issue.

PLC5s can only connect at 10M half (or full can't remember) but important thing to remember is they can't auto-negotiate. So if the port on the switch it is connected to is set to auto-negotiate this can case issues as it constantly tries to get an auto-negotiate response, this floods the the communications with garbage. So if you have not already, make sure the switch port is setup to match the speed/duplex of the PLC5.

Now-a-days, auto-negotiate is the norm, but you have to be aware of older equipment that can't respond to the request.

Click to expand...

If it's an unmanaged switch and you can't set speed and duplex manually, a solution to the auto-negotiate problem is to place a HUB between the PLC and the switch. A hub is by nature a half-duplex device, and the switch will see it as such. Both the PLC and the switch will be happy. Make sure you document this very well, as some well-meaning person may come by and remove the "extra" equipment, thinking it's not necessary.

A hub is actually hard to find these days; everyone uses switches now since prices have come down and the benefits of full-duplex communication are so helpful. They can often be found on Ebay.


rpoet

The 1785-ENET PLC5 sidecar has an unique "feature" implemented probably due the the PLC5 system's age difference when compared to the Ethernet comms protocol.

The module will "Throttle Back" (or even disconnect!) when its onboard comms monitor detects "too much" network activity(16 or more frames are being detected within 10ms); when the activity falls bellow the above mentioned threshold the module will recommence its functionality; all along, the CPU performance has priority over any Ethernet communications.
This is also true for all Ethernet PLC5 models.
There is no way you could disable this "feature" and there is no way to detect when it "kicks in", unless an RSL5 Online application slows down to a crawl or becomes unresponsive.
Obviously, the ML1400s MSGing is necessary and going Online with the controller is a requirement; maybe selecting the lowest acceptable frequency for the MSG triggers, "cascading" the MSG instructions control code and trying to keep the RSL5K Online application session to a bare minimum- no more than one active Trend and the fewest possible simultaneous Edits.
I can't think of anything else unless you have the capability to go Online with the CPU using DH+; yes you will need a very expensive 1784-U2DHP comms adapter; or maybe you have some 1756-DHRIO Gateway somewhere on the DH+ network- you could configure the RSL5 running PC EtherNet/IP driver to connect to the DHRIO and the "hop" the comms onto the DH+; I remember having to choose the last configuration several times when encountered Ethernet PLC5 software communications issues.

Also, how many HMI/SCADA applications are hitting the PLC5? If you've added more stations this could be an issue too. Had a plant with 1 too many RSView32 stations, caused PLC5s to drop out of RSLinx. Ended up migrating to a central RSLinx Gateway for all the RSView32 stations to communicate to for PLC data.