When Is EtherNet/IP Not The Right Choice?

I had an interesting phone conversation with a guy this morning on EtherNet/IP and how to use it. It’s very similar to a lot of the calls that I’ve taken over the years.

With EtherNet/IP, The first thing I always do is to define the terms so that we know we are talking about the same things. There is so much confusion about how the EtherNet/IP devices are labeled that I always have to clear that up first.

For the record, an EtherNet/IP Adapter which is also sometimes called an EtherNet/IP Slave or an EtherNet/IP Server, is the END DEVICE. That’s the device that is some kind of sensor or actuator. It is a valve block, drive or gateway like the Modbus TCP to EtherNet/IP device converter. The Adapter has the inputs and outputs.

The Scanner is the other end. That’s the controller side and it collects inputs from one or more Adapters, processes logic, sets outputs and transmits those outputs to the Adapters. Scanners are also known as Clients or even Masters. An Adapter is usually connected to just one Scanner.

Any device can be a Scanner. For example, you can send EtherNet/IP Adapter data to a Modbus RTU Master using a Modbus RTU to EtherNet/IP device converter. That device is an EtherNet/IP Scanner in a little black box.

So the guy this morning wants to build an application in VB and he wants to connect his application to a couple of Drives. All well and good. The problem right away is that he doesn’t want to spend a lot of money.

With EtherNet/IP it’s hard to avoid that. I usually give guys like him a couple of options. One, he can get an OPC Server and use standard Microsoft interfaces to access the drive data. That’s not always inexpensive and ties him to a MS environment. Many, many end users want as few MS devices on the factory floor as possible. There’s also some configuration hassles around OPC and training issues. OPC works well but there is an administrative cost to it.

A second option is to use a DLL. That’s not a bad approach. The interfaces are straightforward but the cost is similar to an OPC driver. You do avoid all that administrative hassle and issues with updates to Microsoft and people unintentionally screwing up the OPC driver (happens a lot).

But the question I always get to in the end is “Why EtherNet/IP?”. That kind of stuns them for a second. Aren’t I one of the EtherNet/IP gurus? Don’t I advocate it all the time on YouTube and in Blogs and in my talks? Yes, all true but that doesn’t mean it’s the be-all end-all.

The question I ask in simple systems like this is “Why don’t you just use Modbus TCP?” Modbus TCP is supported on lots and lots of drives. I am willing to bet that 95% of drives that support EtherNet/IP will support Modbus TCP. In simple systems, it is just as fast and just as easy to use. In fact, I would argue that writing speed references to a register in a Modbus TCP drive is easier than writing the assemblies of an EtherNet/IP drive.

It’s certainly cheaper and it can be embedded right in your VB code. It’s simple enough for most programmers to do on their own. If you don’t want to build it, it’s pretty inexpensive to buy and you might even find it for free. And you have zero administrative nightmares and can run it anywhere you can run your VB code.

The only time you really have to have EtherNet/IP is if you are in a RA environment and need to communicate with one of their PLCs or the device you are talking to gives you no other option.

In all other cases, it pays to investigate alternatives to EtherNet/IP.

John