Ethernet/IP libraries

[paulengr 44]

I'm finding myself more and more involved with Ethernet/IP-based processors instead of PCCC processors. There's still a lot about the I/O portion of the protocol that is very unclear to me, so I thought I'd do the obvious and read the specs. Ha! Fat chance. AB clearly states in multiple places on their web site that the specifications are freely available for inspection. As near as I can tell, this means that I could drive to Ann Arbor, MI, and they'd pull out a box and that I could freely inspect the box (not the contents)! The ODVA only wants to give away that information if I sign a very nasty 8 page contract with them, pay for a vendor ID, and pay to become a member of the ODVA. About the only "open" thing about Ethernet/IP is your wallet if you try to get information on the protocol, because it's only "freely" available after you pony up a few thousand dollars to the ODVA along with paying your lawyer to parse their extremely unfriendly Terms of Use contract (which appears to be written by the same lawyers that wrote the very nasty Microsoft EULA)'. So...next stop, source code. There is also supposed to be source code "freely available" on their web site. Again, "free" means the same thing as "open" with the ODVA...in other words, these words mean the opposite of what they mean in English. I've found 3 libraries in C++ implementing it. All seem to be inactive: TuxEIP. Old site is dead/inactive. Can find it filed under the pvbrowser project. CELL. Ron Gage has stopped supporting it but there are still open copies floating around on the internet. IOMAK. Haven't heard of this one before but it's listed on sourceforge and appears to be inactive. Out of the three, it appears that TuxEIP is/was in use at least in the pvbrowser project. It is not clear if the other two projects were ever actually used. The overall design of all 3 libraries appears to be similar although their implementation details are radically different (especially IOMAK). It appears that CELL was never intended to use "connected mode". TuxEIP is just the opposite. And IOMAK appears to be the most complete but severely lacking in comments and documentation. AB's web site appears to have enough scattered details to piece together the protocol details that are missing. Does anyone have any information on any of the 3 open source Ethernet/IP libraries to indicate whether they implement the IO portion of things? Reason for my inquiry is that 2 years ago, Cisco was pretty much promoting the idea that to do Ethernet/IP right for I/O, you should either buy 2 ENBT cards and run a separate isolated network for I/O, or else set up a separate VLAN just for your I/O. Separate VLAN's are certainly possible but get into some very ugly details because either the SCADA servers then have to be on overlapping VLAN's, or the PLC does, or we need to add layers of routers for inter-VLAN communication. Overlapping VLAN's are no fun at all in terms of documentation and configuration. Now Cisco has completely backed off on the big VLAN kick and seems to suggest that putting all your PLC's onto a separate "controls" LAN or VLAN is sufficient. I'm still a bit nervous about what all of the traffic is when it comes to I/O and the details on any of the public/free documents are unbelievably vague. Suffice to say that I feel reasonable confident in what goes on in either unconnected or connected sessions between a PLC and a SCADA system since that seems to be fairly well documented. What's not documented well at all is the I/O & PLC traffic. And since Cisco was originally making noise towards what goes on in the I/O side of things and why/how you'd want to protect, they got my interest enough to investigate.

[SteveJanisch 0]

Sorry for the very slow response... I only became a member of the forum quite recently. I know for sure that at least v1.0 of tuxeip did not implement the IO porition of EtherNet/IP. The library was mainly conceived to talk to AB PLCs (and it does that quite well). You will be able to use some of the code in tuxeip to build a driver since some of the initial comms to create the IO packet are defined in tuxeip. ODVA itself has example code for an IO server -- http://www.odva.org/default.aspx?tabid=134. I found the code fairly difficult to follow but was able to follow it.

[paulengr 44]

Going to that link says "order software subscription". Does this sound like freely available to you?

[SteveJanisch 0]

The sample code itself only requires "registration"... look further down on the page, there should be an option to "REGISTER to DOWNLOAD EtherNet/IP Example Code." I will state that even with the code, it would have been very very difficult to write an IO driver without the spec. IMHO the sample code is needlessly confusing and is what it is -- sample code (i.e. they are not really trying to teach you the spec by the code). So I generally agree with your frustration. In spite of the non-profit orgranization and open standards, this is really just big business. I'm not really sure exactly what you want... if you merely want the spec you do have to pay ODVA for it, but you don't necessarily need to purchase an ID or become a memeber of ODVA. You only need to purchase the ID if you want to become an ODVA-authorized vendor. Be careful if you order the spec, however, since ODVA will default you to purchasing a specification annum, and will pleasently send you a bill each following year to renew you license. As far as I've had the misfortune, this is pretty much standard operating practive with all such agencies... I've had it happen with CANOpen and ODVA as well. About the easiest spec I've ever come across is EtherCAT. You do have to become a member of the organization, but all you have to do is provide some information about your company (or self if you are free lancing) and you are pretty much in. No annual fees.

[BobLfoot 301]

Let me agree that ODVA == Big Business. The last time I had dealing with ODVA I worked for Toshiba and was invited by Omron to attend a 3 day DeviceNet School. While there I met big wig engineers from Cutler Hammer, Rockwell, Omron, Toshiba, Siemens and SST to name a few. I reminisce Paul to make this point. If you're on good speaking terms with your local Omron or RA Tech support folks you might snag a look at the spec without opening your wallet. And while he drinks the beer you bought him you might even walk to the copy machine. Ha Ha.

[paulengr 44]

I'm not really interested in building my own devices. If I was going to do that, it seems pretty clear that the moment it hits the market, the ODVA lawyers are going to try to sue me and their marketing wing is going to declare my wares to be heresy because the "open" standard is clearly closed unless you ante up. And with access to for instance the compliance library, as a vendor, I'd be an idiot not to ante up the money anyways. What I'm really interested in is more details on the protocol. With Modbus/TCP or even PCCC, it's a simple request/response stream of packets occurring over a TCP session. You can easily pick apart what is happening and diagnose problems at the protocol level. Not so with Ethernet/IP. Not even close. So when I have problems with troubleshooting Ethernet/IP devices, traffic, etc., it leaves me wondering exactly what's going on. Right now it's a black box scenario. I see packets emanating from point A and arriving at point B. I can poke through it with Wireshark or the web pages of the AB gear to see the data. But when things go screwy, I'm left with really nothing to go on. It doesn't help that especially with ControlLogix PLC's, there are lots of extra features and things that are wrapped up in Ethernet/IP protocol but don't follow the standard per se except to use it as a transport layer (e.g. the alarm commands). Case in point. About 6 months ago I had a new installation consisting of three 1756 racks, two HMI's, and 3 drives. About once every 2 weeks, all Ethernet/IP communications would mysteriously come to a screeching halt for about 10 seconds between the drives, the remote I/O, and the PLC rack. Then the connections would reform and life was good about 10 seconds later. The HMI traffic never stopped. There were no errors or anything else indicating a problem. Now eventually I found what stopped it from happening. I did not say that I found the problem because I didn't. I simply methodically went through looking for potential problems and eventually found something that stopped the issue from reoccurring. Seems that there wasn't an IGMP query device on this particular subnet & VLAN, so all Ethernet/IP traffic was broadcasting. Packet loads were higher than they should have been, but none of the devices were reporting packet loads in excess of their limits (Powerflex drives are limited to around 500-600 packets/second), BUT it still doesn't explain at all why everything suddenly died and then restarted. I suspect that something else is up...a timer some place, an error counter? I don't know what. But since the whole Ethernet/IP protocol is so "open", there's really no way to dive deeper into the protocol to troubleshoot what was happening except to be able to look at a packet stream containing effectively unknown contents. Hence the reason that the ODVA really, really ticks me off in this instance. I can't troubleshoot anything with their protocol because their "open" protocol is not public information.

[TimWilborne 108]

Paul you have brought up some very good points here. As I continue to get deeper into communications protocols, I should take these comments into account when designing systems

[arj3090 5]

Rockwell has actually released an Ethernet/IP stack to the open source community: http://sourceforge.net/projects/opener/ Several years ago, ODVA used to allow you to download an outdated spec of Ethernet/IP. Trust me, not light reading by any means. If you know VB, AdvancedHMI includes an Ethernet/IP driver that encapsulates PCCC so it works with the SLC and Micro series: http://sourceforge.net/projects/advancedhmi/

[SteveJanisch 0]

Thanks for the posts. It's hard to keep up with the open source community! The IO stack looks very interesting. I'm going to have to look closely at that one. And since tuxeip appears to be abandoned, perhaps the AdvancedHMI stuff will benefit the open source community.

[SammyB 0]

Has anyone tried the sourceforge/opener stack, or at least have getting started instruction??

[matzy 0]

Has anyone done something with the ODVA Ethernet/IP Example code and example application? I'm looking for a library which provides explicit messaging capabilities, to write a small program in C# or C++ to read/write configuration data from an HMS Anbyus Ethernet/IP module. I've looked at the encapsulated data with Wireshark, but that's really hard work to figure out how it works. I'm very grateful for every input on this.

[SteveJanisch 0]

I looked at it. It is mainly an implicit IO driver, but there was (if I remember correctly) also an explicit sample (although I never looked into the details). If you are looking for something to communicate to AB processors, the tuxeip library was very good and I've used it extensively to communicate to SLC and ControlLogix PLCs. The website appears to be defunct, but you can still get it (e.g. from pvbrowser). I'm not sure how it would work through the HMS Anybus module, but it works through "normal" ethernet hardware just fine.

[paulengr 44]

As an update, check out Inductive Automation. They are giving away an OPC-UA driver for free which includes drivers for AB processors. Don't know much else in terms of details but since OPC-UA includes a SOAP/WSDL interface, you can trivially point "stub code" systems at WSDL/SOAP servers and it should spit out interface code "for free".