Joint fault during servoj loop

When I submit the following program to a UR3e, the robot immediately breaks due to a joint fault:

def turn_slowly():
    current_angles = get_actual_joint_positions()
    time_step = 0
    total_time_steps = 100
    while (time_step < total_time_steps):
        current_angles[5] = current_angles[5] + 0.001
        servoj(current_angles, 0, 0, t=0.002, lookahead_time=0.100, gain=200)
        sync()
        time_step = time_step + 1
    end  # end of while loop
end  # end of function

There is a photo of the most recent error screen at the bottom of this post. Note that different joint faults of the same general type occur when I repeat the experiment.

I get extremely forceful motions followed by emergency stops, whenever I try to start a loop controlling the robot in real time with servoj. The function above is the smallest non-working example I could come up with to illustrate the issue.

Why is this happening, and how can I fix it?

It turns out this is because t=0.002 is a far too small value for this function argument. Something like t=0.2 is much safer, even if the previous servoj command is superseded by a new servoj command send just a few milliseconds later.

I had chosen t=0.002 on the false understanding that this argument governs how long this function call will block the program before it moves on to the next iteration of the loop. This misunderstanding was partly due to the wording in the URScript manual:

t=0.008 time where the command is controlling the robot. The function is blocking for t = 0.008 time t [S].

In fact, the servoj command is not blocking. The t argument instead appears to be a kind of shape parameter, which modulates the curve that the robot plans to follow over the course of the next t seconds (terminating in the target joint configuration q).

When t is large, the robot can reach a relatively faraway pose with a moderately paced motion within the allotted time horizon. If t is set to an extremely small value, the only plan that will reach the target within t seconds is an extremely fast motion.

So the solution to my problem is to pick much higher values for t. This allows the robot to think that it has ample time to reach the target joint configuration within its time horizon. This results in smooth motions even if in reality, we keep changing the target before the robot ever gets anywhere near its time horizon.