ErrorPending Bit in RA Status Word

[Thorbot]

Hello community,

I’ve been searching for a solution to the following issue for weeks:

When the robot starts, it reports the TelegramState READY_FOR_INITIALIZATION (254),
and the interface can be initialized via the RobotTask function block. Commands can be executed – including the EnableRobot command.

However, if the PLC is restarted, the Profinet connection is interrupted, or any other event occurs that affects the TelegramState,
the robot reports an error, such as ERROR_173. This error can be acknowledged using ACK_ERROR (4) in the TelegramControl,
after which the robot transitions to READY_FOR_RESUME (253). Sending RESUME (2) in the TelegramControl then changes the TelegramState to INITIALIZED (255).

The RobotTask runs through without issues and reaches the status Initialized. Commands can again be executed –
but the EnableRobot command fails with error 16#8F15, and the message log shows 16#048C0000: 'Active error prohibits enable command.'

In the RA Status Word, the ErrorPending bit is set to TRUE.
I tried acknowledging it using a GroupReset, but the ErrorPending bit stays TRUE.

I’ve tried many different approaches, like using the TelegramControl RESET(3) instead of RESUME(2) or explicit causing a LifeSignTimeout to reset the RI on robot side - but haven’t found a way to acknowledge or clear this ErrorPending state. Only a reboot of the robot helps.

This problem only occurs with Yaskawa robots – everything works fine with my Jaka robot.

Just to avoid misunderstandings - I am using my own SRCI implementation with Beckhoff / Codesys PLC

With a Siemens PLC you can enable the Yaskawa robot again, without having to restart it,
so there must be some magic to acknowledge this ErrorPending bit.



Thanks in advance !

[Thorbot]

Hello community,

I’ve been searching for a solution to the following issue for weeks:

When the robot starts, it reports the TelegramState READY_FOR_INITIALIZATION (254),
and the interface can be initialized via the RobotTask function block. Commands can be executed – including the EnableRobot command.

However, if the PLC is restarted, the Profinet connection is interrupted, or any other event occurs that affects the TelegramState,
the robot reports an error, such as ERROR_173. This error can be acknowledged using ACK_ERROR (4) in the TelegramControl,
after which the robot transitions to READY_FOR_RESUME (253). Sending RESUME (2) in the TelegramControl then changes the TelegramState to INITIALIZED (255).

The RobotTask runs through without issues and reaches the status Initialized. Commands can again be executed –
but the EnableRobot command fails with error 16#8F15, and the message log shows 16#048C0000: 'Active error prohibits enable command.'

In the RA Status Word, the ErrorPending bit is set to TRUE.
I tried acknowledging it using a GroupReset, but the ErrorPending bit stays TRUE.

I’ve tried many different approaches, like using the TelegramControl RESET(3) instead of RESUME(2) or explicit causing a LifeSignTimeout to reset the RI on robot side - but haven’t found a way to acknowledge or clear this ErrorPending state. Only a reboot of the robot helps.

This problem only occurs with Yaskawa robots – everything works fine with my Jaka robot.

Just to avoid misunderstandings - I am using my own SRCI implementation with Beckhoff / Codesys PLC

With a Siemens PLC you can enable the Yaskawa robot again, without having to restart it,
so there must be some magic to acknowledge this ErrorPending bit.



Thanks in advance !

Thanks to a tip from Yaskawa, I was finally able to solve the problem!

Yaskawa prohibits enabling the robot arm power if there are still unacknowledged errors in the message log that haven't been transmitted to the PLC yet. With this information, I was able to identify a bug in my implementation related to the acknowledgment of retrieved message logs using the ReadMessages function block.

However, that still wasn’t the final piece of the puzzle. While analyzing the response payload, I noticed what seems to be a small mistake in the SRCI Specification V1.3: it appears that the "Enabled" and "MsgID" bytes are swapped.

According to the spec:
Byte 4 = Enabled
Byte 5 = MsgID

In reality:
Byte 4 = MsgID
Byte 5 = Enabled

( Table 6-108: Received CMD payload (RC to PLC) of "ReadMessages" )

This is probably already corrected in the upcoming version 1.5 of the specification ?

Anyway – I’m just super happy that I was able to fix this bug finally!