GRBL arc validation failure after rotating 90 deg ccw

[MarkHerhold]

Hi, after rotating the attached gcode 90 degrees ccw, grbl fails with code 33. I'm guessing the arc transformation is not quite in agreement with grbl's arc validation code.

The line of gcode in question (this is after ccw rotation) causing error 33:

(2D Contour1)
G0 X25.715 Y30.635
G1 Z15 F1000
Z5
Z1 F100.3
Z-0.365
G19 G3 Y30.635 Z-1 J0 K0 F100 X25.08 # error 33
G1 Y30.635 X24.445
G17 G3 X23.81 Y30 I-0 J-0.635
G1 X23.81 F1000 Y-30

Originally, the relevant gcode was:

(2D Contour1)
G0 X30.635 Y-25.715
G1 Z15 F1000
Z5
Z1 F100.3
Z-0.365
G19 G3 Y-25.08 Z-1 J0.635 K0 F100 # notice that J had a value pre-rotation
G1 Y-24.445
G17 G3 X30 Y-23.81 I-0.635 J0
G1 X-30 F1000

gcode prior to rotation 90 deg
floating-shelf-bracket.txt

gcode after rotation 90 deg
floating-shelf-bracket-90ccw.txt

The latest version of bCNC cloned from github seems to produce the same code.

[MarkHerhold]

I really don't know what I am looking at and might not be helping, but it seems that because self.cnc.plane is 2, (plane YZ), both I and J values don't get translated.

new["J"] = s * i + c * j
where:
s: 1
i: 0
c: 0
j: 0.635
making new["J"] = 0

[MarkHerhold]

I figured out the issue. In short, the G19 move exists on the YZ plane. To properly rotate this 90 degrees CCW, we would have to actually change the command to the XZ plane (G18). While that could be implemented fairly easily, this gets really complicated if the rotation is not an exact multiple of 90 degrees because the move would exist as partial components on both planes (not confined to just one plane).

In short, I think the proper fix here would be in two parts:

1. bCNC should show an error and not attempt to rotate G18/G19 commands. G17 works fine.
2. bCNC should adopt a completely different approach to rotating code. I don’t have enough knowledge to comment further here or recommend an approach.