# Hard braking when using moveP

**URL:** <https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969>\
**Category:** Technical Questions\
**Created:** [March 16, 2021, 10:47am UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969 "2021-03-16T10:47:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nik](https://avatars.discourse-cdn.com/v4/letter/n/6de8d8/32.png) [@nik](https://forum.universal-robots.com/u/nik)\
**Post date:** [March 16, 2021, 10:47am UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969/1 "2021-03-16T10:47:23Z")

</div>

Hey guys,

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.

I’d be happy to hear some suggestions.

---

<div class="post-metadata">

**Author:** ![hi11](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/hi11/32/2179_2.png) [@hi11](https://forum.universal-robots.com/u/hi11)\
**Post date:** [March 16, 2021, 11:45am UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969/2 "2021-03-16T11:45:53Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nik](https://avatars.discourse-cdn.com/v4/letter/n/6de8d8/32.png) [@nik](https://forum.universal-robots.com/u/nik)\
**Post date:** [March 16, 2021, 1:25pm UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969/3 "2021-03-16T13:25:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mbush](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mbush/32/76_2.png) [@mbush](https://forum.universal-robots.com/u/mbush)\
**Post date:** [March 16, 2021, 1:52pm UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969/4 "2021-03-16T13:52:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sam.verity-hilton](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/sam.verity-hilton/32/6046_2.png) [@sam.verity-hilton](https://forum.universal-robots.com/u/sam.verity-hilton)\
**Post date:** [March 16, 2021, 3:07pm UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969/5 "2021-03-16T15:07:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![m.birkholz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/m.birkholz/32/7084_2.png) [@m.birkholz](https://forum.universal-robots.com/u/m.birkholz)\
**Post date:** [March 17, 2021, 7:33am UTC](https://forum.universal-robots.com/t/hard-braking-when-using-movep/12969/7 "2021-03-17T07:33:31Z")

</div>

Hi,

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 😉
