Intermittent ethernet Communications

I am having an issue with an Ethernet network.

Its PLC 5, the Rack has a dedicated Ethernet side card which is dedicated for about 20 drives.

The network is set up for 100Mb/sec. There is 60 MSG instructions communicating to these drives.

They are wired trough 2 switches.

Basically sometimes the communication will be very slow, and I will get starter run faults because the feedback from the drive is not responding fast enough.

Does anyone know how to improve the network or some other work around?

Much Thanks

How are the msgs triggered? In some sort of organized fashion, or just at random? You might want to set up a cascading sequential routine to execute these msgs. What kind of switchs? Is the motor network shared with an office network?

Messgae instruction is as follows:

XIC - MG200:56/EN to the MSG instruction MG200:56

It is not integrated with an office network...its a dedicated network just from the drives

I hope i explained that well enough

First, I have to put in my usual disclaimer about this, because I have helped numerous customers get this working after they have chosen not to take my advice:

Using a PLC-5 to perform control over Ethernet is generally not recommended because it's not built to be an I/O scanner over EtherNet/IP. As you have seen, the performance and stability of the Ethernet traffic depends on the application programmer and on the other traffic on the Ethernet port of the PLC-5.

Just because Ethernet is considered "fast and cheap" does not make it the right choice for control networking with a PLC-5. If I had 20 drives to connect to a PLC-5 I would choose DeviceNet, RIO, or ControlNet before I would attempt to use EtherNet/IP.

Now, let's get to the Q&A.

What model of drives ?

What model of switches ?

What is the application ? How often do you need to make a start or stop or speed change happen ?

The logic you describe is a "self-triggering" Message, that will re-trigger itself as fast as possible and use up as much throughput as the port will give it. From a port capacity and buffer utilization standpoint, it's like the starting gun at the Running of the Bulls.

Ideally, I like to run one MSG at a time and then cascade them so that they run in sequence. Having one /DN enable the next MSG is one way, but I prefer to have each /DN bit (all of them in parallel) increment a counter, then have the counter's ACC value trigger each MSG.

This is not a lost cause, but it will require some careful work on your part to make this stable and successful.

Using a PLC-5 to perform control over Ethernet is generally not recommended because it's not built to be an I/O scanner over EtherNet/IP. As you have seen, the performance and stability of the Ethernet traffic depends on the application programmer and on the other traffic on the Ethernet port of the PLC-5.

I am using a 1785-ENET module which is dedicated to this “VFD” network. Im not sure if this changes the above statement or not.

Just because Ethernet is considered "fast and cheap" does not make it the right choice for control networking with a PLC-5. If I had 20 drives to connect to a PLC-5 I would choose DeviceNet, RIO, or ControlNet before I would attempt to use EtherNet/IP.

I totally agree

What model of drives ?

Powerflex 70s and Powerflex 40s with 20/22-com-e

What model of switches ?

I am unsure at this time, but will find out

What is the application ? How often do you need to make a start or stop or speed change happen ?

Starting and stopping will not occur often, however this is where the problem lies.
For a start fault, If the Drive running feedback isn’t received after 3 seconds of the Output command, this will cause an alarm and the drive to lose its start permissive.
Sometimes it takes longer then the 3 seconds to start,

Using the /DN would work except if you recieve a comm fault then it will halt all the messaging for all the drives?

Chado -

Couple of things, 1st, don't let the 100M network fool you. A PLC 5 can't process more then 10M Half duplex (I believe SLC 5/05 is the same). Any switch or PC connecting directly to a PLC5 should be configured to match. Avoid auto negotiation when directly connecting to a PLC5 (5/05 too) as that will bog the system down (the switch or pc will constantly try to negotiate speed with the PLC). If you have a managed switch you can set a single port on the switch to 10M/half which talks with the PLC5, another port could be set to auto-negotiate to talk with a PC that is setup as auto-negotiate as well.

Ken mentioned the messaging, and he is spot on. The PLC only has so much buffer memory to process messages. How many other messages exist for comms to other equipment? Doesn't matter if they are isolated networks, the PLC 5 buffer memory doesn't care.

Another item to watch, how much data is the HMI(s) requiring? This can also have adverse affects on the PLC5 comms as well.

As for the messages, you need to come up with logic that will "stagger" them for efficiency as Ken mentioned, but you also need logic to detect and correct any errors that occur, it has to be self-healing.

Thanks Guys for all your help

The 1785-ENET "Sidecar" has a Series C version with a RJ45 connector right on board, and this has a more modern 10/100 Mb/s Ethernet port that does support 100BaseT and auto-negotiation.

The 1785-ENET/C has better performance than its predecessor, but still has only about half the Ethernet traffic processing ability of the PLC-5E native port.

The 20-COMM-E and 22-COMM-E process the "PCCC Object" in similar ways, though the content of the data payload will be different. For example, on the 7-series the reference is a 15-bit value spanning Min Hz to Max Hz, while on the 4-series it's a frequency value in 0.1 Hz units.

The capabilities of the switch are not important for the usual reason when we use ControlLogix; MSG instructions don't do multicast like ControlLogix I/O traffic. But it would be very nice to have diagnostics to help tell the difference between logic issues and noise/interference issues.

You mentioned 60 MSG instructions for 20 drives, so that's three per drive.

Is one of those messages to set the Control Timeout value ? You can right away cut traffic by 1/3 by sending that message only if the Command/Reference message fails with a specific error code (I'd have to look it up) indicating that the Control Timeout is zero.

I have a little bit of single-drive logic for the SLC-5/05 and PF40 on the MrPLC.com site in the Download section. It might help show you how basic interlocking works, and it includes that error code.

For the PowerFlex 7 series drives, I recommend reading and writing the whole DataLink table so that you can get feedback data from the drive easily.

PowerFlex 4-series don't have DataLink tables, but you can make use of the Scattered Read function of the DPI Parameter Object to read up to 64 parameters in one message. It won't be fast but it will be efficient.

This one is for all the experts in here and I'm most likley wrong anyway. Eventhough the etheirnet moduels are smokin fast don't they still run infront of the native DF1 like the SLC'S? If so it's the old hurry up and wait. Massive amounts of data arive at the ethiernet module and then wait to funnel through the DF1 driver. Right, Wrong? Anybody?

jimfun71 said:

This one is for all the experts in here and I'm most likely wrong anyway. Even though the ethernet modules are smokin fast don't they still run in front of the native DF1 like the SLC'S? If so it's the old hurry up and wait. Massive amounts of data arrive at the ethernet module and then wait to funnel through the DF1 driver. Right, Wrong? Anybody?

Click to expand...

No, the sidecar does not depend on the serial port. I don't know the inner workings any more, perhaps Ken can help us here. The PLC5 has a great many more communication channels and buffers and is much faster at communications than the SLC. Each port is independent of the other and there are multiple processors to handle comms and ladder logic separately. There are some ways in which certain ports may be required to share buffers, but I don't remember the intricacies or where to find that information.

Chado613 said:

Using the /DN would work except if you recieve a comm fault then it will halt all the messaging for all the drives?

Click to expand...

Not necessarily. This is where Ken emphasizes careful construction of the logic. I will defer to him to clarify further the best way to do this. What I have done, is to set the message timeout fairly short, and then use the ER or DN bit to move on to the next message (CTU for example).

Paul

Hi Guys,

Not certain if this will help - in using an un-mananged switch I had terrible timing problems with a 'network' of PLC's and VSD's. Even the poor laptop kept dropping out with connection timing issues. Changing to a managed switch dramatically increased performance beyond belief.

Managed switches are very expensive compared with bog-standard un-mananged switches, which you might buy from any PC online reseller. For managed switches I used ones from Hirschmann.

If you've not resolved your issue any other way, get the Hirshmann (or other) Sales Rep. in with a model with enough ports to handle your configuration and they should be able to try in situ and se how it goes.

Good luck!