we’re currently trying to use the robot in a dispensing application. It is clear, that we have to use moveP for all movements where the robot is dispensing since we want constant speed at the TCP. The issue we’ve now ran into is that after moveP movement the robot stops abruptly other than having a regulated deceleration.
The only thing that kind of solves the problem is lowering the acceleration, that however is no really an option since that would interfere with the beginning of the whole dispensing process.
What I want to the after the stop (deceleration) is to moveL upwards the Z-Axis.
There are a couple of things I’ve already tried which did not solve the problem such as using “Direction Z” or a Waypoint to the same direction. I’ve used different values of blending, basically trying to go with a blend as low as possible up to the couple millimeters and lastly a simple wait after the movement, which, independently from the time didn’t fix the issue.
We had a similar application and hit the same issue, if I recall correctly (no bot around to confirm sorry) a Wait directly after the MoveP was causing it to abruptly stop, we had to go from a MoveP to a MoveL first to decelerate and then could Wait. I might be wrong though, but this is an easy check.
Not sure if this is what you meant put I put a moveL on the same waypoint as the moveP and put it right below the moveP in the program. That solved the problem. Thank you very much.
MoveP does not have deceleration since it moves at a constant speed. You can either add a movel to the end as recommended above or use a stopl command following the movep. I think the other issue is unless you do something at the end the movep is going to blended points as well and so may not abruptly stop at the actual end point without either a movel or stopl added.
When we train people in Universal robots, we often tell people to use a stopl() at the end of a MoveP, asthis will maintain linear motion whilst bringing the robot to a more controlled stop, I would recomend adding this as a script line at the end of any MovePs that come to an abrupt stop. You will have to add it as a script node, reference the script manualfor teh arguments that stopl()takes.
the real Problem is that MoveP is the only Move Type that guarantees the configured Speed at the TCP. I can’t relate other robots that have similar Issues with that Type of Move e.g. ABB for LIN.
So, there should be a move Type that guarantees the TCP Speed and does not have that weird behavior. Why does it even need blends or has that stopping issues?
I made my own Linear Move Type to solve these Issues in Addition. To do so, you need to use interpolate_pose between your waypoints and slice them into intervals (like 1 mm distance each) and move to each interval with servoj. This way, the robots keeps the configured speed at the tcp
