Do G2 and G3 interpret I and J in 'Incremental IJ mode' or 'Absolute IJ mode'?

[blurfl]

From a discussion in Issue #426. A partner issue in GC #708

There's a good summary here in the section 'Center Format Arc:'. I haven't dug in yet, but I wonder whether we're interpreting I and J in 'Incremental IJ mode' or 'Absolute IJ mode'.

[BarbourSmith]

I believe that we are operating in incremental mode for I and J. From a quick look at the code around line 690 in Gcode.cpp:

    float I       = sys.inchesToMMConversion*extractGcodeValue(readString, 'I', 0.0);
    float J       = sys.inchesToMMConversion*extractGcodeValue(readString, 'J', 0.0);
    sys.feedrate      = sys.inchesToMMConversion*extractGcodeValue(readString, 'F', sys.feedrate/sys.inchesToMMConversion);
    
    float centerX = X1 + I;
    float centerY = Y1 + J;

I think assuming that if the values are omitted to use 0 is a sign that we're in incremental mode, and then the current position + value makes sense for incremental mode.

I'm not sure I have seen gcode generated using absolute mode before...which is strange because for XY coordinates absolute mode is the norm

[blurfl]

That's the center of the issue 😁. Why the problem with a negative relative value for J? Is that an invalid value? It doesn't seem like it should be. Maybe where centerX and centerY are used in Motion::arc() in a atan() calculation to calculate the starting- and endingAngles

[blurfl]

OK, some headway. For the first gcode, Motion::arc() sees these values:

G03 X-1.95 Y1.5 I-8.0 J01
X1 -2.00000000
X2 -1.94999990
Y1 0.00000000
Y2 1.50000000
centerX -10.00000000
centerY 1.00000000
I -8.00000000
J 1.00000000
chordHeight 0.02326965
theta 0.18638710
direction 1.00000000

for the second one:

G03 X-1.95 Y1.5 I-8.0 J-01
X1 -2.00000000
X2 -1.94999990
Y1 0.00000000
Y2 1.50000000
centerX -10.00000000
centerY -1.00000000
I -8.00000000
J -1.00000000
chordHeight 0.02326965
theta 0.17676057
direction 1.00000000

It looks to me like the center of X-10Y-1 is invalid for an endpoint X-1.94Y1.5. Motion::arc() is going to use centerX and centerY to calculate the incremental movement steps that move the bit as g-code simulator suggests. That will result in an endpoint different from the valued X2 and Y2 that the gcode passed to the arc() function. Bam! Position Error.

[BarbourSmith]

Nice work!!!

[blurfl]

And that's the answer.

    // check is centerX,centerY absolute or relatively
    float radius                 =  sqrt( sq(centerX - X1) + sq(centerY - Y1) ); 
    float endRadius          =  sqrt( sq(centerX - X2) + sq(centerY - Y2) ); 

if they don't match, we're using relative mode, and that proves to be true:

G03 X-1.95 Y1.5 I-8.0 J01
radius 8.06225776
endRadius 8.06551265      <----------------
X1 -2.00000000
X2 -1.94999990
Y1 0.00000000
Y2 1.50000000
centerX -10.00000000
centerY 1.00000000
I -8.00000000
J 1.00000000
chordHeight 0.02326965
theta 0.18638710
direction 1.00000000

Sent: G1 X-2.0 Y0.0 F25  
G1 X-2.0 Y0.0 F25
Sent: G03 X-1.95 Y1.5 I-8.0 J-01  
G03 X-1.95 Y1.5 I-8.0 J-01
radius 8.06225776
endRadius 8.42926502        <--------------------
X1 -2.00000000
X2 -1.94999990
Y1 0.00000000
Y2 1.50000000
centerX -10.00000000
centerY -1.00000000
I -8.00000000
J -1.00000000
chordHeight 0.02326965
theta 0.17676057
direction 1.00000000

Now, what to do? Flag an error, or move X2,Y2 relative to I,J?

[BarbourSmith]

This one we could flag when the file is loaded, right? If so I say we show a popup that the file contains some invalid gcode and it can be run, but the results may be unpredictable

[blurfl]

In order to flag it we would need to put the calcs in GC gcodeCanvas, I suppose in drawArc(), yes? I've been trying to figure out the trig to calculate the relative endpoint X,Y, but Mr. Hagberg's trig class was 54 years ago...

[BarbourSmith]

I remember it being complicated and then putting it in the category of "things I would solve when they come up" and nobody has come up with a gcode file that was causing trouble before... 😀

[blurfl]

Working in GC gcodeCanvas::drawArc(), comparing the distance from the I,J centerpoint to the startPoint and to the endPoint, MakerCam does a pretty terrible job of picking an I,J that's equidistant from the start- and endpoints. I guess mostly it doesn't matter, as we don't often see issues, but how to tell when it will matter?

Rounding is a possibility, using the Advanced Setting 'digits' (though the wording might be changed to 'Rounding instead of 'Truncate').

How about, instead of failing to load the questionable gcode, we put a line in the log like

Invalid relative-mode G2/G3 command in line 113
   G3 X20.4580 Y9.884 I-0.301 J2

Also, how about making that line segment some bright color, and maybe fatter as well? Then we can troubleshoot bad gcode files before anyone has wasted plywood 😁

[BarbourSmith]

How about, instead of failing to load the questionable gcode, we put a line in the log like

Invalid relative-mode G2/G3 command in line 113
G3 X20.4580 Y9.884 I-0.301 J2
Also, how about making that line segment some bright color, and maybe fatter as well? Then we can troubleshoot bad gcode files before anyone has wasted plywood 😁

I think both of these are phenomenal ideas