Control.com - Nerds in Control

Hello Everyone,

I was wondering if any of you could give me some insight into how to communicate with Ethernet IP devices from Java.

I already have written my own Modbus TCP/IP driver in Java simply using the spec. However, I now realize that the specs for Ethernet IP are pretty locked down by ODVA. I also noticed some outrageous requirements for using it including hefty costs.

I am wondering at this point what options I have. Personally, I would like a Java based solution due to the posibiltiy of porting it to multiple operating systems. I know Microsoft is king in the Controls world, especially with Allen Bradley, but I'd prefer to be able to use Linux.

My reasons for this are simply that Windows 2008 Server is quite expensive and Vista is not fit for a production enviroment in my opinion.

So what options do I have here? Is there a direct driver available? Would I be forced to use an OPC server? Could you please provide some suggestions?

Thanks,

Jon

You can, in fact, do it yourself. You can even get away without paying a bloody fortune, assuming you're not trying to sell a product with "EtherNet/IP!" stamped on it.

Having said that, if you've implemented Modbus/TCP in Java you have NO IDEA what's in store for you to implement EtherNet/IP. We spent over six months getting it to mostly work with a handful of devices. (Granted, we did it in C. Java would be easier, but not THAT much easier.) On a difficulty scale of 1 to 10 I would put Modbus/TCP at 2 and EtherNet/IP at 9.

I'm not aware of a commercial or open source EtherNet/IP implementation in Java. That doesn't mean they aren't out there.

Hardware solutions are possible. AnyBus makes a Modbus/TCP to EtherNet/IP device. Hilscher makes a PCI card that handles EtherNet/IP in hardware and has Linux drivers. You'd need a bit of JNI for that one, but not much. Woodhead has something similar.

By the way, if you only want to send messages to a PLC, as opposed to control a device like an I/O block or drive, that's a much simpler subset of the EtherNet/IP spec. Still way harder than Modbus/TCP.

-James Ingraham
Sage Automation, Inc.

I may look into Any Bus. We currently use gateways to talk to our SPI devices over Modbus TCP, so another gateway could make sense.

Are there any other providers I should try?

Thanks,

Jon

Ditto, what James Ingraham said about the time it takes to implement Ethernet/IP and the degree of difficulty and we have what I consider to be a very good Ethernet programmer. We wrote our own driver but I believe we bought a starter Ethernet/IP kit from ODVA and modified it to fit our needs. We then paid to get our product certified. These cost weren't too high. This happened a long time ago. I believe we were the second outside of Rockwell to be certified. The cost were insignificant compared to the cost of paying a good programmer for 6 months. The cost may be higher now.

I agree with ODVA's insistence that modules must be certified before they can claim Ethernet/IP compatibility. I don't see why those that do all the work to get their system certified should get tech support calls because of other peoples sloppy certifications. We paid to get out product Profibus DP certified but it didn't make any differences. There were plenty of other products that claimed Profibus DP compatibility that weren't certified and these products caused tech support problems for us. Major PLC and HMI companies couldn't even get their byte order right. Profibus DP certifications hasn't helped at all whereas Ethernet/IP has been relatively trouble free.

I am mostly in agreement except for one big problem. Under this system only larger, for-profit companies that are doing well can play. This excludes any FOSS or public spirited entity from fielding a product that would be of great use either in and of itself, or integrated into other such projects. If there were a provision to provide materials and a certification procedure to non-profit entities in the public interest, it would further everyone's interest in making Ethernet IP a true standard rather than simply another proprietary way to connect things. The "openness" in such a provision would also hopefully prevent the market from splintering as competitors go their own way rather than adopt a proprietary solution they perceive as clubware. Indeed, they are justified in doing so when they can be excluded. Something must be _given_ to create a true standard with widespread adoption. History explicitly teaches this. And as it has been said "Those who choose to ignore history are doomed to repeat it". The automation principals seem to be particularly ignorant in this regard, so it's safe to predict that EthernetIP will not become _the_ Ethernet standard for automation. Unless, that is, they choose to do what it takes to be inclusive. Modbus is making a rather improbable comeback for exactly the right reasons.

Regards
cww

In reply to Curt Wuollet: I on the other hand have to say that I'm in disagreement. I don't put a lot of faith in certification programs. I would put more faith in a program's reputation for reliability than I would in what certifications it has. Certifications usually set a pretty low bar for quality.

If a vendor has had less problems with their Ethernet/IP products than with their Profibus products, I think it is more likely that the reason for this is that there are a large number of independent Profibus implementations, while there's only a small handful of Ethernet/IP implementations that matter.

Basically, people use Ethernet/IP to connect AB hardware together or to connect a few kinds of third party hardware to AB PLCs. If you buy something that uses Ethernet/IP, you can be pretty sure that it was extensively tested against an AB PLC and "fixed" if there were any problems (even if it met the spec as is).

Go to the ODVA web site, and try to find a non-AB PLC in their list. WAGO has a model of 750 Ethernet Controller, Jetter has something that might be a PLC, PILZ has a scanner for one of their safety PLCs, and that's about it. So we can see AB PLCs and a couple of obscure products that probably sell in very low volumes in that configuration. Other than that, all you'll find is a list of things that people will want to connect to an AB PLC. And it's not a particularly long list either. So if you buy an Ethernet/IP field device, you can be pretty sure that it was tested against an AB PLC because there isn't much else to test it against.

Contrast that with Profibus. There is a much broader range of hardware from a larger number of sources that people could connect together under a wider range of conditions. That gives a lot more scope for things to go wrong.


If we look out into the real world at really large communications systems, we find that they manage to get along without worrying about certifications. Somehow Control.com manages to operate without requiring that every web browser and e-mail client and internet router in between be "certified" by them. Yet it manages to perform a communications task that is vastly more complex and on a far greater scale than Ethernet/IP ever attempts. Somehow the internet seems to function without needing any vendors to have meetings where they decide to limit what products are available in order to protect the consumer from poor quality.

Let's look at the other side of the coin. Microsoft set up an extensive driver, software, and hardware certification program for their fabulous new Vista operating system. They had logos and stickers and slogans galore. No hardware or or software could claim Vista compatibility without their approval. The 64 bit version would even refuse to load uncertified drivers. And the result of all that was? Well, Microsoft blames all the problems of Vista on poor quality third party software and hardware.

So the lesson of all this is simple. The internet doesn't work and is a complete failure because there is no trade organisation to control who can hook up to it. Microsoft Vista is the greatest and best software package to ever grace the universe. Anything different you may have heard is all lies meant to confuse you.

We're not too far apart :^). I think it is a matter of timing. Once there is a critical mass of something, yes, the oddballs quietly fade away. But standards _were_ important to the Internet until it became
important to be compatible _with_ the Internet.

None of the schemes we see in automation will ever begin to have the standardizing power that the Internet and it's protocols have. Trying to corner the market by starting up your own proprietary replacement for the Internet is laughable even to automation tycoons. They simply lack the acuity to see _how_ the Internet became ubiquitous.

Regards
cww

CWW said: "Trying to corner the market by starting up your own proprietary replacement for the Internet is laughable even to automation tycoons."

I don't know if you remember this, but that is exactly what Microsoft tried to do in the 1990s. Their original version of MSN was not compatible with the internet. It was a closed proprietary network like the ones sold by Compuserve (and several other companies).

They also had a proprietary alternative for intranets (for use internal to individual companies). It was based on using Microsoft Office as a browser and consisted of linked MS Word documents (instead of HTML pages). I had the misfortune to have to use the system for a while, and it was a useless piece of junk.

Both systems were miserable failures. People didn't want them, so few people bought them. Microsoft was forced to close down MSN (they reused the "MSN" brand when they launched an internet portal business later) and abandoned the "MS Word as a browser" idea.

People wanted open standards, so they chose the internet. That is what customers need to do in our industry. If we simply wait for the vendors to all suddenly change and start to spontaneously cooperate with each other, its never going to happen. If you want open, then buy open. The major vendors are going to follow the market, not lead it.

Of course I remember. And Microsoft almost put themselves out of the game that way. When they finally "got it" they began to try to pervert the Internet. Fortunately, it was already too strong for them to succeed. But, we also have to remember that Ethernet was proprietary at one time, and there was competition. Arcnet stayed proprietary and look where it is. These lessons are still ignored by this industry. The Ethernet model is particularly relevant, if one company or consortia held the keys, it would be on the scrapheap of history. By letting go, they succeeded beyond their wildest dreams. Publishing a reference implementation of EthernetIP OSS would do more than any possible marketing effort or any number of consortia. And how they could lose anything that way is way beyond me.

Regards

cww

I've written a Java driver and it runs on Linux. But I can't give it to you because it's not ODVA licensed and possibly illegal.

Either you pay ODVA and develop your own driver or you pay me so I can pay the license. You can then get the driver for free.

Either way, you are stuck with hefty costs.

Yes, like most Automation Vendor perversions
of the term "Open" it seems the Open part refers
only to your wallet. And you stand to get sued
if you actually try in any way to Open anything
else about it. It's the Big Lie form of propaganda.

But it works, people here call some of the worst
examples "Open".

Regards

cww

Hi there,

I agree with James on the difficulty scale, EtherNet/IP is quite complexed. You could use a gateway Modbus TCP slave to EtherNet /IP master. HMS has such a gateway, for more information please go to:
http://www.anybus.com/support/support.asp?PID=371&ProdType= Anybus%20X-gateway

You will need RSNetworx for configuration of the EtherNet/IP network.

If you have any questions regarding this solution, please let me know.

support@hms.se

/Patrick L

You might want to look at tuxEIP:

http://www.tuxplc.net/index.php?page=tuxeip

It's C, but could be ported to Java. I have thought about trying this myself. If there's enough interest, perhaps the tuxEIP author would be interested in doing a port.

Within http://pvbrowser.org we also use
http://www.tuxplc.net/index.php?page=tuxeip

But pvbrowser is C/C++. If you want to make use of tuxeip from Java you might generate a language binding using http://www.swig.org/

Jon,
just stumbled across your post while googling a related subject. There is Java Modbus implementation out there called Jamod.

I am not sure if it is still being supported by the original developers. Some of the API that it is built on is probably no longer supported by Sun but it is prob worth your while to look it up.

If the "EIP Device" is a Rockwell PLC, then you can create a very quick-n-dirty 4-message poll-response system. It won't be reading PLC tags, but it can read the pseudo-PLC5/SLC5 style data files which can be CREATED in RSLogix 5000.

The bytes required are explained in this PDF:
http://iatips.com/digiwiki/quick_eip_demo.pdf