• With KRC4 KSS8.2.27, is there a difference in the smoothness of movement if you end a ptp movement in the 'normal' way at its end point, compared to executing a brake statement in an interrupt routine?
    I know the point of standstill will be different, but I am interested in the deceleration rate for a normal endpoint of ptp movement and a brake during movement.

  • Place your Ad here!
  • Hm... I'm not entirely certain. The BRAKE command definitely causes a path-controlled stop (i.e., not a "panic" stop), but I'm not sure what specs it applies. If I had to hazard a guess, I'd say it either uses the Default decel values, or the currently active Decel values for the motion that's being interrupted. The manual just says it's "the same as when using the Stop button," but doesn't specify any actual numbers.

    Now, the BRAKE F command performs a "faster" stop, but it's still path-controlled -- the manual simply says it performs the "shortest possible stopping time without drifting off path."

  • It is pretty important for me.
    I am thinking about the strategy of moving already to a an endpoint, but at a point before (intermediary PTP movement) I fire a trigger where I check if the endpoint is ready or reacheable. If not I brake the movement and wait for release. If reachable the brake is not executed and there is a fluent motion.
    This would be an alternative to moving to the intermediary point if the endpoint is not already reachable, and if it becomes reachable then moving finally to the endpoint.
    Off course if during the first movement the endpoint becomes reachable, in the second scenario there is always a stop, in the first scenario not.
    But I must be sure the deceleration is not more aggressive then a normal positioning to an endpoint.

  • Well, the fastest way to a definitive answer, I think, would be to use the O-Scope function and try it both ways, and compare the decel times. And try playing with the programmed accel/decel values to see if they have any effect on BRAKE.

    On a completely different front... one technique I've used in the past in situations like this is to use the SPS monitor the distance of the TCP to endpoint of the motion, and (if an input condition was not met), gradually ramp down $OV_PRO proportional to the remaining distance such that the robot would reach 0 speed at some distance before the endpoint. This was mainly in high-speed press-linking systems where the delay in "recovering" from the standstill of a normal WAIT command could be a cycle-time breaker. That would be a very gentle decel, unless you really slammed $OV_PRO around.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners