To trzeba wytłumaczyć zupełnie inaczej.
Po pierwsze, są dwa sposoby zapisu G2/G3, z długością promienia (R) lub punktem zaczepienia promienia (IJK).
Matematycznie te zapisy są to równorzędne, ale w praktyce używa się tego, który w danej sytuacji jest łatwiejszy do zastosowania.
Tutaj mamy zapis z IJK więc dalej będziemy mówić tylko o tej wersji.
Linia kodu zawiera współrzędne punktu zaczepienia promienia i współrzędne końca łuku. Nie zawiera natomiast ani długości promienia, ani współrzędnych początku łuku. Promień da się obliczyć, a za punkt początku łuku przyjmuje się współrzędne końca poprzedniego ruchu.
Na przykład:
Czyli z punktu X0,Y0 jedziemy do punktu X0,Y2 promieniem o długości 1 zaczepionym w punkcie X0,Y1.
Jak można zauważyć, niektóre parametry nie są podawane jawnie, bo w g-kodzie obowiązuje zasada, że wartości która w danej linii się nie zmienia nie trzeba podawać.
Teraz wróćmy do przedmiotowego błędu.
Podany wyżej kod wykona się bez problemu, bo wszystkie podane współrzędne zgadzają się ze sobą.
Teraz napiszmy kod z błędem:
Czyli z punktu X0,Y0 jedziemy do punktu X0,Y3 promieniem o długości 1 zaczepionym w punkcie X0,Y1, co jest oczywiście niemożliwe, więc LinuxCNC wywali błąd:

I dokładnie z taką sytuacją spotkał się autor wątku.
Przyczyny mogą być różne, ale ponieważ program jest generowany przez CAM, oczywiste błędy rachunkowe bym odrzucił, jako mało prawdopodobne.
Raczej stawiam na to, że kod jest poprawny, ale zapisany w innym dialekcie niż używany przez LinuxCNC.
Zwykle takie cuda dzieją się kiedy współrzędne przyrostowe są interpretowane jako absolutne, albo na odwrót.
https://linuxcnc.org/docs/2.6/html/gcod ... 90_1-G91_1