EtherCAT F/T Sensor Data Interpreted as Unsigned in KUKA Controller

    Hi everyone,

    I'm currently working on integrating an ATI Axia80-M20 Force/Torque sensor with a KUKA sunrise cabinet (iiwa 14 r820) via EtherCAT. The connection is up and running, and data is being received. However, I'm facing an issue with how the sensor data is being interpreted on the KUKA side.

    According to ATI's documentation (and also verified in the ESI file), the force and torque outputs—Fx, Fy, Fz, Tx, Ty, Tz—are mapped as DINT (32-bit signed integers).

    But on the KUKA controller, these values are being shown as UDINT (unsigned 32-bit integers). As a result, any negative force or torque value appears as a very large positive number, which completely breaks the logic in my control program (e.g., for a touch-stop condition based on force thresholds).

    I’ve checked my workvisual project, and everything looks correctly configured. But I still have no idea why it happens.

    Any advice or shared experience would be greatly appreciated!

    Thanks in advance,
    Sean

    Edited once, last by Doubtet (April 10, 2025 at 6:44 PM).

  • Lemster68 April 10, 2025 at 6:36 PM

    Approved the thread.
    • New
    Quote from MOM

    Did you checked with the ATI documentations found here https://www.atiia.com/products/ft/ft…x?id=Axia80-M20

    And here 9620-05-D-ATI KUKA FTCtrl (ati-ia.com)

    In your case you are only showing the counts and not the forces and torques

    i have checked the ati sensor manual before. Actually, ithe ouput value is 32-bit F/T
    result data in counts per unit. And I think I may have found the reason why the value displayed on the controller pad appears as an unsigned number. For example, when I set the I/O mapping for the force component Fz, it was configured as a DINT, which is a 32-bit integer. However, when I exported the I/O configuration into the Sunrise project, it seems that the Sunrise cabinet defaults to reading the data as a 64-bit value (long type). When a 32-bit unsigned integer is extended to 64 bits, it is zero-extended, meaning zeros are added to the higher bits. As a result, the most significant bit remains 0, so the value can never be interpreted as negative and is always treated as unsigned.

Advertising from our partners