Today I am posting here because I encountered a really weird Protective Stop (PS) that I am not able to fully understand. The PS code that I get is the C204A6:5 and it appears when I try to blend 2
movels with a continuous force threshold check (lets call it
What is particular about this PS is that it is really hard to reproduce, even when I execute the same trajectory followed by the UR10 when it stopped for the first time.
First, let me explain you how my
movel_with_force_check works: At a URscript level, whenever I request this move, I create a new thread that executes the motion separately.
movel(thread_pose, a=thread_acc, v=thread_vel, r=thread_blend_radius)
thread_flag = 1
# I add a stopl command with a low acceleration to avoid finishing
# the time frame with no command.
In the main thread I check continuously the force reading and if the threshold is exceeded, I kill the
motion_thread and execute a
stopl(10.0) command to abort the motion. Contrarily, if the move returns naturally and no force is detected, I proceed with the next motion command.
I’ve been blending simple
movej combinations with no problems so far, but when I try to blend two
movel_with_force_check the PS sometimes prompts when the robot enters C’s blending radius. A simple representation of the trajectory would look like this:
I don’t fully understand how the driver computes the velocity and acceleration when the robot enters and leaves the blending radius. Nevertheless, I tried to use a “big” radius to play it safe. I also choose B and C positions carefully to avoid overlapping radiuses.
Could performing the motion in a separate thread somehow induce this issue? I read that the thread scheduling in the UR is done in a round robin fashion and that it is not possible to control it. I already detected that sometimes, when the
movel finished naturally and the given thread was scheduled last in a time frame, the robot ended up in motion with no following move command. This produced a sudden deceleration that sometimes ended up in PS.
Has someone ever experienced something similar? Or does anyone knows if there is any recommended value for the distance between blending radiuses?
One last thing, anyone knows what is the number printed after the PS code? In this case 5 (from C204A6:5)?
Thanks for all your time and attention! I look forward to read your replies.
i’m having similar issues with small distances between blending radiuses too. as a workaround i used the point_dist function in calculated waypoints to avoid this error if the distance is smaller than 50 mm but i don’t know the exact minimum range
A colleague recently published a great paper that discusses Joint speeds, Blending, Speed profiles with and without blending, and discusses optimizing robot acceleration. It may be worth a look over to see if it could clear up some of these points: Robot theory and how to use it in UR robots