LinuxCNC and Path blending tolerance

[sliptonic]

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

Code: Select all

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?

[herbk]

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...

[GeneFC]

Is that tolerance too tight/loose for a default?

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

[cahlfors]

"inferial" units

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...

[oeliks]

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

Code: Select all

G0 Z10 F10
G0 X10 F100

Will blend to:

Code: Select all

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.

[GeneFC]

Well I noticed this today also

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

[oeliks]

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

[GeneFC]

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

[Joneb]

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

[jbraun]

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...

Yes, decscibing dimensions as mm or " isn't much extra effort

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 ?