G19 with G91 - dangerous error

[hmnijp]

G19 in the relative distance mode (G91) sends the machine into space, beyond the limits. It looks like the line is being run in G90 mode. No absolute->relative switching.
But the visualization of the path is drawn correctly.

Identical code but with G18 - no problem.
Identical code with G19 but in absolute distance mode - no problem.

Code: Select all

(wrong G19 in G91)
G90 G94 G40 G49 G17

G64
G54
G0 X12.196 Y39.
Z35.

G91
G0 Z-30.
G1 Z-8. F500
G19 G2 Y-2. Z-2. J-2. K0. F1000
G1 Y-2.
G17 G3 X2. Y-2. I2. J0.
G1 X15.804 F1500
G2 X3. Y-3. I0. J-3.
G1 Y-30.
G2 X-3. Y-3. I-3. J0.
G1 X-30.
G2 X-3. Y3. I0. J3.
G1 Y30.
G2 X3. Y3. I3. J0.
G1 X16.197
G3 X2. Y2. I0. J2. F1000
G1 Y2.
G19 G3 Y2. Z2. J0. K2.
G0 Z38.
G90
M30

I have attached code examples.

wrong G19 in G91.nc

(398 Bytes) Downloaded 682 times

correct G18 in G91.nc

(391 Bytes) Downloaded 642 times

correct G19 in G90.nc

(398 Bytes) Downloaded 641 times

[cncdrive]

It can happen not only with G19.
G91 with arcs can cause problems if run step by step, because if you stop in the middle of the arc and run again then the arc will be different as when viewing the g-code file in total.
This is because arcs are programmed with the endpoint and the center point. The starting point is defined in the previous line which contained movement.
As in G91 mode the endpoint and the center are increments to the starting point therefor if the arc is stopped and restarted causes a different arc which can differ so much that it could cause machine crash.
So, I'm not a fan of programming arcs with G91 at all.
It can be useful sometimes, but can be also dangerous.

So, the question is: Did you run the g-code program from start to end without stop and restart?

[hmnijp]

So, I'm not a fan of programming arcs with G91 at all.
It can be useful sometimes, but can be also dangerous.

So, the question is: Did you run the g-code program from start to end without stop and restart?

yes, it run without stop/hold/restart... An error occurs on the first arc of G19 inside G91.
I noticed this using a pattern - a large program using subroutines - M98P0001, move, M98P0001, move ..., ... O0001 G91 this code ... M99. In my practice, G91 is used only for such a case.

I did some tests, changing the code, and the error was only on the G19 G2 / G3 arc, but the G18 / G17 arc always worked correctly ...
And the simulation always drew the path correctly, in all cases.

If the G18 / G17 arcs are working correctly, maybe the G19 can also be fixed?

[cncdrive]

OK, the stop/run was just my first thought as a possible cause for the problem.
But I will test and study your code later to see why is it happening.

[hmnijp]

Please check this primitive code.

Code: Select all

G19
G90
G0 X0. Y0. Z0.
G91
G1 Z10
G2 Y10 Z10 J10 K0
G1 Y10
G2 Y10 Z-10 J0 K-10
G1 Z-10
Y-30
M30

The machine should return to (0.0.0) but its final coordinates (10.-10.-10)
There is no X movement in the code, but it is offset.

[cncdrive]

OK, I will need some time to debug it, but will do it asap.

[hmnijp]

Ok! Thanks you!

[hmnijp]

Hi. When will the bug be fixed?
There are no changes in the new release - the movement of the machine does not match the code.

[cncdrive]

This was not fixed yet, but was noted and will try to fix it for the next release.

[cncdrive]

We've found the reason for this problem, it was a bug in the UCCNC core code about that exact case when G91 incremental mode is used on the G91 plane.
The endpoint position was then not correctly calculated in some cases.
The problem got fixed now and your G91 G19 codes work fine, it will be in the next release.