Arcing "Rapid" Movements

[area419jon]

I saw a video the other day for a Makino I think which had a drill cycle that, instead of moving straight up then straight over, it "arced" out of the hole to the next hole.  I feel like this is something that would be doable in HSM and wondered if anyone had ever suggeted it before?  It wouldnt have to be just for drill cycles, really anything could benefit from it.  I have a program that drills 50 holes in a plate, then comes in and bores them with an endmill, then chamfers the rims.  I feel like gobs of time could be saved by having one fluid motion from one hole to the next.  Only thing I would suggest is using true arcs instead of points along the way so that non-high speed look ahead machines can benefit from it as well.

Thanks!

[Laurens-3DTechDraw]

@area419jon

The more fluent the motion indeed the faster it goes. That's what the control kind of does with contour control turned on.

But a programmed arc would help, although I think we have one problem, and that is how would you program it on the control?

Does your machine support arcs in rapid movements? Because I'm pretty sure Fanuc's don't.

[Steinwerks]

Pretty sure this would have to be in High Feedrate mode. No machine I've ever run (that's not a lot, Fanuc, Haas and Fadal) or heard of will arc in rapid. I presume either the Makino was programmed as such or has an option to interpolate rapids into fluid motion, likely an option on top of the control since Makino customizes their overlay.

[Laurens-3DTechDraw]

@Steinwerks

I think they made a special cycle. So not the standard fanuc drilling cycle.

Which would of course not be hard to write a macro for.

"

Included is GI Drilling, a unique G-code drilling cycle that enables the spindle and tool to arc from hole to hole instead of following a square path. This simple change reduces non-cut time by as much as 15 percent on common hole-pattern drilling.

"

https://www.makino.com/about/news/Makino-DA300-Vertical-Machining-Center-Reduces-Machining-Time-for-...

[Lonnie.Cady]

It has been around for quite a while.  Used it on G&L controls.  It basically turns off exact stop and acts like corner rounding on steroids.  It is probably not a true arc. Same way doglegs are not true 45 deg.   It can also be dangerous around clamps and fixtures.  It allows the next axis to begin movement way before the other has completed.  It was a special G code on that control and could be used any time.  We even used it in turning when positioning between several grooves.

[Laurens-3DTechDraw]

@Lonnie.Cady Ultimotion from Hurco does it too.

http://www.hurco.com/en-us/cnc-machine-tools/our-control/pages/advanced-motion-control.aspx#RCT 

[Lonnie.Cady]

@Laurens-3DTechDraw I am sure there are more, just pointing out what seems new an cool sometimes is not.  I often think about what software could do when I started programming in the late 90's. Some days it does not seem like much progress for 20 years worth of advancement.  We had an Integrex70YB, dual turret Okuams with live tooling, live tooled CAT 60 VTLs.  Same issues I see today in many cases.  We could control , sync and issue wait codes for multi turret, control Y and B on turning etc....

[Laurens-3DTechDraw]

@Lonnie.Cady pretty sure this is one of those things that someone thought of that was a great idea but was left somewhere because the competitor could go faster without it. iThey put it in the control but the competitor came with rapids 1.5 times the value so it didn't seem to get anyone anywhere. Now every second counts and we are starting to run into the max speeds and accelerations for machines with ballscrews it comes up again.

[kb9ydn]

Pretty neat idea, although I'm wondering how much difference it would actually make over just setting the clearance distance close to the part top.

C|

[Lonnie.Cady]

@kb9ydn exactly, why do you need the clearance any higher than the R plane?

if your holes are on different levels this may not be all that safe.

@Laurens-3DTechDraw I am not so sure, it is still some controls if i am not mistaken.  It did not get used much because it is really not that useful in most situations.  I have run similar systems and it can be a little scary.  Especially when you single block thru and it looks great and then you let it go and maybe not so great.  Very much a specialized use.

[area419jon]

This probably would not make a giant difference on you lucky guys with 1000+ipm rapids.  But my little toolroom HAAS seems like it waits ten seconds between linear moves (up, over, down).  It also moves much faster in high-feedrate than it does in G0, so I think something like this could really benefit me and other older (slower) machines.  It would have to be non-high speed look ahead friendly though!

[kb9ydn]

@area419jon

I have a TM-1 and I still don't think arcing rapids would make much difference.  The reason being; when retracting from a hole or feature, for safety you will at least need to retract up to the top Z level of the part before you can start the arc.  But if you set the clearance plane just above that level, say +0.05in, there is barely any arc to make, so it isn't going to gain you anything.  It really doesn't matter how fast your machine's rapids are because once you've limited the distance for re-positioning moves as much as possible, there is no other way to make it go faster.

It also sounds odd to me that your machine moves faster in G1 than G0.  I usually use G1 for all X/Y linking moves because it's safer than dog legs, but it's never faster.

One thing you should consider doing is increasing the maximum speed of your Z axis.  The standard TM-1 only rapids at 200IPM while the TM-1P rapids at 400IPM.  This is set by parameters so if you know which ones to change you can double your rapid speeds.  I tend to make fairly small parts so faster X/Y rapids don't make much difference, but doubling the Z speed makes a huge difference, especially with tool changes.  If you google around you can find the info for how to do this pretty easily.

C|

[area419jon]

@kb9ydn

I have a 2P, so rapids are at 400.  But if you program a G1 at 400ipm vs a G0, the G1 is definitely faster.  The other benefit is that if your feedrate is set above 100%, the G1 will move faster than 400, but you can never put in something higher than 400 in the code.  Ive had the machine moving at 600ipm before if I program for it.

I still contend that arc'ing moves will speed things up due to the slight delay between two linear moves compared to the fluid motion of connecting arcs.  I may be wrong, but either way it would sure be cool.

[Laurens-3DTechDraw]

@area419jon

If the machine goes beyond the rapid speed haas really did a poor job setting it up. (And it's probably bad for your hardware but well that's up t you ofcourse)

@kb9ydn a lot of the times the acceleration is higher in G1 than in G0 for machines. This is mainly due to the fact in the past people didn't run high feed G1's much to if they slowed the acceleration they could safely use higher rapid speeds without wearing anything out. Also in G1 you need the acceleration whereas in rapid you are not counting on it to be right.(Most of the times the control is set to a lower gain(number of times it checks position) for rapids so is can move smoother and faster without loading up the control, one of the reasons a lot of machines have a max cutting feedrate and a much higher rapid)

I do have to agree that I don't think it will gain much due to the fact you need to move higher than normal.

[kb9ydn]

@Laurens-3DTechDraw  I couldn't say much about the acceleration of G1 vs G0 on the Haas without putting an accelerometer on the table and doing some measurements.  I did look through the parameters but I didn't see anything that looked like separate values for rapids vs feed rates.  As far as I can tell there is only one set of acceleration values per axis.

@area419jon  I can't speak to what your machine does without seeing it, but it does sound quite odd.  It got me curious so I did some playing around with mine (~2001 TM-1).  The maximum programmable feed rate (G1) is 200IPM but the maximum (X/Y) axis speed is set to 300IPM.  I set it up this way because allowing feed rates higher than 200IPM caused problems when I would try and dry run a program with the feed override cranked up, mostly with programs that have a lot of really tight arcs.  Rapids can be faster though because they are always straight lines and aren't going to shake the machine to death.

As far as overriding feed rates; the axes will not move faster than the maximum programmable feed rate.  What's curious though is that if you set the feed override to over 100% it will show the theoretical feed rate on the screen even if the axis is not moving that fast.  I was able to program a feed rate of 200IPM, set the feed override to 999%, and during a G1 move the control would show 1999IPM.  Now obviously it wasn't going that fast because it can't physically do that.  In fact it never went faster than 200IPM, even though the maximum allowable axis speed is 300IPM.  I have to say I think it's misleading for the control to show a speed faster than what it's actually doing, but that's the way it is and there is nothing I can do about it.  I did try setting the maximum programmable feed rate to 400IPM with the maximum axis speed still set to 300IPM.  Interestingly it will allow 400IPM feed rates to be programmed but when executed you still only get 300IPM of actual axis speed, and the control shows "LIM FEED" at the bottom to indicate that the feed rate is limited.  Why they don't do this when the override speed is faster than allowable I have no idea.

So I guess the bottom line is that I could find no way to have a G1 move be physically faster than a G0 move, even though the control says it is.

There is however a setting in the control (setting 85) for corner rounding that determines what the control does when commanded with a sharp corner move (line to line) at a feed rate that is too fast to achieve.  What it does is round the corner to the radius specified by the setting.  If this value is set to zero it does a full stop at every sharp corner.  It sounds like maybe this is what is happening on your machine.

https://diy.haascnc.com/setting-85-%E2%80%94-maximum-corner-rounding

Newer controls also have a (related) G187 command for accuracy control, although I don't know much about it.

C|

[Steinwerks]

@kb9ydn

Actually regarding G187 that has its own set of acceleration properties that can be adjusted in the parameters (these may be hidden normally but I have seen them on our 2012 VF6SS) as well as corner rounding values that can be set in the toolpath (E value). The G187 + E setting has been around for some time but I believe the P values (acceleration parameters) might only be since 2009 or so.

I do understand the G1 "faster" than G0 though. In a Haas the motion noticeably pauses between G1 and G0 and so going back and forth can slow down the actual toolpath even if the rapid is nominally faster once it reaches full acceleration. I mention this of course because Haas isn't exactly known for their lightning-fast machines (although they do seem to be getting better on that front).

And one of my biggest complaints about the Haas control is what you mentioned: that it will always show "programmed" feedrate and not actual feedrate. How am I supposed to optimize my programming if I don't know the limits of the machine's feedrate in various situations? 

This is especially problematic on a machine the size of the ours. It simply doesn't accelerate to 300 IPM in two inches of travel no matter what the control says, so I'd rather know on certain programs if I should be taking a larger optimal load at slower feed to compensate for that and keep the chipload where it should be.

In short though I don't see much benefit in programming for arc transitions. If feedrates are faster, better to simply expand the drilling cycles and post in high feedrate mode (this has its own drawbacks too of course).

[al.whatmough]

Batch processing ideas that are 10+ months old with less than 5 votes. This is in no way to suggest the idea isn't a good one. However, the lack of votes tends to mean that the community feels other ideas should be given a higher priority. Feel free to tag me if you feel an idea wasn't given enough of a chance. We are more than happy to have a conversation on any of these ideas.