Question on setting up helical drills

I’m sure this has been asked and answered before, but if so I haven’t been able to find it…

I’m playing with Estlcam and am (apparently) confused about some of the tool settings. In particular the F(z) value - I guess I was expecting this to control the speed at which the bit plunges in the Z direction. Instead it appears to be the speed at which both XY and Z move whenever Z is plunging. This has the effect on a helical drill of making the XY traversal (around the initial core drill) move painfully slowly when F(z) is set to what I would think would be a reasonable plunge rate (<1mm/s). This also takes an extremely small cut (so I’m generating fine, fine dust, not chips). If I set this value larger I can get ‘reasonable’ traversal rates, but it’s plunging the bit downward at rates that seem unrealistically quick.

Is there any way to keep the XY traversal speed up while slowly plunging?

Just for context, I’m trying to set this up for cutting a round pocket in aluminum (currently testing in foam and air) and I’ve already figured out that round pocket are automatically converted to helical drills.

Any pointers greatly appreciated.

EDIT - one other thing I’m noticing is that, regardless of F(z), I’m getting two revolutions around the starting point with a very shallow Z plunge, then it takes-off plunging down at the F(z) rate (spiraling around the center point). The 2 initial revolutions are occurring above the top of the material plane (but just slightly above)?

I have noticed this too and I think its the plunge angle. I think the remedy is to scale the desired z feedrate by 1/sine of the ramp angle.

1 Like

Hmm - I have my plunge angle set to 90 degrees - I’ll try some tests varying that and see what I get…

Ok - some interesting results…
It seems that for helical drills (at least) the plunge angle has some control over the number of revolutions the bit takes while making it’s center downward cut, and F(z) is only controlling the speed at which those revolutions are traversed. I do suspect there is some trig going on in how the tool paths are calculated, because the plunge angle’s affect on the number of revolutions is definitely non-linear. These are the observations I made at 4mm Depth per Pass (Z+):
Plunge Angle - # of Revolutions to reach 4mm - Notes
90* - 1 revolution -
45* - 1 revolution -
30* - 1 revolution -
20* - 2 revolutions - 1st revolution was ~3.5mm, 2nd was only .5mm
15* - 2 revolutions - 1st ~2.5mm
10* - 3 revolutions - 1st and 2nd revolutions ~ 1.5mm each, 3rd 1mm
5* - 5 revolutions
3* - 9 revolutions

So it would seem that tweaking the traversal speed and plunge rate are actually controllable and independent of each other. I do worry what would happen if I had a tool setup with 5 degree plunge angle and say an 8mm/s F(z) (to keep the helical drills running at a reasonable rate), but there were also straight drills (or a path that couldn’t support a 5 degree plunge). I suspect the bit would be plunged downward at the full F(z) rate… In wood that would probably be an event the bit would live through, in aluminum I suspect not…

1 Like

I have a feeling F(z) is meant to be for moves like this:

G1 Z-1 F

But when you have a move that plunges at an angle, I don’t thunk estlcam is doing the work to speed this up. So something like this is also affected:

G1 X10 Z-1 F

:man_shrugging:

Yeah, I’m thinking that F(xy) is used as the gcode feedrate (F) when only X and/or Y are affected by the move, and F(z) is used if there is a Z component to the move…

Got to wondering how this applies to pockets using the peel strategy, since (in my mind at least) helical drills could just be considered a special case of these. Found some interesting (to me at least) results:

  • When the helical drill is boring it’s initial hole the bit revolves at an offset of 1 tool radius from the center (boring a hole that is 2 tool diameters wide). For the initial hole in a pocket the bit is offset only 1/2 tool radius - resulting in an initial bore hole 1.5 tool diameters wide. This also means that for pockets the tool path length to make one revolution (in the initial bore) is significantly shorter than for a helical drill.
  • Because this path is shorter, with shallow plunge angles more revolutions are needed to achieve the same depth. So the number of revolutions increases more rapidly for shallower plunge angles in pockets vs drills.
  • My observations support this hypothesis (with one glaring exception at 90 degree plunge angle):
    Plunge Angle - # of Revolutions to reach 4mm - Notes
    90* - 3 revolutions - I now believe this is treated as a special case in pockets (but not drills)
    89* - 1 revolution -
    45* - 1 revolution -
    30* - 2 revolutions - 1st revolutions ~2.5mm
    20* - 3 revolutions - 1st and 2nd revolutions ~ 1.5mm
    10* - 5 revolutions
    5* - 9 revolutions
    3* - 15 revolutions

I now suspect that pocketing has a special case when the plunge angle is set to 90 degrees, which forces a plunge depth of approximated 1/2 tool diameter per revolution. This could be setup in any number of ways, but it really feels like it’s probably being treated as a special case in pockets, but not in helical drills.

My take-away from all of this is that to get the behavior I’m looking for (relatively shallow DOC for the plunges, but maintaining a reasonable traversal speed during the plunge) the trick is to fiddle with the plunge angle (generally making it very shallow), but keep the F(z) higher than would seem prudent if an actual straight-in plunge were ever attempted. If vertical plunges were needed (regular drills), setup a duplicate tool with a much more conservative F(z) for those operations.

Makes me kinda wish the estlcam source was open so I could verify some of my assumptions, but it was an interesting exercise in any case. And I feel I have better handle of what it’s doing and what to watch out for…

3 Likes

Yeah. But it is reasonable to contact @christian-knuell and suggest he changes it. The slope in Z to XY should be known, so it should be able to create a max F based on the max F(z) and max F(xy).

Great experiment, I agree it’s natural to expect F(z) to be the maximum vertical component instead of “F(xyz)” being total feedrate when z movement is involved. I hadn’t done a full experiment but I suspected this behavior from my shalllow ramps going very slow.