We have implemented a motion which uses force_mode and rotation of a wrist using speedj where we’re performing an operation to screw a plastic part.
Our system has the ability to go into safeguard_stop.
Our requirement was that if safeguard stop occurs, we want to mark that part for rejection and just pick a new one and move on after the safeguard_stop is removed.
The force mode is configured to push at a low force in the Z axis.
What happened when we were trying to test things out. After we resumed from safeguard stop testing it looked like the force mode did not work correctly. It looked like the procedure to issue the force mode downward Z push has been executed, but the robot remained in the same spot and the wrist rotated in space …
We eventually ended up shutting the system down, rebooting things and eventually it works again.
I’m wondering is it somewhere documented if there is any effect of safeguard_stop on the operation of force_mode that would explain this? Is there a sequence of steps we should perform that would ensure we can recover?
Yes the sensor was pushing against something before entering safeguard stop.
What ended up happening was a bug in my software in the end. And the issue was not if force_mode.
I had code that exited a monitoring loop if a certain value of torque was reached during my screwdriving operation.
What had happened is that after the safeguard_stop was issued, the wrist of the robot stopped rotating entirely, so the software timed out never reaching the desired torque… and due to a side effect assigned the value of force_mode to 0 in the Z axis on the next retry. ( nothing to do with the UR Software , but an exception in a code running on my supervisory windows computer which resulted in feeding the wrong value of Z force)
The solution was to more gracefully handle that timeout within my own software stack once timeout happens.