Request for comments regarding cutter diameter compensation

[JasonTitcomb]

I challenged myself to implement cutter compensation and I am at the physical testing stage.
Its a feature that hobbyists don't typically need but I wanted it.
I am running on BOARD_T41U5XBB with my 3 axis router.
Here is cutter_comp.md next to the code files.
Any comments about how it's implemented or suggestions for changes are welcome.

[terjeio]

Nice! No comment on the compensation code itself, how it is added to the core looks good to me.

Some initial comments/questions:

• There are some gcode commands that cannot be executed while compensation is active, these should return an error and it seems there are no checks in place. G10L11, G28, G30, G38, G53, G54-G59.3 and canned cycles are those I found while skimming the LinuxCNC documentation. I assume M6 should also fail if compensation is active since it likely involves probing.
• Add current mode to report_gcode_modes().
• M2, M30 turns compensation off?
• On M72 or M73 is compensation reenabled if was active? Looks like it might be but not sure.
• G41.1 and G41.2 are not implemented? Which means that a tooltable has to be enabled?

Finally, there is a debug_printf() that you may use instead of your custom version. This is enabled with the DEBUG symbol and is an empty function that should emit no code if not.

[JasonTitcomb]

Excellent feedback.
The code is in and the .md file is updated. Now I need to test.
I am not familiar with M72 or M73. I'll need to construct some kind of test case to verify my changes for those.
A sub call while in cutter comp mode?
If you or anyone else has a gcode file I can use as a reference that would be great. Otherwise I will come up with something.

[terjeio]

I am not familiar with M72 or M73. I'll need to construct some kind of test case to verify my changes for those.
A sub call while in cutter comp mode?

These are connected and logic dictates that a sub call should not change the mode pre call. If so M70-M73 would lose their meaning?
Currently the core do not return the correct value for the _ccomp parameter so there is no way for a sub to query the current mode, this has to be fixed. To do so either ccomp_mode_t should be expanded to cover G41.1 and G41.2 or gc_ccomp_t should be given a new field dynamic. The latter is the best option?

A test would be to add a G65 macro which saves the modal state with M70 or M73, disables compensation and makes some moves then restores compensation with M72 before exit if saved with M70. If saved with M73 it should be automatically restored on exit.

I see you have added some new error codes to error.h, please add them to error.c as well.

[JasonTitcomb]

This test passes after some work.

Here is my sub residing on the SD card.

M73
G40
G0 Z1.0
G91 X1.5
X-1.5
G90 G1 Z0 F20.0

Here is my main calling it.

(TEST WITH .25 OFFSET)
N1 G0 G20 G17 X0.0 Y0.0 Z0.0
N2 X0.02 Y0.25 F40
N3 G1 G41.1 D0.05 X0.25 Y0.55
N4 Y0.9
G65P200
N5 X0.45
N6 G03 X0.5 Y1.15 R0.65
N7 G02 X0.9 R0.25
N8 G03 X0.95 Y0.9 R0.65
N9 G1 X1.15
N10 Y0.55
N11 X0.7 Y0.65
N12 X0.25 Y0.55
N13 G40 X0.2 Y0
Z0.1 X0Y0
N14 G0G53Z0

[JasonTitcomb]

This is an update in case anyone has feedback.
The mechanics of offsetting the tool path and taking input for the tool diameter seem to work as expected.
If you just run the job it works as expected.

As I continued to test I notice that if you are in single block mode then you are one-move off where you think the tool should be.
When you first enter with G41/G42 and single block you will notice the machine doesn't move until it reads the next line.
And also upon canceling cutter comp with G40 while in single block mode it will execute the cancel move automatically when you press the last cycle start before the G40. Effectively making two moves with one press of cycle start.

The other issue is with a M00 or M01. They will appear to happen one block too soon.
All these issues are because the cutter comp system need to know about the NEXT move so it can stop short, extend or add a corner roll.

I started going down the trail of overcoming these issues but adds a lot of complexity to the core code.

[karoria]

I am not the right person to comment you regarding this as I am not using single block mode. All I want you to know is that I am desperately waiting for cutter compensation feature. This will be a great upgrade. I can help you testing it on my machine if required.
Thanks for your time and effort.
Cheers!
Ravi

[JasonTitcomb]

Awesome.
Oh you're the right person all right.
Single block, feed hold and M00 seem to be working for me now. Had a breakthrough.
Take a look at this doc cutter_comp.md.
See what you think about the restrictions and how the diameter is specified.
Jason

[JasonTitcomb]

Ravi,
Are you running a BOARD_T41U5XB?
Jason

[karoria]

I am having my customized board with teensy4.1. I am compiling locally with vs code and PIO. Let me know if I can be any help to you.