Cutter compensation and variables is very bad

[mr_guy99493]

Using cutter compensation to offset arcs while using variables is unusable.
Cutter compensation with literal constants works as expected, [leftmost circle in image] (although adding a + to a constant also fails, which is unexpected, [final line of gcode, rightmost circle])

When the arc's y coordinates use a variable (#2, #1 in the example) the offset arcs have incorrect midpoints, and other glitchy behaviour at edges of arcs. [center ?circle? in image, should be same as left]

In addition, variables are extremely difficult to use. Using the negative value of a variable such as `g1 y-#1` doesnt work, nor does any variable maths `g1 y[#1 + 10]`

Bad cutter compensation demo

Minimal GCode to reproduce, using AXBB demo with standard profile.

Code: Select all

g40
g90

#2 = -10
#1 = 10

g1 x -10 y 10

g1 y#1
g41 d1

g0 x0
g2 x0 y-10 r10
g2 x0 y10 r10

g0 x30
g2 x30 y#2 r10
g2 x30 y#1 r10

g0 x60
g2 x60 y-10 r10
g2 x60 y+10 r10



[cncdrive]

I think we did not test the mentioned scenario.
Will have to implement cutter compensation for lathes (which is a bit more complicated than cutter comp for mills), it will be only in the next next release and then we will take a look at this problem too.

[mr_guy99493]

This is a pretty fundamental use-case.
Automatically generated g-code may not suffer due to this bug, but writing gcode manually becomes basically impossible.
Variables are required for most subroutines to be useful, and cutter compensation is a requirement for producing accurate parts without editing hundreds of lines of code.
In another thread you say a new lathe version will not be available this year... that means manually written gcode with this software is and will remain unusable for at least 6 months?

[mr_guy99493]

I think the main issue may be with the parsing of commands using variables, rather than the cutter compensation specifically - it may be just one place where issues show up.
Since 'Parametric programming using internal variables and programming mathematical expressions.' is one of the listed features for the software, could you please provide a fix for this issue in a timely manner.

[dezsoe]

In another thread you say a new lathe version will not be available this year...

Where did you read this? It must be a post from last year...

[mr_guy99493]

No, not last year.... 2 years ago. My bad.

[cncdrive]

I think the problem lies in that with cutter compensation there is a look-ahead, because the controller has to look ahead one line and probably the # variables are not handled properly there.
Can you test if replacing the # variables to fixed values fixes the issue?

[mr_guy99493]

Yes, thats the first circle in the example gcode, works fine

[mr_guy99493]

For anyone else interested, manually specifying the circle midpoint using relative IJ parameters resolves the problem.

Code: Select all

g0 x30
g2 i0 j#2 y#2
g2 i0 j#1 y#1

[mr_guy99493]

The cutter compensation also has issues for subroutines!

When I simulating this extremely simple gcode program which has cutter compensation in a subroutine, the program repeats lines of code that have already been processed.

The code is very simple: call a subroutine that cuts a helix with cutter compensation enabled. There is only 1 G2 call, and the subroutine is only called once.
The spindle spirals down as expected, then raises to 50 as expected. This is where the subroutine and program should finish, but instead the software decides to repeat the spiral command!
The program finishes with the cutter at Z=0, instead of 50!
This is very dangerous! The software cant manage to follow the simplest gcode programs, and leaves the cutter in a location that is likely to cause a crash!

Code: Select all

g40g90
g0x0y0z0
m98 p2000
m30

o2000              (start sub)
g0 z50y20          (start pos)
g42 d1             (turn on cutter comp)
g2 i0 j-20 y20 z-0 (sprial down)
g0 z50             (raise spindle)
m99                (end sub)