I would like to discover all Ethernet/IP enabled devices from the current network. By using Java, how can I check this? Please provide me some examples and articles to do this.
As far as I know, the EthernetIP specification published by the ODVA defines the port used. With this information scanning the network using Java is very easy.
No, I have no code.
A connection originator may use the "ListIdentity" (command code 0x63) command to locate and identify potential targets. This command shall be sent as a broadcast message using UDP (0xAF12) and does not require that a session be established. You may need to buy the EtherNet/IP specification form ODVA.
ODVA or Open DeviceNet Vendors Association should change their name and drop the Open. I can't believe you have to pay for the EtherNet/IP Specification. What's going to happen to Modbus TCP once ODVA takes over? I remember a few years back the EtherNet/IP Specification was a free download.
It's not just that you have to pay for the spec. It's that the specs are available only to "qualified vendors". In other words, Rockwell's marketting department decides case by case whether it is to their advantage for you to be able to talk to their equipment. It is a very closed, very proprietary protocol just like Profinet.
I haven't heard anything about ODVA "taking over" Modbus. What they have done is "published" a (secret) spec to allow Modbus messages to be tunnelled over EtherNet/IP. This isn't uncommon. You can tunnel CAN messages over ModbusTCP, and various protocols (I don't know which) over Profinet.
At present, ModbusTCP is pretty much the only commonly used open Ethernet protocol available in industry.
>It's that the specs are available only "qualified vendors".
No. Anyone can purchase a copy of the spec.
>In other words, Rockwell's marketing
>department decides case by case whether
>it is to their advantage for you to be
>able to talk to their equipment.
No. You can write software to communicate with an AB processor using Ethernet/IP without any approval from AB.
> It is a very closed, very proprietary protocol.
No. You can purchase a copy of the spec, it is published.
>What they have done is "published" a (secret) >spec to allow Modbus messages to be tunneled over EtherNet/IP.
No. Ethernet/IP is not MODBUS TCP/IP and the two protocols have nothing in common other than TCP/IP.
Ethernet/IP is not the only spec that must be purchased. (e.g. BacNet)
And I do not work for AB or ODVA.
In reply to Mark: You said: "No. Anyone can purchase a copy of the spec." And also: "No. You can write software to communicate with an AB processor using Ethernet/IP without any approval from AB."
Reply: That's not what the ODVA says. To use the specs, they state that you must sign an 8 page (5000 word) contract, submit it to ODVA, be approved by them (signed by their Executive Director), and receive a vendor ID code. They don't have to accept you if they don't want to. As a reference, see step 4 of the ordering procedure "Do you intend to make products or solutions using the Specifications ordered? If yes, you must obtain the relevant Vendor ID". They also state: "The right to use the Specifications to design, manufacture, or sell products incorporating all or any part of the Specifications is subject to the terms and conditions of the Terms of Usage Agreement. If you have not previously submitted a Terms of Usage Agreement please fax to (...) a signed and completed copy of the Terms of Usage Agreement."
This means that your rights to use the specifications are limited to what is stated in the contract.
"This Terms of Usage Agreement, including all Exhibits and Schedules ("Agreement"), (...) constitutes a binding contract between such Entity as a "Licensed Vendor" and ODVA."
You must have a legal contract with them, not just "order specs".
"1.1 Licensed Vendor agrees to: 1.1.1 Follow the design specifications set forth in the Licensed Technology (...) and to refrain from modifying, reproducing, or disseminating the Licensed Technology without prior written consent of ODVA."
You can't base a derivative work on the specifications. You are limited to whatever they decide to allow you to do. You also must have their written permission to do anything with any work you base on the specs.
"1.1.3 Obtain and maintain its specification subscription(s) to the Licensed Technology;"
You have to maintain your subscription on a continuing basis (I will get back to this point later).
"1.1.4 Obtain and maintain Declarations of Conformity from ODVA for its Compliant Products as prescribed by ODVA in its published policies;"
You have to get your work approved by them. You have to pay for this, by the way.
Under their "termination clauses" (section 4), the "ODVA may terminate this Agreement with respect to any or all Licensed Technology". This means that your rights to use the specification may be terminated by the OVDA.
Among the reasons for termination are: "(b) failure to pay any fees due to ODVA". So it appears that if you let your subscription lapse, your rights to use the specification terminate.
"4.3 Upon termination of this Agreement: (a) all rights and licenses granted to the Licensed Vendor hereunder for the Licensed Technology shall terminate (...) including but not limited to making, having made, using, reproducing, marketing, importing, offering to sell, selling, leasing, and otherwise distributing and disposing of, Compliant Products". So once your contract is terminated, you can't even *use* your software anymore.
This is a legal contract and it includes a jurisdiction clause: "This agreement shall be construed and controlled by the laws of the State of Michigan". This means I would have to agree that any dispute would be governed by the laws of a foreign country and go through all the expense and difficulties related to that. It also requires "final and binding arbitration" by a commercial arbitration panel. Commercial arbitration panels are notorious for favouring large businesses over individuals or small businesses. If I lose, then I have to agree to pay ODVA's legal costs. Furthermore, note that since this is a contract, this falls under contract law, which will interpret the contract pretty much as written. In other words, don't sign this agreement without the advice of a lawyer.
Given the above, I don't see how Ethernet/IP can be considered by any reasonable person as being anything other than a closed, proprietary protocol. Many proprietary vendors have "partner licensing programs" for their proprietary protocols or specifications, and the ODVA doesn't seem any different than most in this regards.
On another point and with regards to my statement about: "What they have done is "published" a (secret) spec to allow Modbus messages to be tunneled over EtherNet/IP."
You replied: "No. Ethernet/IP is not MODBUS TCP/IP and the two protocols have nothing in common other than TCP/IP."
To this I have two replies. First, I didn't say that "Ethernet/IP is MODBUS TCP/IP". I said that they have a new spec which allows Modbus to be tunnelled over Ethernet/IP (see above). Secondly, this seems to be covered under "Volume Seven: Integration of Modbus Devices into the CIP Architecture". Use Google to have a look for the press releases from late last year regarding this for more details.
When I made my previous reply, it wasn't just some remark that I made off the top of my head. I actually did some research into it first. I would really *like* to support Ethernet/IP in some software that I am presently writing. It just doesn't look feasible though under the terms that the ODVA has set. If ODVA would like to be genuinely open (as opposed to being "PR open"), then I would really like to hear about it.
I read the same documents.
I am always open to correction.
I think perhaps there is confusion between manufacturing a device that supports Ethernet/IP and writing a program to poll a ControlLogix processor to fill a spreadsheet or log to disk.
I count many companies of software programs that communicate with ControlLogix processors using Ethernet/IP and they are not listed on the ODVA web site as vendors and do not have vendor IDs.
Using AB's published documents you can write a program to communicate to a ControlLogix processor via Ethernet/IP.
In reply to Mark: ODVA asks: "Do you intend to make products or solutions using the Specifications ordered?" Software is a "product" or "solution" under normal legal definitions. There isn't any contract language that I noticed that explicitly exempts software. In fact, *any* "product" or "solution" that implements the protocol would necessarily contain software.
If we look under the "definitions" section, they describe "compliant products" as being "hardware, software, or combinations thereof... that implement and conform with all relevant required portions of the Licensed Technology". It is apparent from this that they consider something that is pure software to be a "product".
As for whether they are actually enforcing their contract at the moment is irrelevant. They may choose to do so in future on a selective basis, and I can't afford to fight them even if I was right. It might happen that it is to their strategic advantage to turn a blind eye to unlicensed implementations for the moment. It is better therefore to just avoid them and to use a safer protocol that doesn't present the same sort of risks and uncertainty.
Companies and organisations that want to openly license their protocols, specifications, software, etc. for widespread implementation will always make the terms very clear. Ambiguity does not normally work in your favour.
In reply to Curt Wuollet: In the Automation business, there seems to be an inverse relationship between the number of times a vendor uses the word "open" in their name and in their literature, and how open they actually are.
It appears that vendors know that their customers really want them to be open. It also appears that these same vendors think that their customers have the attention span of a goldfish, and that if the vendor says the word "open" often enough the customers will lose interest in "open" and wander off to watch the lovely blinking lights on the I/O modules.
To give you an idea of what we are talking about, let's look some more at the ODVA "Terms of Usage Agreement". If I pull the text into an editor, it tells me that the contract has 5061 words.
Let's compare that to a Modbus/TCP server (slave) that I recently finished writing. This server implements the most commonly used functions and stores the data in a memory table while handling multiple incoming client connections. If I strip out all of the comments, I get 4254 words. 2661 words of that are look-up tables, so that's really only 1593 words of actual code.
In other words, the source code for an entire working Modbus/TCP server is less than a third of the size of the contract that ODVA wants me to sign just to *look at* their specs. I think I will let those numbers speak for themselves.
So, some vendors like to talk about being "open". When are they going to actually translate that talk into action though?
P.S. My Mobus/TCP server will be released under GPL fairly soon. It will be Free Software, with no vendor ID codes required. I would like to add Ethernet/IP support to it, but that doesn't seem to be in the cards at this time for reasons that should be obvious by now.
Yes, they are Open by Declaration. This is really quite cost effective for them as it involves merely adding the word open to every other line in their next advertising spread, with no messy policy changes or licensing changes. And it works!
We even see people describing Microsoft products as Open here. It's a new hallmark in propaganda effectiveness, but an old tactic called "The Big Lie". I suppose there's no reason not to keep using it as long as it works.
I have written software that communicates via Ethernet/IP to ControlLogix. I did not use documents from AB.
I would like to see the documents. Do you have a link? Or are they for sale?
1. Communicating with RA Products Using EtherNet/IP Explicit Messaging (Rev. 1.2) 7-Jun-01
2. Establishing I/O Communications with RA ControlLogix Systems on EtherNet/IP (Rev 1.0) March 10, 2003
3. Publication 1756-RM005A-EN-E - March 2000
4. Type Encoding of Logix Structures
in CIP Data Table R/W
( 3-Nov-06, Rev. 1.2)
I found all of these on the AB/Rockwell website.
In reply to Mark: I don't want to sound like a broken record, but this is something that interests me a great deal so I checked out those documents. I found the following:
The first two documents:
1) "Communicating with RA Products Using EtherNet/IP Explicit Messaging".
2) "Establishing I/O Communications with RA ControlLogix Systems on EtherNet/IP"
These are supplementary documents, and refer you to the actual specifications if you want to know how the protocol itself works. E.g. On page 5 of the first document it states: "To understand EtherNet/IP and the CIP concepts, developers should obtain the EtherNet/IP Specification".
On page 6 it states: "5. WHERE IS THE EIP PROTOCOL DOCUMENTED? The EIP protocol is now documented in the EtherNet/IP Specification which can be downloaded for free at the EtherNet/IP website ..."
The web site they reference however appears to have been abandoned and been taken over by a spammer. That seems to just leave ODVA as a source for the specs.
They are also very clear that obtaining the documents does not give you the right to actually use them. For example:
"Must obtain the EtherNet/IP Specification (Ref#10). The spec can be downloaded (...) for evaluation. To build a product for sale requires a license. (...)"
"Must obtain a License and Vendor ID from CI or ODVA. A license is required to use the technology in a product. (...)"
"Must pass the EIP Conformance Test and submit an EtherNet/IP Statement of Compliance"
The next two documents are more supplementary information on the data structures in AB PLCs with respect accessing them remotely. They do not however detail the actual protocols used.
3) Logix5000 Data Access
4) Type Encoding of Logix Structures in CIP Data Table R/W
So, while it appears that while these documents are probably useful, they do not themselves describe the protocols in question.
It also appears that these documents have cleared up some questions about the status of the protocol documents. It appears that at one time you could indeed download the actual specification documents at no charge. However, these were "for evaluation purposes only". You were not allowed to actually use them to produce anything without purchasing a license and a vendor ID, undergoing conformance tests, etc.
So the only thing that appears to have changed is they are now making it more difficult and expensive to actually get your hands on the specification documents. As to why they might not have been very rigorous in enforcing their licencing terms in the past, it is possible that this was deliberate policy to try to get their protocol used more widely used while still keeping their options open to tighten up enforcement later. There doesn't appear to be anything preventing them from going around and demanding royalties from all the unlicensed users (and their customers), if they decide that is what they want to do.
If anyone has any other ideas, I would very much like to hear them.
> If anyone has any other ideas, I would very much like to hear them. <
ODVA oversees product compliance with the CIP Network specifications using the following processes:
Each vendor is required to sign a Terms of Usage Agreement for each ODVA technology for which they intend to make, have made, sell or have sold products. In signing this agreement, the vendor agrees to comply with the network technology specification and meet a set of user responsibilities.
ODVA's conformance testing provides general industry with the vendor-independent assurance that products built to the CIP Network specifications comply with those specifications.
In reply to Bill Code: I had a look through the AB web site. I can find references to documents and pages that are no longer there, but anything directly relating to Ethernet/IP protocol details seems to have been systematically removed. I can also find references to freely accessable download pages at ODVA which also no longer exist.
It appears that the marketing strategy regarding access to documentation has changed. It is unfortunate, but it is their proprietary protocol so they can do things like that any time they wish. If anyone has any other suggestions or sources of information, I would like to hear about them.
The reason you see many products talking to Rockwell controllers via Ethernet/IP even though those products and companies are not ODVA members is this:
Those guys bought ready made EIP stacks from someone else. The producer of the stack is no doubt a member of ODVA.
I used to work for one, and that's how we generally handled it.
No wonder it cost so much to get the spec. ODVA has to pay all those lawyers. Modbus TCP is so successively and widely used because it is truly open. Ethernet/IP wants to become pseudo open. I guess Ethernet/IP and ODAV were so brilliant that they have to use someone else's technology to maintain in the market. When will the country clubs of the automation world finally loosen the choke hold on technology?
I hope Modbus TCP keeps kicking Ethernet/IP's butt from here and on into the future.
In reply to David Wisti: Ethercat seems to be making an effort at being open as well. I haven't read the terms in detail, but it looked good at a brief glance. They seemed to say the specs are open, but they control the use of their logo and trademarks (which seems reasonable). I would have to look at it more detail though before stating a definite opinion.
As far as implementing Ethercat goes though, I think it needs an RTOS because of timing limitations. If there is a non-real time version of the protocol, that might be interesting enough to look into. They are pretty narrowly focused on I/O though, so they aren't exactly a direct replacement for Modbus.
Modbus has a number of big advantages, including being very simple and not too fussy about the media that it travels over. That means that it can continue to adapt to and take advantage of new technology without having to constantly re-invent the wheel like other protocols have had to do. That's one of the advantages of sticking to genuine standards.
Modbus/TCP seems to be everyones first or second choice or option but Modbus/TCP's only advantage over Ethernet/IP is simplicity but this comes at a great cost.
1. Modbus/TCP has a very resistricted addressing space. 64K words is not enough for many applications.
2. Modbus/TCP doesn't have data types. Floats, DWORDS, and DINTS are transfered as words. Ethernet/IP supports data types.
3. There should be a Modbus/UDP as well as a Modbus/TCP. TCP is not the best way to send I/O. UDP is much better. Ethernet/IP got this right. TCP should never be used for I/O. If something goes wrong the TCP stack will retry trying to send or receive old data. UDP will just send or receive new data the next time a transfer is made. This has been covered many times and at many forums.
4. Modbus/TCP packets/messages are very small compared to Ethernet/IP messages. One can send a lot of data with just one MSG block. We have transfer 32767 words with one MSG block. MSTR blocks are limited to just 100-125 words. This means that a PLC program must download 1000 words in many transfers. Many programmers are not capable of writing code that does that.
We have 3 Ethernet/IP certified products. They can communicate using any one of many Ethernet application layers including Ethernet/IP and Modbus/TCP. We have a pretty good idea of how our products being used and what protocol are used. Most of our customers use Ethernet/IP because most use Rockwell PLCs. Duh. Rockwell makes Ethernet/IP so easy and fast. Unless Schneider and others that use TCP have a bigger market share than Rockwell I don't see how Modbus/TCP can be 'kicking Ethernet/IP butt'.
In reply to Peter Nachtwey: Every protocol has its advantages and disadvantages. That is why for example on your PC, e-mail, web browsing, getting an IP address, database access, transferring files, etc. all use different protocols. To deal with each of your points in turn.
1) The address space in Modbus/TCP is at least an order of magnitude greater than the capabilities of most hardware to make use of it. There are very few industrial applications for this much data. I don't see address space as a problem.
2a) For support of data types, there are actually two general opinions. One opinion is that a data transfer protocol should not impose meaning on data. The other opinion is that is should. The problem with imposing meaning on data is that either your data types are limited to what the protocol supports, or else you must jump through hoops to coerce the unsupported data types into another form. The advantage to imposing meaning on the data is that if your problem is narrow enough it can save some work. The second point of view is mainly of use where a single party controls the design of all devices end to end. The first point of view is useful with more open protocols.
2b) Data sizes are a different matter. It would be useful if Modbus/TCP supported 4, and particularly 8 byte words. So far as I know however, no commonly used industrial protocol supports 8 byte words (which are used for standard double precision floating point numbers).
3) There actually is a proposal for a Modbus/UDP, although it hasn't been accepted by the Modbus organisation. The changes to the protocol to implement it are trivial. As for which of UDP or TCP is better depends upon the particular application (which is why both UDP and TCP exist). UDP has an advantage where you are dealing with very large numbers of connections. It has the disadvantage though of throwing more of the work of tracking errors back onto the application. TCP has an advantage when you have fewer connections and want the communications stack to do more of the work for your application. So far as communications speed is concerned, the practical bottlenecks in most industrial applications don't seem to be in the protocol stacks.
4) Your point about maximum message sizes is closely related to point # 1. Again, for most practical industrial applications this isn't a problem. Few industrial devices can handle large amounts of data regardless of the protocol. Controlling a couple of dozen valves in a valve bank only requires a few bytes of data (e.g. 4 bytes for 32 solenoids). For very large transfers of data (e.g. video streaming), none of the industrial protocols that I have seen are actually a good choice. Industrial protocols are all intended for frequent transfers of small amounts of data. To add to this, Ethernet/IP devices seem to generate very large numbers of small packets to transfer data. This tends to be a real bottleneck on many networks.
5) I'm sure you have some very nice Ethernet/IP products. As for your statement that you "don't see how Modbus/TCP can be kicking Ethernet/IP butt", I don't know where you saw that statement anywhere in my message. What I've been saying is that I would like to use the Ethernet/IP protocol, but the specs are closed so that it just isn't practical to do so.
>Modbus/TCP seems to be everyones first
>or second choice or option but
>Modbus/TCP's only advantage over
>Ethernet/IP is simplicity but this
>comes at a great cost.
>1. Modbus/TCP has a very resistricted
>addressing space. 64K words is not
>enough for many applications. <
I've never found this to be a restriction in any of my applications. However, there are ways around this by using the "Unit Identifier" in the MBAP header.
>2. Modbus/TCP doesn't have data types.
>Floats, DWORDS, and DINTS are transfered
>as words. Ethernet/IP supports data
Not true. See page 24 of the Open Modbus/TCP Specification Release 1.0 29 March 1999. There in B.2 is a chapter on data types.
>3. There should be a Modbus/UDP as well
>as a Modbus/TCP. TCP is not the best
>way to send I/O. UDP is much better.
>Ethernet/IP got this right. TCP should
>never be used for I/O. If something goes
>wrong the TCP stack will retry trying to
>send or receive old data. UDP will just
>send or receive new data the next time a
>transfer is made. This has been covered
>many times and at many forums. <
Again not true. Modbus/UDP is a well known and used by many. Kepware's KepServerEx supports it in their Modbus Suite.
>4. Modbus/TCP packets/messages are very
>small compared to Ethernet/IP messages.
>One can send a lot of data with just one
>MSG block. We have transfer 32767 words
>with one MSG block. MSTR blocks are
>limited to just 100-125 words. This
>means that a PLC program must download
>1000 words in many transfers. Many
>programmers are not capable of writing
>code that does that. <
Are you stating Ethernet/IP is simpler to code compared to Modbus?
>We have 3 Ethernet/IP certified
>products. They can communicate using
>any one of many Ethernet application
>layers including Ethernet/IP and
>Modbus/TCP. We have a pretty good idea
>of how our products being used and what
>protocol are used. Most of our customers
>use Ethernet/IP because most use
>Rockwell PLCs. Duh. Rockwell makes
>Ethernet/IP so easy and fast. Unless
>Schneider and others that use TCP have
>a bigger market share than Rockwell I
>don't see how Modbus/TCP can be
>'kicking Ethernet/IP butt'. <
Industry analysts have reported over 7 million Modbus nodes in North America and Europe alone. Why would ODVA be putting support for Modbus into Ethernet/IP if there wasn't something to gain?
Remember Modbus was created back in 1979 while it might have some limitations in 2008 it success is because its truly open, unlike Ethernet/IP.
Modbus is about as "focused" on I/O as EtherCAT is -- that is, not much, unless you only look at the surface.
EtherCAT standards are free as long as you join their user organization (for free, too), and agree to some terms. Those terms are fairly reasonable (much more reasonable than ODVA's).
EtherCAT can be used entirely for acyclic messaging and then there are no real-time requirements of any sort.
There are two protocol variants in EtherCAT: device protocol and automation protocol (EAP). The former is used to do real-time data exchange with I/O points, drives, sensors, etc. The latter is used across the factory floor to link PLCs, factory supervision, etc.
So where can I get The EtherNet/IP Specification by ODVA for evaluation?
Can anyone send me a link or a copy?