Commercial Ethernet and EtherNet/IP

[MarkTTU]

Just at a guess, if you replace the commercial grade switches with industrial grade things will get much better. Wether or not Ethernet makes sense would be a case by case thing (in my opinion).

For example, we're an OEM and build machines for cotton gins. In previous modles the installation of our equipment required some 20 wires (some 120VAC, some 4-20mA, some thermocouple) and 3 conduits run between the actual machine(s) and the main control console. Using ethernet we've got that down to a single shielded cat5 in its own metal conduit. Its easier to install and trouble-shoot.

As an example, if a gin has 4 heaters located near each other (typically in a fan room) we can put an industrial network switch in one cabinet, run cat5 between all 4 heaters and then run a single cat5 up to the main control console from that switch.

The one thing I haven't been willing to do yet is mesh our network with the network of another vendor. I don't trust anyone else to have their ethernet communications timed in such a way that there are reasonably long gaps (10-50ms) between packets for other devices to attempt to transmit.

 

[JesperMP]

All the products carry the CE mark for installation in the European Union.

Warning !
The "CE" stamp on office or home equipment does NOT mean that it is approved for use in an industrial environment.

The requirements for CE conformance with respect to EMC is divided into "industrial" and "home/office".
Industrial equipment is allowed to radiate a higher level of electrical noise, but must also be able to withstand a higher level of electrical noise.

 

[Jiri Toman]

The word Ethernet has become synonymous with the TCP/IP protocol stack

I stand corrected on this one. Ethernet actually encompasses
only the physical layer and the data link layer (layer 1).

Oh Sleepy, it is stil non-deterministic. I guess you expected that.

The fact that Ethernet is non-deterministic is blown out of proportions and the statement is overused.
Studies have shown that as the collisions increase the time lag does not increase in an exponential manner, instead it increases in a linear fashion. On a 10M network loaded appr 10% you will see delays of appr 2 ms, if it's loaded to 90% the dealys will be about 30ms.
Even at 30 ms this is fast enough for many processes.
If that's not fast enough crank the speed up to 100M, isolate
your network with a switch to insure light loading and you don't have to worry about determinism.

One more point concerning the cost. About 60% of costs of a network
are associated with cabling. Also most problems on a network are associated with cable connections.
If you can provide one common physical media for all comm. protocols then we have made a huge step fwd.

 

[Gerry]

Multicast

... major plant involving in excess of 100 nodes of Ethernet based control. ...The system has been set up with one single layer of Ethernet so that all the nodes are available on a single subnet. It has all been set up by competent networking professionals.

The PLC has plenty of Ethernet cards each dedicated to various data channels. From the automation hardware perspective everything has been done right. BUT... all the cabling is commercial grade Cat5 STP and the switches are all commercial grade. It sucks. Far too many network errors are being reported by the Ethernet interfaces.

My observations:

1. The I/O data should have been done on a true Industrial network.

...

So far, nobody has mentioned the "elephant in the living room" - multicasting .
Since I know Philip works almost exclusively with A-B, I'll assume the system mentioned is CLX-based. The remote ethernet I/O is all multicasting its input information. Standard switches, whether "industrial" or "commercial" grade, handle multicast packets like the simplest hub - they are repeated out every port of the switch. To restrict the multicast traffic to the devices interested in receiving it, the switches need to be 'smart' and support a feature known as IGMP snooping. But it doesn't end there. There has to be a device on the network to issue IGMP queries to enable the smart switches to configure their IGMP tables. This function is built in to some smart switches (known as level 3), others (level 2) require a router to issue the queries.

As for the industrial-commercial grade argument, I've been very skeptical ever since the experience of running an 'industrialised' IBM XT alongside a Taiwanese clone 'commmercial' unit in a factory office. Guess which one failed - several times!

 

[RMA]

The fact that Ethernet is non-deterministic is blown out of proportions and the statement is overused.

Another point that nobody seems to have mentioned is that at least in Step7 you can set up your Ethernet connections to be either half- or full-duplex. This means that for internal project communication you can run multiple point to point Ethernet connections using relatively cheaply available commercial cabling etc. and still have collisionless communication which utilises the full potential of 100Mbit/s circuits. For all practical purposes in a normal PLC environment, that is real time!

 

[Alan Case]

Gerry has bought up the biggest problem with EthernetIP. Multicasting.
It is not a problem if the system is designed correctly with the CORRECT switches. (ie supporting IGMP snooping)
I have found if it has been designed by a network engineer who is experienced in an office environment then it is usually wrong. There is a lot of info out there on multicasting in an AB system. The last advice I saw from Rockwell was not to produce/consume tags between PLCs over the ethernet network but to use a controlnet for this purpose. Phillip, PM me if you want some of the info. Regards Alan Case

 

[PhilipW]

Just to clarify...yes the system has been setup with Layer 2 and 3 switches. The IGMP issue has been well sorted right from the start.

The problems we are seeing are things like Flex I/O 1794-ENET and SMCFlex Ethernet interfaces giving "network errors" more often than I would like.

My main beef is the use of STP cable without due consideration of the quality of the RF grounding, especially when using switches not qualified in an industrial environment.

Disturbing however to see that Gerry and others I have spoken to have found the commercial grade switches to be more reliable than the more expensive "industrial rated" ones. Anyone else want to add their comments here?

And the subject of connectors hasn't been mentioned either..any other thoughts? These RJ45 clipins perform remarkably well for how simple and cheap they are, but is it the right way for the controls industry to go?

My other point is that in my experience ControlNet would have been more dependable, faster and had lot lower total cost of install. (Decent RG6U cable, balun drop lines and terminators appeal to me.) So why use Ethernet at the IO level? No net gain as far as I can see.

 

[BobB]

Phillip W, WE AGREE.

I have been quite vocal for a long time about my dislike of Ethernet for industrial networks. A am not surprised that I now find quite a few of the members are running into problems with Ethernet for one reason or another.

Alan Case highlighted a problem that I had not run into and it is also interesting that AB recommend use of a different network for peer to peer PLC communications. My first peer to peer Ethernet project convinced me that this is the way to go.

I am just completing commissioning a job where we have replaced some old Omron PLCs with the latest CJ1 series. I have use Controller Link, as is my custom. This is the first time I have set up a Controller Link network with Omron CX-Programmer V5. I just selected automatic allocation and specified my starting word for network digital a data memory (register) words and specified 10 words for each PLC for digital words and 50 words for each PLC for registers. Also specified the starting word for network status bits. Connected to each PLC in turn over the network using Omron Toolbus connection and downloaded the network set up to each PLC. ALL OVER!!!

Just started the network communications by pressing the appropriate button in the software and specified that each node should automatically start on power up and it just works.

There are 8 bits automatically allocated to each PLC for status showng whether the PLC is OK, running the program or stopped etc etc. I use these for error checking and alarming if something is off line. The bits allocated to each PLC are exactly the same through the network. Just do your symbols and comments once and copy and paste them from PLC program to PLC program. Really easy.

The scan time for the network is 9.6 milliseconds for automatic transfer of 40 digital words and 200 registers (4 PLCs). No collisions and totally reliable. This scan time includes all in built error checking and complete exchange of data.

The network was set up and running in a matter of only 5 minutes.

I believe that in time Ethernet will become a reliable PLC peer to peer network but also believe that for it to be effective proprietory solutions will be the way the PLC manufacturers will take us. It will probably be along the lines of a prorietary application layer running on TCP/IP under Ethernet. This is already in place from at least one manufacturer and is mooted by others. I am inclined to believe that this is also how Modbus TCP works. I am waiting to see my Schneider rep to confirm this.

The only real problem I can see with this approach is bandwidth, at this stage. If there are others out there with experience here please post and let us know.

A question for Jiri, can you explain to me the following situation?
4 x GE-Fanuc 90-30 PLCs with Ethernet communications between them - FIX Scada system over the top. Ethernet network running at 10 meg - all that was available. Closed network with no switches or hubs, as specified by the client. 5 words of data transfer for each PLC issued on the basis of a read command from each PLC - request every 2 seconds only. FIX Dynamics SCADA only has 80 tags - very underused. PLCs reporting "full mailbox" on a regular basis. Increasing and decreasing the read request time did not appear to make much difference to the update time. I must admit that I do not usually use GE-Fanuc and maybe there was something in their system that was causing the slow update times but their distributor was unable to enlighten me on a solution to the problem. Perhaps with other vendors solutions on Ethernet the problem would not have arisen.

Updates from PLC to PLC were actually taking far longer than communications from one Horner Modbus RTU card running on RS485 at 19,200 baud to several dvevices in a loop. Much larger quantity of data being requested.

I continue to use a different network for PLC peer to peer these days, as recommended by AB, but one day will probably have to go back to using Ethernet due to specification and may find a completely different set of results.

By the way, the proprietary solution I normally use is way cheaper than Ethernet. This is often very important as we usually deal with builders. To them the cheapest quote wins the job. It is very competetive. I lost a job just recently to a competitor because my solution was $500 dearer than his in a $40,000 job. It can be really tough out there some times.