We have an application using GE Fanuc VersaMax Ethernet CPU’s, and need to know if it is reliable enough or recommended to exchange interlocks between different controllers, via Ethernet. The Ethernet network is built with fiber optics and Cisco switches.

Any comments (Pros & Cons) will be greatly appreciated.

Regards,
Alvaro Rodriguez

 

First you should define 'interlock'. critical ones like ESD are usually hardwired. Less critical ones you may prefer to be within one controller. A heartbeat mechanism on your ethernet should assure the quality of inter-controller signals. Keep in mind that the interlock should and will act upon bad ethernet communication

 

In a nut shell, all the interlocks should be hard wired. They have a following distinct advantages:

1. In case your communication fails in case of ethernet all the interlocks will operate to fail safe condition even though the plant is running normally.

2. By hard wiring, the entire communication does not stall hence the plant keeps on running. even there is a fault in hard wiring or any input module in such case, that section of the plant will be affected, whereas in communication the entire plant will trip as all the interlocks will be affeted...

3. U can consider redundancy in communication if hard wiring could not be possible

Mihir

 

We have been exchanging interlocks via Ethernet for years - no problems. The only thing I always recommend is to keep the control and IS networks
completely separate. If I can get away with it I source the switches as well as all the other hardware, design my own network and tell the IS guys to go away. They always try to load my network with rubbish.

Watch out for people who do not understand Ethernet. We are all at fault here. There is a consistent lack of understanding about what happens on the trunk. No one understands cable length limits et cetera too.

We have checked most networks and found low levels of utilisation. Timing checks have shown that the data arrives at a satisfactory time. Yes, of course, Ethernet is not real time at 10 Mbps.

We use both TCP and UDP. No problems with either type. The UDP seems to be a bit faster given that there is supposed to be less overhead.

Since people put HMIs on Ethernet and the systems cannot run without the HMIs, then I do not see the problem with inter-PLC communications on
Ethernet too.

There is always the safety angle, follow the code, follow your instincts and use yellow wire! We obviously do not put ultra-critical anything on
Ethernet. But then, it is rare that we have to machines with safety interlocks between them. Safety is normally for the machine itself. If
it does not want product or something, then that is rarely a safety concern with the stuff we programme for.

RA

 

Have had experience with GE 90-30s and Ethernet. Won't go there again for critical interlocks etc. Had to hard wire everything critical. The problem is if there is a lot of traffic on Ethernet, your interlocks won't work. I believe GE have Ethernet Global I/O now. If implemented properly, this will run under the main Ethernet layer and will not be affected by Ethernet traffic. Check with your local distributor. IF THE INTERLOCK IS CRITICAL, DEFINATELY HARD WIRE IT.

 

Please note that there are certain safety systems that have 'certified for safety' communications between controllers (to allow just this sort of application). However, they are NOT using plain jane ethernet!

 

Papers on this subject have been published by the IEEE. I believe some papers have also been published in the industry magazines like motion
control (isa.org), motion systems design (formerly PTD) and control engineering.

My hunch is that the current increase due to bearing electrical failure is too slight to notice and too difficult to distinguish from varying currents due to all other kinds of effects.

Also, if you really do have bearing electrical failures due to PWM/IGBT drives, why not address the root cause with your motor and drive supplier?
Any competent motor and drive supplier should have specialist familiar with this subject and remedies.