PLC ( Machine) Downtime due to Communication Problem.Looking for Redundancy Options

[Rob S.]

Good Morning ,

Yesterday we had some downtime due to some communication problems with remote Ethernet I/O. I am still a fan of hardwiring everything , but in a world of communication remote I/O does work. I would like to switch over to AB ControlLogix and focus on redundancy . I would remotely use Flex I/O , I was looking at 1794-AENTR , instead of the 1794-AENT . It looks like the 1794-AENTR has 2 Ethernet ports.

I plan on using a 1756-ENBT in the rack. Is there any other areas I need to consider redundancy ?

Thanks in advance,

 

[rdrast]

I have to ask first, what the original problem was?
Redundancy is nice and all, but it is complicated, expensive, and can cause more problems then you have now.

 

[Psymon]

Instead of the ENBT look at the EN2TR. It is more expensive, but it will allow you to setup a ring topology with the AENTR cards. At least I assume that's what you're trying to accomplish.

 

[JesperMP]

Redundancy for the communication bit alone may not be so complicated.
It is possible to create an Ethernet device-level ring (DLR) with automatic switchover in case of cable or node failure.
For anything that is somewhat complicated and various parts being dependant on each other, it is a very good idea to have such a redundant "backbone". One failure will not bring the whole thing down.

I dont know about Rockwell and Ethernet/IP, but for some systems the functionality only requires a few settings to be setup.
For AB, I like Point much better than Flex. There is also a dual-port Ethernet/IP adapter for Point that supports DLR.

 

[Rob S.]

It was a bad switch yesterday. Just concerned , like for instance a Ethernet cable was bad , If I had a 1794-AENTR it seems like the 2nd EtherNet cable would take over. What do
you feel about relying on networking between panels vs. having individual PLCs or hardwiring between panels ?

 

[Psymon]

Look at this

This shows you how a ring is setup. So if one cable on the ring is disconnected, the other side of the ring will take over allowing operation to continue as normal.

 

[JesperMP]

What do you feel about relying on networking between panels vs. having individual PLCs or hardwiring between panels ?

We are going ethernet for everything. PLCs, IO, Drives, HMIs, and also interfacing between systems. We are not going back. There has been a sharp drop in cost and complexity because of fewer cables, terminals, IO module setc, and an increase in flexibility. If you need to change something you can do it by programming, and that even via a remote connection.

The only times that we consider old-fashioned potentialfree contacts and 4-20 mA, is when the partner is primitive and has no clue about modern control systems. In that case it may be better to do a few hardwared signals. But how do we do it ? We stick a remote IO block in the partners control panel and connect to that via Ethernet. The partner then hooks up his oldfashioned control system to the remote IO block.

 

[V0N_hydro]

I am not a huge fan of ethernet rings. I prefer redundant star topology. In the linked PDF Psymon posted for the equipment on the right hand side to talk to the left hand side it has to hop through three other devices. While there are two paths with 3x as many ethernet cables, terminations, and devices the odds of a failure are 3x as high. Even if the equipment in the plant is physically located so that a ring is naturally the least amount of cabling, and even if the ring could use cat5 while redundant star would have to use fibre I would still push for redundant star despite the cost difference.

If the plant is large enough that there are multiple panels with PLCs in each one they probably can afford to 10x the cost in communications cabling (which is small to begin with) to get the most robust communications bus (redundant star) for the plant control system. These ethernet cables are replacing 10x more cables for analog and discrete signals.

I like redundant star because there is no single point of failure, and the minimal number of hops between devices which provides the minimal amount of jitter. Each port in the redundant star would have many fewer packets per second so possibly latency is also reduced. Less bandwidth in each port is used as well but bandwidth has never been an issue for me.

If I can't deploy redundant star I would simply go for star topology over a ring. A ring is so much more complexity for so little gain, in a plant environment. SONET loops out in cities still make sense IMO.

All of the communications failures I have dealt with have been caused by fibre. When the whole cable is broken it doesn't matter what your topology is. Only in one case have we found a fibre pair stopped working and the switch automatically changed to the redundant pair.

For the record despite remote IO to each panel in the plant, I still end up with half a dozen discrete signals and a few analogs hard wired to the remote panels, for safety or to maintain the modularity or independence of the PLCs and equipment in failure scenarios.

 

[Psymon]

In the redundant star the single point of failure would be an Ethernet switch, which is what he had go bad. The fact that it needs to travel through 3 other devices is negligible at best. I doubt that it would add more than a few ms to the total ping time. However, if he needs to please the powers that be by adding redundancy, then pulling another cable to a switch would probably be the easiest placebo.

 

[V0N_hydro]

I was thinking of each device having two links, one to switch A and one to switch B. switch A and B are also connected directly to eachother.

Maybe this is called dual star.
https://docs.oracle.com/cd/E19217-01/820-7346/guide.html

But there are two switches, so protected against failure of one.

In my experience the panels in the middle of an ethernet ring have had measurably worse ethernet performance.

I measure performance as the time delay between updates from modbus or CIP by always including the real time clock in the data transmitted. My panels in the middle of the ring have longer delays and more often.

Maybe it is an artifact of the protocol (mostly modbus) or the make/model of the switch, and not the ring topology.