Hello everyone, I am working with kuka robot KSS version 8.6.6 and I would like to increase the speed of robot My robot is applied for press (run 6 points, using LIN, CIRC motion), and each cycle press for a product take 10 seconds and I need to reduce it to 7 seconds. I have reduced the robot's running distance but it's insignificant. Can everyone help me? Thanks
Increase the speed of robot
-
Nguyen Truong Chinh -
March 23, 2023 at 5:03 PM -
Thread is Unresolved
-
- Go to Best Answer
-
95devils
March 23, 2023 at 5:10 PM Approved the thread. -
i see no code so... what kind of help you are looking for?
if the speed is required, motions should be blended as much as possible, avoid advance run stops, CP motions are to be avoided, and if used, stick with new instruction set (SLIN, SCIRC), make sure load is as light as possible and entered correctly etc.
and do not use inline form motions, when using pure KRL motions, one can use maximum values for velocity and acceleration. for example ILF instructions cap velocity at 2m/s while robot may well be capable of more. ILFs are there for convenience, not performance.
in general, optimized code like for press transfer and palletizer can do cycles in 2sec or so. but it takes effort...
-
You can make continuous motion without braking and win time by using CONT. You can also try using LIN in the place of CIRC if possible and check the cycle time.
-
I did press linking in the past and robot speed was not the major issue.
When do you go into the press to take the part out?
When the loading robot can go into the press to put the part in?
How is you gripper build - oscillation?
Do you use plc to control the robot speed?
Do you have a synchronous or asynchronous press line?
-
My robot is applied for press (run 6 points, using LIN, CIRC motion), and each cycle press for a product take 10 seconds and I need to reduce it to 7 seconds.
That's a big jump. Without really seeing your application, or code, it's very hard to make concrete suggestions.
LIN and CIRC motions should be avoided when possible. PTP motions are inherently faster.
Using TRIGGER commands to pre-fire grip/release/clear signals can be used to decrease cycle time, but this adds risks. I once had a press-linking line where the robot fired the "start press" signal while the robot was still inside the press, using the acceleration time of the press to get clear.
Grippers and suction cups take time to grip or release, so triggering their open/close a fraction of a second early can also save time. But of course, this adds some risk.
You need to identify the bottlenecks, and attack them one at a time. Fixing one bottleneck will often reveal another, at another part of the process.
Is your payload data accurate? By default, KRCs assume worst-case payloads, which makes them move more slowly.
I have reduced the robot's running distance but it's insignificant.
What does this mean? Details matter.
-
and each cycle press for a product take 10 seconds and I need to reduce it to 7 seconds
Just a stupid Question:
How can you be faster than a press?
Define:
cycle press (10s): OT-UT-OT
With the information I got so far you must live in a different galaxy.
Give as all information to help
-
- Best Answer
i see no code so... what kind of help you are looking for?
if the speed is required, motions should be blended as much as possible, avoid advance run stops, CP motions are to be avoided, and if used, stick with new instruction set (SLIN, SCIRC), make sure load is as light as possible and entered correctly etc.
and do not use inline form motions, when using pure KRL motions, one can use maximum values for velocity and acceleration. for example ILF instructions cap velocity at 2m/s while robot may well be capable of more. ILFs are there for convenience, not performance.
in general, optimized code like for press transfer and palletizer can do cycles in 2sec or so. but it takes effort...
Adding info about this:
If you want to use the new instructions, do not mix "S" and "Normal" instructions (Example: SLIN and LIN instructions on the same trajectory)
It seems each set of instruction uses a different motion planner, and if you mix the normal and new instructions it will be forced a fine point.
I had that issue with a robot that was stopping even with C_DIS and no logic betwheen points, until I changed all instructions to the normal ones.
I also tested it using only "S" instructions and it works ok, problem only happens when you mix the two instruction sets.