Linuxcnc interprets Freecad postprocessor Gcode lines with big Parameters I and j wrong,

gcode created with FreeCAD consisting of G2/G3 lines with big I an J parameters,

This is what I expected to happen:

loading the gcode with linuxcnc should show the shape of the drawing (a dwarf door)

This is what happened instead:

Linuxcnc shows huge circles

It worked properly before this:

(If the behavior changed after making a particular change in hardware or
software, describe the change you think is responsible. E.g., "after upgrading
from LinuxCNC 2.7.3 to 2.7.4")

Information about my hardware and software:

• I am using this Linux distribution and version (often, shown by lsb_release -a):

• No LSB modules are available.
  Distributor ID: Debian
  Description: Debian GNU/Linux 10 (buster)
  Release: 10
  Codename: buster

• I am using this kernel version (shown by uname -a):

• Linux cnc 4.19.0-18-rt-amd64 use Tcl_SetResult and Tcl_GetStringResult #1 SMP PREEMPT RT Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux

• I am running ...

  • [ x] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
  • A binary I built myself
  • A binary version from some other source besides linuxcnc.org

• I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git):

• I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc):

• AXIS

• I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card):

• MESA 7i76e

Wichteltuer.txt

[andypugh]

This is rather pathological G-code, but it does seem that LinuxCNC is interpreting it incorrectly.
(for example an arc length of about 5mm with a radius of 7km...)
It should be a nearly-straight and short line, but is instead being interpreted as slightly more than a full revolution.

My guess is that the ends are so close together relative to the arc radius that the interpreter is deciding to make a full circle (as it normal ix the start and ends are identical)

[dwrobel]

I'm not sure how this is helpful, but when I copy-pasted the file content into ncviewer (online G-Code viewer) - it looks quite reasonable:

:

[andypugh]

Yes, there is nothing technically wrong with the G-code.

Simple test case

G0 X29.976 Y115.144 Z-3.000
G2 X29.078 Y120.080 Z-3.000 I6253343.722 J1136978.869 F1200.000
M2

I thought that the problem was here, where the code decides whether a full circle was intended:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/task/emccanon.cc#L1662
And whereas it does seem to be based on an arc angle (why? it should just be a check for the start and end points being (double)exactly the same) the limit is 1e-12 and by my calculations the code I extracted has an internal angle of 4.4E-6

Turning on debug logging, it seems that the problem is not happening in emccanon.cc

line = 2
first_end = 29.078000, second_end = 120.080000
start = 29.976000 115.144000 -3.000000
end = 29.078000 120.080000 -3.000000
center = 6253373.698000 1137094.013000 -3.000000
active plane is 1, shift_ind is 0
normal = 0.000000 0.000000 1.000000
plane_x = 1.000000 0.000000 0.000000
plane_y = 0.000000 1.000000 0.000000
end = 29.078000 120.080000 -3.000000
endpt = 29.078000 120.080000 -3.000000
center = 6253373.698000 1137094.013000 -3.000000
normal = 0.000000 0.000000 1.000000
planar end = -6253344.620000 -1136973.933000
planar start = -6253343.722000 -1136978.869000
rotation = -1
radius = 6355865.688797
raw values: theta_end = -2.96173881573440667e+00, theta_start = -2.96173802638150852e+00
theta_end = -2.961739, theta_start = -2.961738
angle = -0.000001
full turns = 0
full_angle = -7.89352898156181482e-07
axis1 = 0, axis2 = 1
a_max_axes = 508.000000
v_max_radial = 52879.157706
v_max_planar = 30.480000
v_max = 30.480000
current F = 20.000000
vel = 20.000000
v_max = 30.480000
a_max = 508.000000

[andypugh]

It looks like there are two bugs here....

1. The preview is wrong
2. The motion is wrong. Less wrong, but wrong.

Firstly, I modified the code very slightly so that the radius to end-points was exactly the same (it was a shade out in the original G-code)
[code]
G0 X29.976 Y115.144 Z-3.000
G2 X29.078 Y120.080 Z-3.000 I6253343.722 J1137665.164 F1200.000
m2[/code]

Then I ran the code, and the tool point flew off out of bounds, but did actually pass through the end point on the way.
The preview actually misses the endpoint. The red is the tool path, the cyan is the preview of the G2.

[andypugh]

Simplified code:

G0 X1 Y -1
G2 X1 Y 1 I 10000000 J 0 F1200
m2

And experimenting with the numbers. I 1999999 is OK and I 2000000 is not.

In the debug:

line = 3
first_end = 1.000000, second_end = 1.000000
start = 1.000000 -1.000000 -3.000000
end = 1.000000 1.000000 -3.000000
center = 1000001.000000 -1.000000 -3.000000
active plane is 1, shift_ind is 0
normal = 0.000000 0.000000 1.000000
plane_x = 1.000000 0.000000 0.000000
plane_y = 0.000000 1.000000 0.000000
end = 1.000000 1.000000 -3.000000
endpt = 1.000000 1.000000 -3.000000
center = 1000001.000000 -1.000000 -3.000000
normal = 0.000000 0.000000 1.000000
planar end = -1000000.000000 2.000000
planar start = -1000000.000000 0.000000
rotation = -1
radius = 1000000.000000
raw values: theta_end = 3.14159065358979328e+00, theta_start = 3.14159265358979312e+00
theta_end = 3.141591, theta_start = 3.141593
angle = -0.000002
full turns = 0
full_angle = -1.99999999983546672e-06
axis1 = 0, axis2 = 1
a_max_axes = 508.000000
v_max_radial = 20974.768297
v_max_planar = 30.480000
v_max = 30.480000
current F = 20.000000
vel = 20.000000
v_max = 30.480000
a_max = 508.000000

Is OK

Whereas

line = 3
first_end = 1.000000, second_end = 1.000000
start = 1.000000 -1.000000 -3.000000
end = 1.000000 1.000000 -3.000000
center = 10000001.000000 -1.000000 -3.000000
active plane is 1, shift_ind is 0
normal = 0.000000 0.000000 1.000000
plane_x = 1.000000 0.000000 0.000000
plane_y = 0.000000 1.000000 0.000000
end = 1.000000 1.000000 -3.000000
endpt = 1.000000 1.000000 -3.000000
center = 10000001.000000 -1.000000 -3.000000
normal = 0.000000 0.000000 1.000000
planar end = -10000000.000000 2.000000
planar start = -10000000.000000 0.000000
rotation = -1
radius = 10000000.000000
raw values: theta_end = 3.14159245358979344e+00, theta_start = 3.14159265358979312e+00
theta_end = 3.141592, theta_start = 3.141593
angle = -0.000000
full turns = 0
full_angle = -1.99999999672684226e-07
axis1 = 0, axis2 = 1
a_max_axes = 508.000000
v_max_radial = 66328.041214
v_max_planar = 30.480000
v_max = 30.480000
current F = 20.000000
vel = 20.000000
v_max = 30.480000
a_max = 507.999999

Is not OK (I confess I was expecting to see the threshold being < -2E-7

[andypugh]

An update: I have a fix for this in the motion layer (ie the machine now moves correctly) and I am working on the preview layer.

In the meantime, I just wanted to suggest a workaround of converting the problem arcs to straight lines by editing the G-code, they are so nearly straight that it will make no visible difference.
You can click the circles in the preview to see which G-code line makes them, then change the G2 / G3 to a G1 and delete the I / J numbers.

[andypugh]

I think I have it fixed, but it involves messing with just about the most critical code in LinuxCNC (second only to straight feed, I guess) so it will need a lot of validation.

[andypugh]

Fixed by ad91118