In the Explicit Un-Connected primer video we saw that EtherNet/IP is really just a bunch
lookup tables the device vendor fills out.
The blank table template in each class is called an object and a filled-in table is
one specific instance of that object.
There was also a table of services – things you can do with these tables - like get and
set the values and another table that listed the attributes of the whole group – things
like how many total instances are there in the group.
All these things taken together are what we call the Class.
Once you have that picture in your mind, getting or setting a parameter of a EtherNet/IP device
is easy.
Let’s do a few examples with an Allen Bradley Power Flex 40 as the server and a Do-more
PLC as the Client.
In the Do-more Designer software, that Flex Drive is just another device so as always,
we start with system configuration and work our way down this list.
There’s nothing to do at the CPU level, It doesn’t affect the I/O of the PLC, It’s
not a new module, but it is a new device so we’ll start here.
Could we use this one generic EtherNet IP built-in device to talk to all of our EtherNet/IP
hardware?
Sure.
BUT, it’s better to create a new Do-more device for each piece of Ethernet IP hardware
because each one needs its own TCP/IP connection.
If you run all of those through the one generic EtherNet/IP device, it has to manage all of
those which slows things down.
If each piece of EtherNet/IP hardware has its own device, then things get real simple
and much faster.
So we’ll create a new EthernNet/IP device for this Flex Drive.
New Device, EtherNet/IP Client, OK.
Give it a name, how abut FlexDrive and the rest of this looks fine.
That’s it.
We just created a device we can talk to.
There is no associated I/O mapping and no new structure because there is nothing for
us to interact with in this EtherNet/IP client.
Notice that there IS a structure for the EtherNet/IP SERVER – some people call that the slave
– we’ll see that in action in the video where we use the Do-more as a server to another
device.
For this video, the Do-more is the Client or Master device.
Great, we’ve created our EtherNet/IP device.
Let’s talk to it.
In this setup we have a Do-more at this IP address, a Stride Ethernet switch here and
the Allen Bradley PowerFlex40 drive here on the same subnet at this IP address.
To talk to it we just drag the EtherNet/IP instruction from the toolbox in the Protocol
section and fill in the blanks.
We want to talk to our PowerFlex device.
Remember, that device – which is a lot like the drivers you have on your windows pc – manages
the hardware for you.
It takes care of all the handshaking, error checking, the memory allocation, etc. so you
don’t have to mess with any of that.
It makes your life easy.
We’ll enter the device’s IP address is this.
We have a direct connection so the default port number is fine.
For the rest of this, we just look up the answers in the PowerFlex 40’s EtherNet/IP
Adapter Manual.
In Appendix C we see all the different classes available.
We want the Parameter Class so we’ll scroll down to page C-9.
Here’s everything we need to know about how the parameter information is organized.
The Class number is 15.
That goes here.
This chart is telling me that the Drive Parameters Numbers ARE the Instance numbers.
That means these instance tables we need have the same numbers as the drive’s parameters
– that’s really convenient.
In this example we want the nameplate voltage which is drive parameter 31, so that’s also
table - or “instance” - 31.
It’s also telling us that instance zero is the class attribute table – this guy
– and here’s the format of that table.
So if we wanted to know how many parameters are in this Class, we would just specify Instance
zero, attribute 2.
Here’s the object template – the table format for these instances - the parameter
value, name, units, data type, min value, max value – everything we could want to
know about each drive parameter.
We want the value of the name plate voltage for this first example – that’s attribute
number 1 - so that number 1 goes here.
This is the format for the services table format for this class.
We want to get a single attribute which is a 0E hex or 14 decimal, so we put that one
here.
So that’s all there is to it – you just go to the hardware manual, look up the numbers
for the service, Class, Instance, and the attribute of that instance that you want and
you’re done.
In this example we want to get from the parameter class, parameter 31 which is instance 31 – and
we want to know the nameplate voltage of that instance which is attribute number 1.
We’ll enable this on an edge, set these bits on success and error and put the response
here which I happen to know is a 16 bit unsigned result – I’ll show you how I know that
in just a minute – which is 2 bytes max.
Let’s add a control bit so we can enable this instruction and transfer the project
… Let’s bring up a data view and monitor the
result which we put in D1 and the result length which we put in D2.
Let’s also add the control bit so we can activate the instruction.
When I toggle that control bit, I see the request was successful and the name plate
voltage is 225 Volts and that two bytes were returned.
Perfect.
That’s all there is to it.
Given these tables, we just look up what we want and fill in the blanks.
EtherNet/IP is easy once you understand how to navigate these tables.
How did I know that the nameplate voltage was an unsigned 16 bit integer?
I ask asked for it!
You can see back in appendix C that the data type is attribute number 5.
Let’s try that.
And since it’s almost the exact same thing as we just did, let’s just copy that instruction
and modify it.
The only thing we need to change is the attribute we want – instead of the parameter value
we want the data type which is number 5.
And let’s put that result in D3 and the length in D4.
And let’s use these as our success bits.
We see in appendix C, attribute number 5, is an unsigned integer or 8 bits, so we only
need one byte for that.
Click OK.
Let’s trigger this instruction on the success of the previous one.
And write it out to the Do-more.
And over in the Data view let’s add our new results.
Toggle the control bit and sure enough, the device tells us the data type for parameter
31 is 199 which is C7 hex which according to our lookup table is Unsigned 16 bit.
So before I started this video, I executed this command so I would know the data type
to use for that first example we did.
Again, everything you need to know is in these tables and once you understand how to use
them you will be in total control of your device.
Let’s do another one.
Let’s get the name of this parameter.
Again, it’s almost identical to what we just did, so we’ll just copy this instruction.
Same Class – or group of tables.
Same Instance – or table number.
The only difference is now we want a different row of the table – or attribute of the parameter.
We see back in appendix C that the name of the parameter is attribute 7 and that it is
a short string.
So we put a 7 here, and put the result in a string structure.
Change the success bits and we’re Done.
Trigger this one on the success of the previous one.
Accept everything, and write out to the Do-more.
Add the string to the data view, toggle the control bit and we see the name of this parameter
is “Motor Name Plate Voltage.”
Awesome.
Do you notice this little dot here?
That’s because the string sent to us from the flex drive has a leading length byte.
If I switch this to Hex display this 10 hex which is 16 decimal is a count of the characters
in the string.
And if we do a short string zero dot length – it agrees – there are a total of 17
characters – which includes the length byte – in this string.
Perfect.
Ok, this time we’re going to ask the Flex Drive what the units of the Name Plate Voltage
are.
It’s exactly what we just did so we’ll copy that instruction and change the attribute
we want to the Units Attribute, attribute number 8.
Change the status bits, put the result in short string 1.
Great.
Let’s enable this instruction on successful completion of the parameter name request.
Accept the changes and write the project to the Do-more.
And I’ll add the units string to our dataview.
Toggle the initial name plate voltage control bit, and sure enough, we see the units are
volts.
What if we wanted to do all of this for the acceleration parameter?
Same thing, Right?
Except now we want parameter or “instance” number 39.
What if you wanted to set a parameter instead of get one?
Well, the SET service code is 10 hex or 16 decimal.
Everything else is pretty much the same.
As you can see, once you get the hang of using these groups of tables – or “Classes”
– it’s easy to get or set anything you want using just the one explicit message instruction.
And keep in mind – we only messed with the Parameter class of this device – there are
a bunch of others you can explore simply by changing the class number here.
The only hard part of all of this is finding the documents that have the EtherNet/IP class
information – you know, all those filled out tables - for your target device.
Once you’ve done that, the rest is easy.
If you have any questions, please contact AutomationDirect’s FREE award winning tech
support during regular business hours – they will be happy to help you with any AutomationDirect
parts.
The PowerFlex drive isn’t an AutomationDirect part so don’t ask them about that, but you
can ask folks on the forums – they love to share their years of experience!
Just don’t post any questions directed at AutomationDIrect’s support staff there,
they don’t monitor the forums on a regular basis.
Spend Less, Do More.
With AutomationDirect.