HOW DO YOU THINK WHEN PROGRAMMING MOVE VELOCITY?

    Hi! I'm new to Robot programming. I would like to know how do you think when programming moves on robot. I mean we all start to teach points and if you use the INLINE mothod for all point you have a velocity. PTP 100% and LIN 2 m/s for default. I understand that they are $OV_PRO dependent. So if your $OV_PRO is 10% you have to think for instance to that 2 m/s relative your $OV_PRO.


    So besically you try to program your movement presuming that you'll go to $OV_PRO=100% and you can figure it out how much velocity you want for avery movement. And if you need to change the speed you have to reinsert the velocity for that movement.


    Another way could be to leave all the maximim velocity and write your $OV_PRO when needed to scale the velocity down.


    Wich is the best practice for speed control over the program? Are any other method you use out there?

    For operations other than paint/extrusion or seam welding, robot speed generally isn't crtical, compared to path. Also, PTP motions are kind of random, anyway.


    Baseline assumption is that $OV_PRO will be 100% by default, and some programs where that is critical should be written with checks for that.


    Moves are generally programmed by feel -- large air moves at 100% PTP, with large approximation radii. Moves in tighter quarters, or with hard turns, usually involve reduced speeds, accelerations, and approximation, depending on expected inertia. Interpolated moves are saved for when they're absolutely necessary.


    Normally, barring speed-critical motions like paint, moves are initially programmed at lower speeds than their intended "final," and test at low $OV_PRO -- the rule is, get it working reliably first, then speed it up. Once $OV_PRO is at 100%, and motions can be observed, improving speed is an interative process of finding which motions can be tweaked, and by how much. Sometimes, moving slower actually reduces cycle time, by making certain transitions smoother. And any wait states also have an effect -- some parts of the program are fine to let the robot run slowly, b/c it'll always be outrunning the hardware it's waiting for, and other parts need maximum speed tuning, because everything downstream is waiting. It's all about identifying and improving bottlenecks, one at a time.

    OK... thanks al lot for sharing some of your tips. I agree with you that you need to observe the cycle at the and of your job and try to see where and when you can adjust the speed.


    So in conclusion you can leave the speed as it is for PTP (100%) and LIN (2 m/s) and place before and after blocks of your program $OV_PRO adjustments... wich is faster than modify each movement speed...

    Not... necessarily. If working in tight quarters, I'll often slow the speed down on motions in that area during initial programming. Open-air moves I'll often leave at default max speed. It's something you sort of develop a feel for with experience.


    As a rule of thumb, start slow -- you can always try to improve speed later, but breaking hardware b/c you tried to go too fast too soon can get expensive.

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