Productivity Series EtherNet/IP Unconnected Explicit Messaging Primer at AutomationDirect

Explicit Un-Connected messaging is typically used for setting up and configuring a device because it gives you access to every parameter in the device, setting up the device is not time critical, and you can be confident the parameter actually got to the device because it uses the TCP/IP protocol which guarantees delivery of those parameters. You would then typically use implicit connected messaging to actually monitor the device once it is running because connected messaging, provides periodic updates and requires no effort on your part to get the data – it just appears at your local controller. Implicit connected message delivery isn’t guaranteed because it’s UDP, but if you don’t get a drive speed or amperage update when you’re getting several per second it’s not a big deal if you miss one every now and then. Explicit messaging can be setup as connected messaging to give you periodic updates, which is cool because it’s still using the TCP/IP protocol to guarantee message delivery but it adds a larger burden on the processor because it has a lot more bulk in the messages and handshaking which you usually don’t need for periodic updates. This video is about Explicit Un-Connected messaging, so let’s focus on that. With Explicit Un-connected messaging you are in complete control which also means you have a lot more work to do. You have to generate each and every message in ladder code; you have to monitor the tags to see if the request was successful, you have to dig up all the device specific parameters for each and every message. Once you understand how it fits together though, implementing Explicit Unconnected messaging in the Productivity Series Controllers is easy. Before we do that though, there is a lot of terminology you gotta wrap your head around with this Explicit Un-Connected Messaging, so before we do live examples, we’re going to back up and look at the big picture. This video covers all of these concepts, with other videos we have live demos showing you exactly how to use Unconnected Explicit Ethernet/IP messaging to configure things like Variable Frequency Drives. For the purposes of this video, let’s assume we’ll use a Productivity3000 as the Client and an Allen Bradley PowerFlex-40 Variable Frequency Drive as the Server and the PowerFlex40 drive is equipped with the Ethernet adapter module to make it EtherNet/IP compatible. Appendix C of that Ethernet Adapter manual summarizes everything we need to know about how to access the data in the PowerFlex40 drive via EtherNet/IP. The first table in the Appendix breaks stuff up into these “objects” – an object is just a generic way to describe things that share common features or attributes. We’ll look at the details of these specific objects in the next video where we do a live example with a Power Flex Drive. For now, if we look at objects in general, and we use the example of Drive parameters – the drive parameters all have similar attributes – right? Each parameter has a Name, a value, a min, a max, a data type, etc. – these are all attributes we can use to describe each of the drive parameters. So we can use a template like this to describe each parameter. Here’s Drive parameter 31 for example, with his values filled in. His name, his current value, etc. … Keep in mind I’m just making these numbers up for now – we’ll look at real data in the next video. Here’s another one – Parameter 32: the Motor Name Plate Frequency. Again, uses the exact same template and just fills in the blanks. How about Parameter 39 the acceleration time? Same thing … Parameter 40 - Deceleration – same thing. So we end up with a huge group of tables like this describing every parameter in the drive using this common attribute template which we call an object. Now, what can I do with these attributes? I can get the value, Set the value, reset the value, etc. We call those the services – all the things you can do to this common set of objects. So since all of these instances of this common template or object share a common set of attributes and services, we group them together into a common class of objects called the “Parameter class.” There’s one more template we need – this one describes the attributes of the class itself – it tells us the revision of this class, the total number of parameters in this class, and some other things we might want to know about this group – or class – of objects. So again, the template describes a generic object and a filled in template creates a single instance of the object, like Parameter 31 – that’s an instance of the object, this is another instance .. another instance, another instance. So suppose for a moment we want to get the value of parameter 31. Well, we look up in the manual and we find out that the parameter class is number 15 or 0F hex, the get is code 0x0e, The instance of the object we want is 31 – parameter 31 - and the attribute we want is number 2 – the value. We simply hand those numbers to the Explicit message instruction and it fetches the value of that parameter for us. The cool thing about this is since every EtherNet/IP drive uses this exact same messaging with this exact same set of templates, you can use this exact same instruction in ANY drive, not just this one. So once you understand how to use this, all the sudden your world just got a whole lot bigger because you don’t have to learn a new way of accessing every new device that comes down the line. You just specify an Ethernet/IP enabled device and code you wrote for one manufacturer’s device will be easily ported over to any other manufacturer’s device. That’s huge and makes you much more productive. Each class has its own set of predefined tables, but you access each one the same way. For example: let’s look at the Identity class. This is used to identify different components in a device. In our device we have the Host drive itself and the EtherNet adapter. You might even have another communications adapter module connected to the drive. How would you get the Vendor ID or the device type or the Revision or the serial number? You would use the identity class. Here’s the predefined template of attributes, now the vendor just fills in the blanks to create an instance of each object. Here’s the drive instance – so now I can look up all these things about the drive - here’s my EtherNet/IP adapter instance. Again, you might have some other communications module. The drive manufacturer will create one of these instances for every option available. And since they all use this standardized template along with a standard list of services and class attributes – anyone that wants to know about the identity of one of these objects knows how to get it. You as a programmer just issue a command that says you want to GET, from the Identity Class – the revision - of the host drive. We’ll see how to get these numbers in the examples in the next video – but given these numbers, we just issue an Explicit message command and the EtherNet/IP messaging retrieves the revision of that hardware for us. If you were super ambitious, you could even write a program to query and fully auto-detect and configure an entire EtherNet/IP system without knowing anything but the IP address of each device on the network because you can ask every device who he is, what type he is and then configure him appropriately. Very cool. What other kinds of classes of objects are there- that is groups of things that behave similarly? We’ll if we look at that Allen-Bradley VFD for example, it looks like there is an assembly object, a register object, and a bunch of others. Do you need to know all of this? No. In fact, most of the time all you are going to care about is the Parameters Object so you can setup and configure the drive. We’ll do several examples of that one and maybe a couple others in the next video. The key thing about this is once you get the hang of using these classes of objects, you’ll be able to use any of them on ANY EtherNet/IP enabled device out there. That includes other manufacturer’s drives, encoders, remote IO, other PLCs and PACs, etc. And of course Productivity Series of controllers makes it super easy to do. Well, that oughtta be enough to get you oriented. Check out the other videos in this series to see some live demos of the Productivity 3000 using Explicit Unconnected messaging to communicate with devices like the Allen-Bradley PowerFlex Drive. Performance plus value. That’s productivity. From automation direct.