Universal Robots+

Ethernet IP EDS-File Outdated/wrong


i tried to communicate via Ethernet IP with a Schneider PLC.

The EDS-File from the following link is outdated or wrong:

In the Output Assembly of the PLC there are 3 unused Bytes, that are not in the Input Assembly of the robot. The following error is that all following Variables/Date is affected.
By editing the Assembly on the PLC Side (move the 3 Bytes to the End of the assembly) I got it working.

If you use Schneider PLC you need to swap Bytes (Big/Little Endian) in Addition.

Please create a new, working EDS-File.

Best Regards,
Alexander Apostolidis

have some one a solution for this problem? I use the robot software an a CodeSys system. I need the actual TCP and TCP speed in PLC. I want to use Ethernet IP to get this Information or is there a better solution? I think with RTDE it is to complicate to get the information to codesys.

When i scan my Ethernet IP network i found the robot but i think the EDS file from HowTo ist wrong.

Thank you for solutions and ideas


Just move These 3 Bytes to the end of the Assembly.

As you are in Codesys you also Need to Converter from the endianess?:



I’ve see it some times ago, without reporting.

Yes the file is wrong and the 3 bytes should be removes not to be put at the end: delete the line 2859 in the EDS file (where you can see 24, $pad).

Endianess is given by the protocol specification Volume 1 (definition 1.7.30 indeed !):
The native CIP data types are sent in little endian order
and paragraphe “C-5 CIP Application Transfer Syntax: Compact Encoding”

and that’s we can see with wireshark during UR exchanges. Strange you’ve got problem with a Schneider device.


Hi UR team,

In the EDS file the param501 is type 0xD3 (DWORD). So if a tool (like Schneider one it seems) got the size from it, the output assembly is wrong because 3 bytes are added with pad.

If a tool is just looking the output assembly description it can seen this param501 is given with a 8bits size. So for a tool working with it it’s OK because the 3 bytes pads are OK.

option 1:

        Param501 =
            0,                      $ reserved, shall equal 0
            ,,                      $ Link Path Size, Link Path
            0x0200,                 $ Descriptor
            0xD1,                   $ Data Type  <---------changed
            1,                      $ Data Size in bytes  <---------- changed
            "RobotBits",            $ name

option 2 :

        Assem2 =
            "Output Assembly",
            "20 04 24 70 30 03",
            $ ROBOT
            32,Param501,    $ <--------- changed


1 Like

Thank you for your solutions but it doesn’t work for me. I have modify the eds file. Delete line 2859 and change the Param501 type to 0xD1 and size to 1. I don’t make any changes to endianees. But I think the communication should work unheeded the endianees only the interpreation of data gets wrong? I don’t have that much experience with DeviceNet.

Do you have any ideas?


EDS modification : option 1 or option 2, not both.

gives Robot_Bits : 4 bytes without padding or Robot_Bits 8 bytes + 3 bytes padding.


Yes I think I do i the right way here the 2 relevant extracts from my EDS

 >    Param501 =
>         0,                      $ reserved, shall equal 0
>         ,,                      $ Link Path Size, Link Path
>         0x0200,                 $ Descriptor
>         0xD3,                   $ Data Type
>         4,                      $ Data Size in bytes
>         "RobotBits",            $ name
>         "",                     $ units
>         "",                     $ help string
>         ,,0,                    $ min, max, default data values
>         ,,,,                    $ mult, div, base, offset scaling
>         ,,,,                    $ mult, div, base, offset links
>         ;  


           "Output Assembly",
            "20 04 24 70 30 03",
            $ ROBOT
            $ Outputs

Thats how i understod your post, thats right?


I’m not quiet sure if i had also test option 1 without deleting line 2859. I’ll check this tomorrow

The EDS extracts here do not match the 1.png screenshot where the first field is 1 byte followed by Speed_Slider_Fraction : 3 bytes padding are missing … or DWORD for the first field.

Hey frederic,
sorry you are right th screenshot shows a wrong EDS config. I now check the option 1 and 2 a second time. but it also doesn’t work for me.Maybe in the robot Version there are other changes in DeviceNet specification from UR? I could also imagine that my PLC system make a fault maybe with cycle time. But when i scan for the Robot i found it. See the screenshot in my first post.