We have sold some torque force sensors recently and the client experimented with the RobotIQ – Demo_Force_twist_release program. He found that the force feedback works great and the program performs well.

 He did have a problem with the speed though: Whenever he increased the (Speed_inc) variable for axis 6 only (or wrist 3 in the UR world) to greater than 0.33 the robot would trip with error

C204A3: Sudden stop detected

 Now we are guessing that we are breaking one of the speed or acceleration rules, we would just like some clarity on the meaning of the value 0.33 and if there was anything else ( within the demo program) that we could do to increase the speed of that motion.

Thanks Hennie

@Hennie  I have run into this problem in a more general way.  If you have a loop with some robot movement (speed, force, or waypoints) and that loop has a constantly monitored exit condition (or just a short loop time) you will see this error after surpassing a certain speed.

Basically what happens is that the robot will  still physically be in motion after the loop exits, and depending on the next command the joints will have no movement parameters from the controller and will try to immediately stop.  This causes either the error you are seeing (sudden stop) or another error that says "invalid set point."

There are two ways around this:  Slow the movement down if acceptable, or add a "stopl(a)" command right after the loop.  stopl(a) [or stopj(a)]  is a command that sends a command to decelerate the robot at value "a."  stopl() is for linear stop, and stopj() is for decelerating in joint space, and units will be m/s/s or rad/s/s respectively.  The stop command will still only work up to a certain limit though, and requires some trial and error.

@JeanPhilippe_Jobin @Alexandre_Pare   Can you offer any other advice?

@Grady_Turner @Hennie
Grady I think you are right. @JeanPhilippe_Jobin will be able to elaborate more on the speed_inc variable. 
I saw some error with loops once that I think was also related to this. When I hit play, if the loop has no delays in it or position speeds are too fast I get an infinite loop error and the program won't run. I think it is the same things as what you are saying. Have you seen that before?

@Alexandre_Pare I meant that the error occurs when the loop's exit condition is met, and then the robot has no physical movement command and so tries to stop with immediately.

I've run into this issue, using the if with check expression continuously, monitoring Mz to check clockwise and counterclockwise force.  But the error shows up not on that move, but on the gripper open afterwards, even with adding a wait between the move and the gripper open.  Is the situation the same in this instance, or could there be a weird scenario with this setup?

@bsawlor  You may be having too much force twisted up in the arm and so when you release the gripper the arm suddenly moves (you probably can't see this) causing an unexpected motion.  Try placing the gripper opening inside of a force wizard node.  Use the frame type with tool as the frame of reference.  Then allow the Z rotation to be compliant.  I would start with a low rotational velocity like 10 degrees/second and work up as needed to eliminate the fault.  This will allow the arm to float when you open the gripper and should stop the fault.

If you need any help around implementing this let me know and I can do a sample program

Tried inserting the force with the gripper as indicated, now instead of stopping on the gripper action, it stops on the wait that is still present above the force command.  As the part this test is on is plastic, I have the range for the force on the if statements set with minimum change triggering the next command, so I highly doubt the forces it's detecting are too high.  The other thing is, I test by applying pressure on the gripper as it rotates to simulate it hitting the physical limit of the part, so I can iron out the specifics before introducing the part to the gripper.  It's representative but should still work.  Both with the part, and using my fingers, the same error pops up, even though it's reacting for the force detection as it should.

@bsawlor  Have you tried taking the wait out?  Can you send a screenshot of your program?

@bsawlor the only thing that I see in your code that is different from what we do on a daily basis is the else statement attached to each of the continuos if statements, we just use the if with the check box checked for motion.  The other thing that we usually do differently and I cannot see it mattering is we have the if statement inside the movej so that only a waypoint is inside there and maybe a flag so that we know whether we made the point or exited early such as 

global didWeMakeThePoint = False
movej
  waypointBeforeMyForceControlledOne
  while Mz <.2 # The if statement with the checkbox checked effectively becomes a while statement
    waypoint
    didWeMakeThePoint = True
  end
 open gripper

  
At this point I will usually evaluate whether we made it or not, depending on the task, to determine what my next step is.  If all I am doing is using this as a search method then I don't care but if its trying to insert something without faulting on overload then I will use this to know whether the part was inserted for example

I did manage to get past the error, by using the stopj command to stop the movement after it detected the moment.

Im going to have to remember to use the stopj more often, occasionally we have issues with some of our weird moves that we are making.

Glad you were able to get it running @bsawlor