Want to get constant cutter speed on my kuka

I was wondering if I could get some help. I have written a Kuka PRC program to do 11 different cuts in my 3D part.

I created the program by drawing the curves I need in Rhino and then drawing the jogs between the curves. My Grasshopper program uses the curves to add orientation curves. These curves are then broken down into 150 segments with a "Divide Equal" command", then merged and fed to my Kuka|prc core. 24 commands in total.

The program works well on the Kuka in T1 setting so I can adjust the speed. Albeit my hand is exhausted holding the buttons... and this will not work when I am not in T1 mode.

When trying to program I found that if I did not have each curve broken into an equal number of segments (i.e. 150) the commands would not merge. I found that each LIN command on the kuka is completed in the same time interval. Unfortunately this means that some of my shorter jog curves can take longer to run than my cutting curves. And my velocities are not constant throughout the program because the curves are different lengths. I need the cutter when in the material to have a consistent cutter speed to optimize my machine time (as well to speed up the jogs).

Is there a better way to program this (or component to use) so I can manipulate the velocity with Kuka|prc? i.e. should I be using Divide Equal and Merge?

Thanks

Joanne

Replies to This Discussion

Permalink Reply by martyn hogg on August 25, 2015 at 2:34am

I'm not familiar with KUKA PRC but for 3-axis CNC machines the g-code lines usually include a G code for the type of move, coordinates and a feedrate so a line might look like this...

G1 X10.0 Y10.0 Z10.0 F1000

Where F1000 would be the feedrate.

Sometimes I think if the feedrate is not specified it would use a default setting for the particular G code.

Is the KUKA defaulting to a preset time per move because you are not specifying feedrates?

Are there different modes for the KUKA? i.e. one mode where each move takes the same amount of time and another mode where feedrates should be specified?

There must be some way of controlling the feedrate other than just having more or less curve division points otherwise you would have to break each LIN command of 150 points down into say 3 points so your rapid moves might be a small number of large, spaced out 3 point moves and your slower cutting moves might be a large number of small, close together 3 point moves. Perhaps this is how it is doen with KUKA, but as I said for most CNC machines you specify a feedrate for each type of move.

Permalink Reply by Johannes Braumann on August 25, 2015 at 4:38am

Hello Joanne,

I'm the developer of KUKA|prc - if possible post support question on forum.robotsinarchitecture.org as I get immediately notified when any new posts are made. Here it took me a while.

On a KUKA robot, no matter if you are using KUKA|prc or another tool, you can set the velocity of the robot in % for PTP movements (movement from A to B with the least amount of axis rotation) and m/sec for LIN movements, as you are using.

However, there is no guarantee that the robot will actually reach that speed as its maximum speed is set by the slowest axis. Furthermore, what seems to be the problem in your case, is that a high point density will always slow down the robot.

There are some things you can try out: If you want constant speed, manually set the speed to a rather low value (the robot will never go faster than the programmed speed). To get more speed out of the robot, use a less dense toolpath, be sure that an interpolation like C_DIS is enabled. In the KUKA|prc settings set the Advance Run to e.g. 3 positions. You can also do that manually with the existing file by setting the variable $ADVANCE to 3.

Do you have access to the member version of KUKA|prc? It makes a few of these things easier than before, with e.g. a component to reduce the complexity of toolpaths. Send me an eMail (johannes[at]robotsinarchitecture.org) and I can send you a temporary license for it.

Hope that helps!

Best,

Johannes

Permalink Reply by Joanne H on August 26, 2015 at 10:42am

Thank you Johannes

I will follow up via email. Thanks for creating this application.

As a follow up on here, I actually want to increase the number of LIN command points as I need very smooth curves. In tight corners I watch the tool working very choppy due to LIN. So my fix was to increase (which unfortunately changed the tool path as well since the curves were more closely followed) - and I had to scrap a few more parts.

I will also try reducing the LIN speed. As my goal is to get slower... I have been doing my cuts at 3% or 1% velocity while in T1 mode. That is most important. Faster jog speeds is just a plus.

Thanks,

Joanne

Permalink Reply by Johannes Braumann on August 26, 2015 at 11:27am

Hello Joanne,

I've replied to your eMail. And yes, if you are using T1 at 3%, definitely set a slower speed in m/sec - this will greatly improve the toolpath. Another way would be to use spline toolpaths, which you can use with all KRC4 and some KRC2 robots. Spline-movements have got their own challenges, most importantly you have to remember that the robot will basically connect a series of points with a spline (similar to Curve-through-Points), so you cannot just take any NURBS curve and have the robot follow it.

Best,

Johannes

RSS