LinuxCNC and Path blending tolerance

Mods CAM/Path
1

I saw this come up in another discussion and it reminded me that I had an issue with it myself last weekend.

I was doing an adaptive clearing on three holes. One of the holes would exit on the side closest to the next hole. The safe and clearance heights were plenty high enough but as the hole got deeper, the cutter started nicking the edge of the hole as it exited. The problem was that LinuxCNC is blending the G0 retraction move with the G0 rapid to the next hole.

Our default LinuxCNC postprocessor preamble has no tolerance setting for G64 and no argument to set it. So the user either has to edit the postprocessor or hand-edit the gcode.

I would suggest that the default preamble add a

G64 P0.025

to force the path tolerance to 25 micron. Is that tolerance too tight/loose for a default?

Should we also add an argument so it can be easily overridden?

2

Hi sliptonic,

The problem was that LinuxCNC is blending the G0 retraction move with the G0 rapid to the next hole.

realy, ? I never noticed that…

3

I set mine to G64 P0.001 in “inferial” units, which is the same. I tried tighter and looser, and that is what worked for me. I do not see any slowdowns, and I do not see any blending problems. I would like to be able to work with 10x greater precision, but realistically 0.001 inch is all I can expect with my machines.

I typically work with difficult materials like stainless steel, so my needs may be different from someone working in aluminum or non-metals. That is why I suggested testing in the other thread.

Gene

4

:laughing:

When people from “imperial territory” talk about thousandths and microns, I really don’t know what to expect… And if there is no clue to their origin… :unamused:

5

Well I noticed this today also :confused: Fortunately on a test piece made from foam :wink:

G0 Z10 F10
G0 X10 F100

Will blend to:

G0 X10 Z10 F100

But G1,2,3 G codes are not blended.

So now Im not setting any feeds in FC, and then find&replece G1 → G1 Fxxx, and then G0 to G1 Fyyy etc.

6

That looks like sort sort of problem, but it has nothing to do with the topic.

LinuxCNC does the blending inside its trajectory planner. What you are reporting is in the G-code.

Gene

7

The problem was that LinuxCNC is blending the G0 retraction move with the G0 rapid to the next hole

I tried to describe the exact same problem.

Freecad postprocessor for Linux CNC generates G0 codes one after another, but Linux CNC will blend this two G0 g-codes in to one.

https://m.youtube.com/watch?v=culLVxEmFuE

8

I understand the problem.

The “solution” is that you need to set up LinuxCNC correctly. It is not done in G-code, and it really has nothing to do with FreeCAD. (Other than FC helping issue the G64 code).

Gene

9

I’ve always set mine to G64 P .5 which is acurate enough for what I do mainly wood if you set it to low it may slow your machine down. I’m suprised that other users haven’t picked up on this as I had a problem write at the start using LinuxCNC cutting out letters they just didn’t look right.
I edit the post processor.
John

10

Yes, decscibing dimensions as mm or " isn’t much extra effort :slight_smile:

Adding G64 option in the Jobs “Arguments” and displayed in that mouse-over might be better than setting a default ?
Also does [–precision= ] argument only work posting metric ?

11

For 0.19, you should just add the G64 bit to your preamble. When we start the 0.20 development cycle, refactoring the post-processors is going to be a priority. We’ll have a dedicated linuxcnc post that has a path blending option at that time.

The precision flag controls the number of digits of precision after the decimal point and works regardless of unit.

12

What’s the proper syntax ?
–precision=2, --inches
results in G20 and 4 decimal places
–inches, --precision=2
returns an error
–precision=2
results in G21 and 2 decimal places

maybe it’s my settings somewhere, anyway I only tried this out of curiosity of how arguments string together.

13

Okay syntax is
–argument --argument --argument
which makes sense. I got thrown off because --precision= has no effect for me when combined with --inches. It doesn’t matter since linuxcnc recommends minimum 4 decimals when milling in inches and the post is 4 decimals.

14

This solution didnt work for me. :confused:

G64 P0.1
G0 Z10 F50
G0 X0 Y0 F500

Different feed rates on Z axis and XY axis produced the same result like when not using G64.

Or maybe I’m just using G64 wrong?

15

I am not certain that LinuxCNC path blending works with G0. I did not find anything in the documentation, but I know there are instances where G0 is treated differently from other motion codes.

Also, you might try adding the “Q” parameter. I have never used it, but the description indicates it may be a secondary check on blending behavior.

Gene

16

Was this code being run in single block mode ? In single block with G64 active the Z retract will stop short of the programmed height.

regarding G64 and G00 the docs say:
“When using G0 (rapid) moves with G64 use caution on clearance moves and allow enough distance to clear obstacles based on the acceleration capabilities of your machine.”
suggesting G64 acts on G00 moves.

I think G64 P without Q is the same as G64 P Q0. I posted that question on linuxcnc forum so will correct this post if I’ve got that wrong.
Really I think these type of questions are best answered on that forum, I’m not aware of linuxcnc developers posting here.

17

I agree. That is what I was suggesting above. There is nothing improper about the FreeCAD output in this case.

Gene

18

G64 was a preamble.
Two G0 moves one after another was generated by Freecad Linux CNC postprocessor. This caused a “crash”.

Its not so uncommon to have a different feeds on Z axis and XY axis. And setting rapid move to lowest possible value for axis that dont travel as much as XY is waste of time.

My previous answer was to first post of this topic. That adding preamble G64 P will remove this problem. But in prezented case it didnt.

The probabble issue is - feedrate of Z axis F50 was “replaced” by feedrate of XY F500, jammed the Z axis and then executed the next move XY with F500. Im not sure, but thats how it looked like.

This blended Z and XY moves with second feedrate.

If this is true, changing G0 feed rates XYZ to lowest value (in this case F50) should remove the issue, but wont be the best option.

19

I think G64 P without Q is the same as G64 P Q0

And that’s the problem with thinking… I’m not good at it :slight_smile:
I’m told G64 with Q0 would act the same as G61. That makes sense.
With no Q in the g-code, Q becomes equal to P. Using a Q smaller than P will follow the path more exactly. Unless someone on the linuxcnc forum says otherwise I’m staying with that answer.

oeliks.
Sorry I can’t help. I think the path should respect the P value despite different feed rates but offer no guarantee. Sometimes the documents don’t tell the whole story.

20

Two G0 moves one after another was generated by Freecad Linux CNC postprocessor. This caused a “crash”.

Because your gcode interpreter didn’t executed the program correctly.


Its not so uncommon to have a different feeds on Z axis and XY axis. And setting rapid move to lowest possible value for axis that dont travel as much as XY is waste of time.

Every simple gcode interpreter can handle different feeds.


The probabble issue is - feedrate of Z axis F50 was “replaced” by feedrate of XY F500,

Because your gcode interpreter didn’t executed the program correctly.


This blended Z and XY moves with second feedrate.

Because your gcode interpreter didn’t executed the program correctly.


I also use different feeds for z and xy. Never had any problems with it. Please configure your machine correctly.
There is a reason why FC puts moves in separated lines instead of merging it into one!