Understand the big picture before delving into the details of using EtherNet/IP on the Productivity Series controllers.
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. And it’s so easy with the Productivity Suite software. You just fill in a few blanks and you are up and running. With Explicit messaging there is a single ladder instruction that does the work and with Implicit, well, you just set it up in the hardware configuration and forget about it. The data is just automatically transferred in the background and just appears on your local controller as if it was local I/O ready for you to use. Easy. A couple side notes: These are generically called Originators because they originate the transfers, and these are generically referred to as Targets. And sometimes you will see folks use these terms interchangeably, so just beware of that. The Common Industrial Protocol – or “CIP” - refers to this as Class-I messaging and this as Class-3 messaging, so you may hear those terms use sometimes too. Well, hopefully that helps set the stage for you. Check out the other videos in this series to see how incredibly easy it is to configure and use the Productivity Series Controllers that support EtherNet/IP to communicate with your favorite EtherNet/IP devices! Performance plus value. That’s productivity. From Automation Direct.