GRBL new post processor with drill cycles G81..G83

[freman]

The reduced pecking only affects the depth of each successive peck, it does not change the retraction height.

While IJK pecks would be a nice addition, it will require some work on the UI and treeview.

I'll restrict myself to finding a suitable A_BIT value for rapid move down to previous drilling depth.

I see three choices :

1. Wsk8's one-size-fits-all absolute distance
2. a %age of peck depth, Q
3. a %age of drill diameter.

2 and 3 are similar since peck depth is usually chosen as a multiple of tool diam. , though the latter is probably a better way to define it. I'm inclined to that approach because I don't think the best choice for 1/2" and 1mm drills will be the same. The aim is probably to avoid any roughness or debris in the hole while on rapid and that will depend on tool size.

It's poor that NIST don't specify this properly.

[freman]

Especially when GRBL does not yet support any type of drilling canned cycles?

The discussion about IJK peck cycles affects all FC output since it will be in the UI. If this is a HAAS extension, it will probably need to be added to all post processors anyway and that is probably not priority.

I've already coded the correct speed for peck retract/returns for the GRBL post processor. That was important, even on small jobs since doing it all at drilling speed is painfully slow.

You are correct about cast iron. There is no reason why retract height needs to be out of the hole, probably best if not in most cases since that also mean re-entering the hole at full rpm. I've also added a check that R is less than Z per the spec.

I'll probably submit with 5% of drill diam. , if it causes a problem it will be easy to change a detail like that later.

5% of 8mm diam = 0.4mm

[RatonLaveur]

It is necessary to at least bring the flutes back over the surface of the material so they can evacuate chips for example.

Actually there is some thought that this is a bad idea. The drill flutes do a pretty good job of evacuating chips if pulled close to the surface, and pulling the drill bit all the way out of the hole allows some of the junk on the surface to fall back into the hole. It then gets recut when the drill goes back to the working front.

I have seen this in some cases when working with materials like cast iron. Not really a problem for me because I work conservatively.

Gene

I meant only the top of the flutes should come up to the surface when deep drilling. Just to pull the chips out. I didn't mean clear the surface with the whole bit

[freman]

PR for the speed changes:

https://github.com/FreeCAD/FreeCAD/pull/3725

[Gauthier]

Hi @freman,

Thanks for this good idea of canned cycle speed optimisation, and sorry for my late response...
Since NIST RS274NGC is not the only GCode standard (ISO 6983, DIN 66025, PN-73M-55256 or PN-93/M-55251are other ones), I think this must be a postprocessor option, and it shouldn't be activated by default.

By using this optional speed optimisation, the user will have the choice of the value of the rapid speed distance. For example:

Code: Select all

-drill_speed_optimize=0

=> no optimization, keep current behavior,

Code: Select all

-drill_speed_optimize=3%

=> optimize with rapid speed of 97% of the Z movement and cut speed of 3%,

Code: Select all

-drill_speed_optimize=0.5mm

=> optimize with fixed cut speed length of 0.5 mm after the high speed,

Code: Select all

-drill_speed_optimize=0.05d

=> optimize with cut speed length of 5% of the tool diameter after the high speed,

@++;
Gauthier.

[freman]

Thanks for your thoughts Gauthier.

Do you have a working link to any those documents. ISO , for some reason, think we should pay to see the contents of international standards. The other refs seem to be an equally frustrating paper chase.

Do you know whether any of those documents give a proper spec of what should be done for G83: ie do they define what NIST call "a bit" in a technically coherent manner?

I don't think this is "optimisation". From the NIST spec, it is required. It is just the detail of exactly where you should stop when approaching the previously drilled depth which is ill-defined.

It makes no sense at all to retract at drilling speed or to descend through the air in a previously cut hole at drilling speed. That is painfully slow to sit through and grossly increases machine time for no good reason.

You suggest it should not be active by default. What is your reason for saying that?

@+

[GeneFC]

FYI, the "bit" as interpreted by LinuxCNC is hard-coded in a header file as:

Code: Select all

/* how far above hole bottom for rapid return, in inches */
#define G83_RAPID_DELTA 0.010

The value is not user accessible in the compiled program.

Gene

[freman]

Useful reference, thanks, so 0.25mm. A bit closer than I would have chosen but same ball park. cf Wsk8's fixed 0.4mm

I'm inclined to relate the choice to drill diameter ( like d/10 ) than one size fits all but I don't think that is accessible to the post pro. only the command parameter Q : the peck depth. If I guess the peck is probably about 3D that gave me my initial Q*3% . Maybe better to err a little larger than too close.

At least I have a proper variable name now

[freman]

Hi @freman,

Thanks for this good idea of canned cycle speed optimisation, and sorry for my late response...
Since NIST RS274NGC is not the only GCode standard (ISO 6983, DIN 66025, PN-73M-55256 or PN-93/M-55251are other ones), I think this must be a postprocessor option, and it shouldn't be activated by default.


@++;
Gauthier.

I do not have access to those very expensive documents. ( Why the hell anyone makes a national standard and then prevents it being a freely available document is beyond me.)

Do any of those documents say anything different from the NIST spec ? Do any of them give us something more useful than NIST's "a bit".

Is there any reason not to want to rapid through space that you have just drilled slowly ? Isn't that the point of "canned" cycles? Anyone having the need of customised behaviour has the possibility not to use a fixed "canned" cycle and program whatever speeds and moves fit a specific need.

While an extra parameter would allow fine tuning in terms of % mm or D, I don't think this is a critical issue, it just needs a reasonable default. It seems to me that a faction of drill diameter is more appropriate than an absolute distance or a fraction of drilling depth ( which is typically a multiple of drill size so it comes down to the same thing).

the current PR is 5% of step down ( 15%D in case of 3D steps ) but since this PR has not been merged it may need updating.

10%D seems a good default, does anyone have objections or machining cases where that would be a problem?

Thanks.