The first 8 messages in the EDS Import Message Center are just stating that the 8-bit signed data type from the file (various parameters) is being converted to an 8-bit unsigned data type for compatibility with the PSeries data types. PSeries does not have an 8-bit signed data type option.

Line 730 shows that the Interroll device uses a 32-bit Run/Idle header in the T->O direction. Meaning, the target device is sending these extra for bytes along with the Input Data. The PSeries has the option to enable or disable the Run/Idle Header in the O->T direction (based on whether the target needs it or not), but does not support this format (or the extra bytes) in the T->O direction. I would check to see if this is something that can be disabled in the Interroll device.

So for the first 8 messages, it seems that '0xC2' means 8 bit signed in, can I simply change the datatype to signed 16 int? How can I find the hex value for that?

If I was able to disable what you are talking about in the Interroll device, the EDS file will still not work in the Productivity...

Do you know what the [Port] section means? I have a working EDS file for UR robots and this section looks the same except for the last number being a 2 in the Interroll file and a 1 in the UR file. Do you know what this number means?

Maybe I can get this working without an EDS file (using Generic Client).

Interroll have a document that is just too large to attach to this forum here:

https://www.interroll.com/products-solutions/product/multicontrol-bi/ -> Software -> Download

Not exactly sure how to configure it though...

Regarding the 8-bit signed versus the 8-bit unsigned conversion, I am not suggesting that you change anything. The EDS import is doing this for you. The software is just letting you know that the data type is changing in order to be compatible. Think of it an an 'FYI.'

Regarding the 32-bit Run/Idle Header in the T->O direction, you are correct. Even if you can disable this in the device, the EDS file would not reflect this. However, if it turns out that you can disable this, I can guide you in the required modification of the EDS file, in order to get you moving forward.

Also...

The hex values associated with the data types in the EDS file are outlined as part of the CIP specification. The CIP specification is a purchased and licensed document, but you may be able to find a table showing these on the internet.

And if I cant disable the '32-bit Run/Idle Header in the T->O direction' does that mean I cannot talk with this device or is it possible to use the generic client?

I have been trying to use the generic client and their document but I feel like this is different than other Ethernet/IP communications that I have done in the past. I am used to their being a input block and an output block (and maybe a configuration block) but it seems Interroll don't do things this way???

There really isn't a difference in communication when using an EDS file or using a Generic Client. The difference is simply how the parameter settings get populated; manually entered or read from a file.

Based on the EDS file, it appears that the Output Data block is Assembly Instance 100 and holds 10 bytes of data. The Input Data block is Assembly Instance 101 and hold 36 bytes of data.

If the device truly requires the 32-bit Run/Idle Header in the T->O connection, then 'Implicit' communication is not going to be an option. The alternative would be to use 'Explicit' communication. This would be my approach when testing.