|Lynn's Industrial Automation Protocol Tips|
|Home > Rockwell >|
The information on this web page is either Lynn's opinion or something Lynn agrees with. He has complete control over its contents. Nothing contained within this pages is approved by or represents the opinion of Digi International, The Modbus Organization, the Modbus-IDA Group, ODVA, or any other organization Lynn is associated with.
ODVA/CIP and Ethernet/IP Protocols
Answer: from the ODVA web site
You can download the specification for free. However, when you do so you 'click through' an agreement that says you will just study the document and not implement Ethernet/IP. To legally implement Ethernet/IP you need to subscribe to the specification and be assigned an ODVA Vendor Id. This id is used for several important things, so you really cannot fudge this with a fake id.
Question? Is Ethernet/IP proprietary to Rockwell?
Answer: No, there are 'issues', but it is NOT a Rockwell protocol.
Opponents (ie: people profiting from OTHER protocols) like to dismiss ODVA, Ethernet/IP, and CIP as something Rockwell really controls. Well, since early Ethernet/IP was implemented first on ControlLogix and then kind of after-the-fact documented as a "Here is how we think we did it" basis, there are fuzzy portions of the specification that don't work quite as advertised.
However, ODVA has a very nice series of bimonthly meetings called the "Ethernet/IP Implementor's Workshop" which is a place for the actual implementors (ie: programmers) to get together and do the following:
The workshops are very interesting and very helpful. I've been privileged to attend about half of them. Most are held in the Detroit or Cleveland area (yes, even in Winter), which makes it a bit expensive for some people - like me - to attend. Visit the from the ODVA web site to find out about the next Workshop.
Question? Does Ethernet/IP use UDP Broadcast?
Answer: Rarely. EIP mainly uses TCP unicast and UDP multicast.
This myth is based on the fact that cheap switches behave like hubs when faced with udp multicast, but multicast is NOT broadcast. Every multicast packet include a class D ip and an ethernet multicast MAC. This allows switches (which inherently include tables of enet MACs to filter upon) to very easily filter udp multicast.
EIP rarely uses "UDP Broadcast" - RSLinx uses it with the ListIdentity service to browse or RSWho a network but that's about it.
Both Cisco and Hirshmann sell switches that use IGMP-Snooping to forward/block multicast traffic address-by-address only to those devices which REQUEST to see it. This means the switch (yes, a layer 2 device) detects the IGMP message (yes, a layer 3 packet) as an indication of intent to send/receive multicast.
Plus EIP producer/consumer can also be set up in unicast mode if you only have 1 consumer who wants a set of data from producers. So do some reading (or ask AB) and use unicast (Class A-C IP) when you have only 1 consumer and use Multicast (Class D IP) when you have more than 1 consumer. If your application can run with only unicast, this whole issue goes away - or at least is delayed until you really need to use multicast.
Answer: You need to do a bit of extra work to optimize your data access.
Rumors exist that AB ControlLogix Ethernet cards create their own subnet and transfer a lot of extraneous data. I'm happy to say this is not true - there is no artificially intelligent conspiracy here! Your first pass at a ControlLogix system may result in a large amount of traffic and slow networks, but it can be fixed. Switches and/or VLAN will help a lot, but there is more you can do. The traffic on the network is there in the same manner as the fat on a person - you put it there by yourself either with a fork or your program structure.
The 'challenge' with ControlLogix and object-oriented programs is the 'easy way' to do things is the worst way measured in network load. It treats every data item as an object and potential message target. Thus while Modbus/TCP can move 125 words of data in 1 TCP message, the same design under ControlLogix *MIGHT* create 125 messages. No matter how fast your network is, 125 messages will be slower than 1.
There are many solutions - most direct is to manually repack your data into assemblies or groups that can be moved in fewer messages. There are tools to help with this - talk to someone familiar with Rockwell (like your local RA/AB App Engineer who most likely will be very keen to see your network situation get better so you buy more equipment!). Wonderware and other OPC vendors now sell special (ie: extra $$) versions of their tools for ControlLogix. These take into account that an HMI page has say 40 data objects and then handles both ends (PLC included) of the pack/unpack to move the data for this page in 1 message assembly instead of 40 messages.
|Feedback - Contact||Lynn's Industrial Automation Protocol Tips||Copyright 2004|