search

Yaskawa-Global / motoros2

ROS 2 (rcl, rclc & micro-ROS) node for MotoPlus-compatible Yaskawa Motoman robot controllers
101 stars 21 forks source link

Need to clearly indicate failure when configuring speed FB #305

Open ted-miller opened 2 months ago

ted-miller commented 2 months ago

We had a user get into this scenario. But he reports that he never saw the alarm, 8001 Speed FB enabled, reboot now. [10]

https://github.com/Yaskawa-Global/motoros2/discussions/294#discussioncomment-10595168

This results in MR2 appearing to freeze at startup and communication dropping to the agent.

The only way that I know it occurred was by looking through the alarm history.

I too believe that I have seen this scenario, but I just brushed it off and assumed that I wasn't paying attention.

We need to try to reproduce with a "clean" robot controller that has FSU enabled.

ted-miller commented 2 months ago

And assuming that we can reproduce, add some debug messaging to indicate what's wrong.

gavanderhoorn commented 2 months ago

Isn't that all part of GP_getFeedbackSpeedMRegisterAddresses(..) (called here)?

ted-miller commented 2 months ago

Yes. If S1CxG0335 is not set, then GP_getFeedbackSpeedMRegisterAddresses will attempt to directly modify the SC.PRM file in the controller. After that modification, it raises an alarm and sits in an infinite (blocking) loop to force the user to reboot.

But... a) The user didn't see the alarm. Don't know why... b) Since the FSU CRC-check was enabled, the modification to SC.PRM was never accepted. So MR2 gets stuck in the bootup routine.

If the pendant isn't properly displaying the alarm, then I don't know that we'll be able to fix that directly. (Will need to report to Japan.) But we can ensure that the debug message gets reported in a way that is visible to the user.

Alternatively (or additionally), we can modify the setup instructions to have users manually enable the speed-feedback parameters.

gavanderhoorn commented 2 months ago

What about extending GP_getFeedbackSpeedMRegisterAddresses(..) to not

attempt to directly modify the SC.PRM file in the controller. After that modification, it raises an alarm and sits in an infinite (blocking) loop to force the user to reboot.

but instead just return an error? That can then be forwarded / reported to the user in the normal way.

Since the FSU CRC-check was enabled, the modification to SC.PRM was never accepted. So MR2 gets stuck in the bootup routine.

is there a way to detect the FSU is enabled? If there is, we can report that as well.

Alternatively (or additionally), we can modify the setup instructions to have users manually enable the speed-feedback parameters.

I'd really only do that as a last resort. There's quite a few parameters, especially when you have multiple axes.