Home store site map
Bookmark and Share
Video - EtherNet/IP Overview


Video Transcript

Now that EtherNet/IP is supported by the Productivity Series of controllers, you can seamlessly communicate with EtherNet/IP enabled devices like Advantec Adam Remote IO devices, AMCI Absolute Encoders, Beckhoff I/O devices, Allen Bradley FlexDrives, AMCI Motion Controllers and any pretty much anything else that supports the EtherNet/IP Explicit and Implicit messaging protocols.

The idea is simple … you have an EtherNet/IP enabled device like an Encoder, a VFD, Remote I/O another PAC or PLC, etc and it has data that you need access to so you can configure and monitor the device. EtherNet/IP in the Productivity Series of controllers does this via this Explicit and/or Implicit messaging.

Explicit messaging is basically the same Client/Server request/reply messaging you find in standard Ethernet devices. The client requests stuff from the server device via TCP/IP and that request has everything the server needs to respond explicitly built into each and every message. And the response has everything the Client needs to decode the message.  This is ideal for general purpose non-real time messaging because a Client can send a request anytime it wants and the Server can reply when ever it’s ready.  There isn’t anything time critical about this explicit Client/Server communication. The two ends are just two devices sitting on the network that aren’t really connected in any way so we call this Un-Connected messaging. This is great for things like setting up parameters in a Variable Frequency Drive.

Implicit messaging on the other hand – which we also call I/O messaging - IS time critical and it’s much more efficient.  The reason it’s more efficient is you pre-setup – or “connect” - both ends so they know implicitly exactly what to expect without having to include the extra communication baggage in each and every message.  The data is simply copied back and forth at a periodic rate in the background.  You don’t have to do anything once it is enabled – the data just appears on your local controller as if it was local I/O. This is ideal for things like monitoring the speed of a Variable Frequency Drive.  Once you enable the messaging, the current drive speed just appears at your local controller without you having to anything and that speed is updated at whatever rate you specify.

This Implicit messaging is done using UDP and because this is different from the explicit nature of the Client/Server pair, we use different names for these guys – we have the Implicit Scanner which we call the I/O Scanner for short and the I/O Adapter. Again, this is referred to as connected messaging, and this is referred to as un-connected messaging.

The Explicit protocol can also do this connected messaging where both ends know what to expect and data is transferred at periodic intervals in the background, but it still uses the TCP/IP protocol with all the extra communications baggage built into the message, so it’s not nearly as efficient as the Implicit version of the Connected messaging, but it is available for you to use if you want.

Why have both types of connected messaging?  Because some vendors of EtherNet/IP devices use TCP/IP and some use UDP. It all depends on how they want to communicate with the outside world. The good news is, the Productivity family of controllers supports all of these. So if you have an Ethernet/IP device that uses Explicit or Implicit messaging, then you’re in business with any Productivity Series Controller that supports EtherNet/IP.

 

Performance plus Value … That's Productivity.

From AutomationDirect.