Manually reading or mapping EDS files. (Rockwell)(Studio)(Ethernet/IP)

einnh

Lifetime Supporting Member
Join Date
Mar 2014
Location
New England
Posts
275
We have a customer that requires a CISCO network switches by government regulation.

We are using a IE-4000-8GT4G-E industrial network switch. I have the EDS file for the device so I can add it to my Studio 5000 build, however the parameters aren't mapping with descriptions. Is there a way to reverse build the descriptions from the EDS file? It is almost 9000 lines long but would be worth the effort if it is possible.o_Oo_Oo_Oo_Oo_Oo_O

Thank you.

(I have attached the EDS file).
 
As you have found, just because you have a EDS file it doesn't mean that you get any info from the Devicenet.
I am most probable wrong, but from my reading you need to get AB to put the info into Devicenet, they have different license, the basic it picks up the device, thru to giving all input/output data.
Maybe on other forums someone can do reverse engineering back into the software, but unlikely to tell you here.
Poke around in the software you may find the code to enable it, if you have a Device that is showing the info, definitely anything AB will show up somewhere.
 
however the parameters aren't mapping with descriptions.

Can you describe exactly what you mean by that ?

Are you trying to use the Stratix AOIs or faceplates with these Cisco switches ?

Do you mean that the descriptions don't appear at all for the parameters, or that the wrong description appears with each parameter ?

What revision of Studio 5000 are you using ?

In general, Cisco is very tightly coupled with Rockwell with regard to their device integration and provides proper EDS files that function correctly.
 
Avengers Assemble!...

Ken,

I think they're referring to the raw I/O data arrays created under the module-defined data types for input and output data where we see only "module_name:I1.Data[0], etc. for the member names and no descriptions? If so, and as I'm sure you are aware, this is typical for EDS based AOPs. The minimum requirements for an EDS AOP are stipulated by Rockwell and it will not meet the grade if you have not met their targets. But adding actual parameter names for the I/O data type members, or indeed descriptions, is not stipulated and so quite often is not included.

einnh said:
...I can add it to my Studio 5000 build, however the parameters aren't mapping with descriptions. Is there a way to reverse build the descriptions from the EDS file? It is almost 9000 lines long but would be worth the effort if it is possible...

Yes, manually, as you have suggested yourself.

Typically for these EDS AOP files, the device parameters, which are intended to be used for the I/O connection under the module properties, will be grouped into an "Assembly" Object. Depending on whether one or more Assembly Objects are created, there may be more than one Input Assembly available for input data, as is the case here. And there may optionally be an Output Assembly for output data, which there happens to be here.

If we take the default "Control and Status" I/O connection that you see in the module properties. There are 56 bytes of data presented to the software/controller, again whether we choose to display it using SINT, INT, DINT or REAL data type. Optionally, for the input data, there is also another input only connection available - "Status Only for Managed ethernet switch" (Tie me down, they've spelled "Ethernet" with a lowercase "e" and I cannot change it!). This connection presents us with 18 bytes of input only data.

Within the EDS file, we can search for these I/O Assembly Object definitions. To speed this up you can use search terms like "Assembly", or "Assem", but I use a specific method which usually hits the target straight away. Each Assembly lists its "Length in bytes".
So if we use this search term, starting from the top of the text in the EDS file and searching "Down",
we will usually land on the first Assembly Object...

Code:
[Assembly]
        Revision = 1;
        Object_Name = "Assembly Object";
        Object_Class_Code = 0x04;

        Assem1 =
                "[B]Input Data for managed switch[/B]",
                "20 04 24 01 30 03",    $ Path
                [B]18,                     $ Length in bytes[/B]
                0x0000,                 $ descriptor
                ,,                      $ reserved
                16,Param32004,
                32,Param32200,
                32,Param32201,
                32,Param32202,
                32,Param32203;

Here we can see the name of the Assembly is "Input Data for managed switch",
which does not match exactly with either of the two connection names we see available under the module properties.
But, also we can see the Length in bytes is "18",
which we know is the number of bytes listed for the "Status Only for Managed ethernet switch" connection - so that's a hit!

As the Assemblies are all defined under this section in the EDS file,
we can quickly see that the other Assembly Objects we are interested in are just beneath the first...

Code:
Assem191 =
                "[B]Input Data[/B]",
                "20 04 24 65 30 03",    $ Path
                [B]56,                     $ Length in bytes[/B]
                0x0000,                 $ descriptor
                ,,                      $ reserved
                ,Param31013,
                ,Param101,
                ,Param102,
                ,Param103,
                8,Param104,
                8,Param1100,
                8,Param2100,            $  
                8,Param3100,            $  
                8,Param4100,            $  
                8,Param5100,            $  
                8,Param6100,            $  
                8,Param7100,            $  
                8,Param8100,            $  
                8,Param9100,
                8,Param10100,
                8,Param11100,
                8,Param12100,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,           $  
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param27100,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                8,Param40000,
                ,Param31002,
                ,Param31010;

Here we see the name "Input Data", which is relevant but not exactly matching again.
But more importantly, the Length in bytes is "56",
which we know is the number of bytes of input data presented for the connection "Control and Status" - so that's another hit!

Next we see...

Code:
Assem192 =
                "[B]Output Data[/B]",
                "20 04 24 66 30 03",    $ Path
                [B]4,                      $ Length in bytes[/B]
                0x0000,                 $ descriptor
                ,,                      $ reserved
                ,Param105;

Again we see the name "Output Data" which is relevant but not an exact match, but also the Length in bytes is "4",
which we know is the number of bytes of output data presented for the connection "Control and Status" - so that's another hit and our last!

Now that we have the Assembly Objects for the I/O data presented under the module properties,
we can also see which parameters within the EDS file are being grouped into these Assemblies...

If we look above at Assembly 191 (Assem191),
which is the Input Assembly for the 56 bytes of input data,
we can count 21 different parameters listed.
The data for each of these particular parameters is populated in a certain pattern within the 56 bytes of data.
To decide how, we must find each of these parameters in the EDS file under the [Params] section,
and see what Data size in bytes and which data types they use...

Example: Param101

Code:
Param101 =
                0,                      $ reserved, shall equal 0
                6,"20 F6 24 00 30 65",  $ Link Path Size, Link Path
                0x0010,                 $ Descriptor: read only
               [B] 0xD3,                   $ Data Type : DWORD
                4,                      $ Data Size in bytes[/B]
                "[B]Global Link Status[/B]",   $ name
                "",                     $ units
                "[B]on = active, off = not active[/B]",    $ [B]help string[/B]
                0x00000000,0x1000,0,    $ min, max, default data values
                ,,,,                    $ mult, div, base, offset scaling
                ,,,,                    $ mult, div, base, offset links
                ;                       $ decimal places
        Enum101 =
                0,"Link Active any port",
                1,"Link Active on port Gi1/1",
                2,"Link Active on port Gi1/2",
                3,"Link Active on port Gi1/3",
                4,"Link Active on port Gi1/4",
                5,"Link Active on port Gi1/5",
                6,"Link Active on port Gi1/6",
                7,"Link Active on port Gi1/7",
                8,"Link Active on port Gi1/8",
                9,"Link Active on port Gi1/9",
                10,"Link Active on port Gi1/10",
                11,"Link Active on port Gi1/11",
                12,"Link Active on port Gi1/12";

Right, here we can see that the name of the parameter is "Global Link Status". Its data type is "0xD3 DWORD".
As a Double Word, it uses 4 bytes and represents 32 individual bits of data.
The 4 bytes is confirmed on the next line. We can also see the help string "on = active, off = not active".
This can be used to decipher what the status of the value of each of the 32 bits means.
The "Enum101" section is the Enumeration of the bits that are used with the 32 bit data type (only bits 0 - 12 are used).
This also gives us the descriptions for each of these bits that will be members of the input data.
You can describe your input data array member with the name above,
and could also append the help string to further describe the status of the data values.
Then use the "Enum" descriptions to describe the individual bits for the input data in the Controller Tags...

IE_4000_Example_IO_User_Descriptions.jpg


Live, Die, Repeat...

It wouldn't take you "too long" to go through them all if you think it worth it?

EDIT: In my haste to show you an example I had forgotten the example I chose was not the first parameter under "Assem191". The first is "Param31013", which is a "Fault Member" DWORD. This should be described as ...data[0] and not "Param101", as I have shown in my screenshot. You would put "Param101" at the next DINT address - ...data[1].

Sorry about that!

Regards,
George
 
Last edited:
Here, I've fixed that up to save confusion...

IE_4000_Example_IO_User_Descriptions_01.jpg


...but I'm not doing any more for you!! :ROFLMAO:

Note: the Fault Member parameter 31013 is a 32 bit DWORD. This is set all '0' by the switch when the I/O connection is active. If the connection is detected as inactive by the controller, then the controller sets the 32 bits all '1', not the switch. This lets you detect the connection failure at the controller end (DINT = -1). The "Help String" for this parameter explains all this "at length", but I have just abbreviated that information into the description in my screenshot. There is also the default "ConnectionFaulted" member above, which could also be used.

Note also: Forgot to mention, although obvious?, I have chosen DINT for the data type for the I/O Connection ([DINT]14 for input data).

Regards,
George
 
Last edited:
I just wanted to add this additional info on the topic...

As I mentioned, it is not required or expected that developers provide the I/O array members specific names or descriptions of the parameters assigned to the Assemblies when developing an EDS AOP for Rockwell Automation software (RSLogix 5000 / Logix Designer).

From the Logix 5000 Controllers EDS AOP Guidelines for Logix Designer

Logix 5000 Controllers EDS AOP Guidelines for Logix Designer said:
Input and Output data structures and parameters

This section covers defining the module Input and Output data structures and parameters, and how they display in the Logix Designer application.
In the EDS file, the [Assembly] section defines the data structures.
The EDS file details are described later in this document, beginning with the EDS File Sections.

The Input and Output data structures define the parameters whose values are produced by the target module and consumed by the target module.

The Input and Output tags are contained in a single non-descriptive array of type SINT, INT, DINT or REAL.

In the EDS file, define a detailed assembly or a non-detailed assembly.

Both detailed and non-detailed assemblies only define the size of the assembly, and result in a non-detailed data type.

This is why EDS AOPs will normally just use the generic name "Data" for the data members within the module-defined I/O data types (...:I1.Data, ...:O1.Data) It's quick and easy.

Regards,
George
 
Geospark. I'm walking through this now. Do you have Venmo? I'd love to send you a 'tip' haha!
 
If you will be using this switch in other projects, you can use the info provided by George to read the EDS, but then make a UDT with more descriptive tags for each parameter, as well as their descriptions. Then COP the module .data[0] to your UDT. Then you don't have to redo the tag descriptions every time you use that switch.

Pages 13-19 of the document here give an example of how to do this:
https://www.watlow.com/-/media/documents/white-papers/ruigtw.ashx
 
Last edited:
Here, I've fixed that up to save confusion...

Regards,
George

You changed the data types in the file definition?

Mine all show up as SINTs by default.

Would SINT [0] - [3] relate to Parameter31013 as it is 4 Bytes long?

2019-10-01 16_48_00-Clipboard.png
 
Last edited:
einnh said:
You changed the data types in the file definition?...

I changed the data type in the module properties under the General tab via the Change button. This is where you view/edit the I/O connections made available by the device Assembly Objects. If you're not familiar, the fields in there can often appear read-only. If you play around with your mouse you should see a drop-down menu is available for some of the fields, including where the default SINT data type is listed. Changing the data type for the I/O connection in the project makes no difference to the data being exchanged with the device. 56 bytes of data will be read in, no matter which data type you choose. The option is more so you can arrange the data in a format that suits you or the application of the data.

I just chose DINT as it most clearly displayed the example parameter data I was trying to show you. If the majority of the data looked better as say SINT, then I would probably leave it as such. But it usually wouldn't matter too much because...

Often the default SINT data type is just left as is and the raw input data in bytes is mapped (copied) to meaningful tag structures, such as the UDTs that Incandenza is advising. Or for output data, the UDT data is mapped back to the raw SINT data type. This is pretty much standard practice. I do like to have descriptions on the base I/O tags as well though, but only when possible or not a crazy amount of work. Even though the EDS file for this switch is huge, the amount of data you want to "parse" out is not really in the realms of "crazy". Another reason I like to have the descriptions on the base I/O tags is for when I go to map the data. It's much clearer when deciding what needs to go where.

Pre-defined UDTs are a good idea here, and widely used, but another method is to supercharge the UDTs by using them with an Add-On Instruction (AOI). Here you "can" the logic for the mapping for the specific module inside the AOI, while using the UDTs for the data structures. As I believe many Cisco switches use the same EDS file, there is now also the option to generically reference whichever module-defined data type we want using the MODULE data type. But that is for (& in) another thread.

einnh said:
...Would SINT [0] - [3] relate to Parameter31013 as it is 4 Bytes long?

Exactly. Just use each parameter's number of bytes to advance your way through 56 bytes of input data. If you haven't reached or at least viewed "Param40000" yet, you will notice it is called out in the EDS file as a "pad byte". That's why you see so many instances of it listed in the Assembly. The 56 bytes is a default size for the Input Assembly Object. As this is only a 12 port model switch, the full Assembly of Status data is not required. So it is padded out to "plug the port holes" (pardon the switch pun).

Regards,
George
 
Hi George, another great tutorial you have supplied.
My bad, l thought the op was after getting the data displayed on RSNetworx for Devicenet, (not Ethernet/IP) were it would show I/O descriptions and live data for the modules connected, not EDS data into tags in 5000
Do you have an example how to change EDS files so they can show in RSNetworx?? pretty please. If you can, l will open a new thread, a Beckhoff, BK5220 Devicenet Scanner would be great.
 
Name your price, or price your Name?...

duckman said:
Hi George, another great tutorial you have supplied.
My bad, l thought the op was after getting the data displayed on RSNetworx for Devicenet, (not Ethernet/IP) were it would show I/O descriptions and live data for the modules connected, not EDS data into tags in 5000
Do you have an example how to change EDS files so they can show in RSNetworx?? pretty please. If you can, l will open a new thread, a Beckhoff, BK5220 Devicenet Scanner would be great.

Hi duckman, or should I call you "PLCnovice61"??? If that is also you then I had no clue! (I'll come back to your DeviceNet question at a later date...)

More to add on the subject...

I had noticed (your?) post #3 was making incorrect references to DeviceNet, even though the OP title had "Ethernet/IP" in it. So I could have quickly dismissed all the information included in it. But, and even though there "seemed" to be some rambling going on about needing licenses or something?, it did trigger a vague recollection I had on another aspect of what I was explaining above. Maybe you meant the following by those comments, or maybe you meant something different, but either way, thank you...

While I am describing the lack of descriptions, or indeed names for the raw I/O tags created from such devices using EDS-based AOPs, and how it is not generally requested by Rockwell to include such details, it actually can be requested to be included by a Vendor if they so choose to...

1061418 - EDS AOP does not create named tags
Access Level: Everyone

Rockwell Automation said:
In order for Logix to display named tags, the EDS file needs to include a license key. These are issued by RA Technologies Inc. on a case-by-case basis.

That is "named tags", and not necessarily "descriptive tags". The I/O tags will have specific names included in the module-defined data types, referencing the parameters they belong to, but they will still usually have no descriptions. Unless the Vendor adds descriptions to the members in their data types, but that generally is not done. I think the consensus is to leave the "Description" field entirely at the end user's discretion?

I had completely forgotten about this until I had read your little "license" prompt the other day. Once a Vendor is issued a Rockwell license key for their product's EDS AOP file, they must then define the I/O Assembly and parameter structures in line with the atomic data types supported in a Logix 5000 project. Also note, the project must be v20 or higher to support EDS AOPs. So instead of seeing a variety of data types like Unsigned 8-bit integer, USINT, Type Code 0xC6, all being read in raw byte format, the Vendor must now present all parameter data using Logix 5000 supported data types such as the following elementary examples...

Signed 32-bit integer, DINT, Type Code 0xC4
Signed 16-bit integer, INT, Type Code 0xC3
Signed 8-bit integer, SINT, Type Code 0xC2
Boolean, BOOL, Type Code 0xC1

Or the Vendor can create structured module-defined data types containing these elementary data types, or arrays of elementary data types, and so on. But these structured data types must be designed in keeping with the supported Logix 5000 structures and all adhere to the byte boundary alignment rules. They must also, of course, update the firmware in the device so that it processes the I/O data using the Logix 5000 data types or structures. Only then will their nice new module-defined data type member names be permitted.

If only more would do it? It's a right pain when you have larger I/O data arrays to map to meaningful tags and it all looks a "blank".

"What do you mean I'll have to read the manual?"

I have no idea of how much Rockwell charge for this "service" though?
They probably charge you more for Capital letter$!?

Regards,
George
 
Hi George guilty as charged re name. 2 different computers, 1 which didn't have original name and couldn't be found so needed another.
We are currently using RS5000 V15 which will be upgraded at some stage, l wasn't aware of requiring V20 to get Devicenet tags/ AOP, so that will be an advantage.
Yes l was talking about the AB license requirement to get the data into RSNetworX, which as you stated, the stumbling block would be it wouldn't be done for free. It certainly makes life easier when it is available.

I can now see how via another one of your great tutorials, how it can be done in RS5000 V20+, but do you think IO/descriptions can be added to RSNetworx?
 

Similar Topics

To quickly test a plc output which is wired to a relay do I dob a cable between the output and 24vdc+ source I.e something with 24vdc+ live such...
Replies
6
Views
680
Hi there, I am trying to determine the input, output, and config assembly and entering it into a beckhoff plc, and couldn''t get proper active...
Replies
22
Views
7,320
Hello everyone‚ Fairly new to PLC prog I seek your advise concerning what is said in my thread title; I program using workbench components; I...
Replies
1
Views
1,247
Dear Sirs, I have several Siemens MasterDrives (of dubious parentage) and I'm not sure if they are operational or not. I have an old laptop...
Replies
9
Views
2,787
I need to increase a servo motor's ability to hold a load in place when work is being performed against it. This project is in a metal forming...
Replies
0
Views
1,395
Back
Top Bottom