Hello!

Recently i encountered funny bug https://www.machsupport.com/forum/index.php?topic=49270.msg302793#msg302793 . It happened after i homed the y/b axis many times to calibrate squareness (but interestingly the first tool zeroing after calibration went perfectly fine).

But today i discovered even more funny bug! And now i even have g code to replicate it.

I cut some mdf parts by 4 at once using g52 command to shift coordinates. It went perfectly fine, except i had stock slightly smaller than needed so i had to stop the job manually slightly before the proper end. Also it included several tool changes which also went fine. But after this i tried to change tool to 0 (no tool) and saw the head heading to the point where no tool hanger is present! So i had to manually stop the machine.

When i printed the actual command that generated that move, i found it is perfectly correct:

G0G53 X1574Y68.5

, whereas de facto destination X was 2054, which differs from 1574 by 480, i. e. exactly G52 offset of the last part i had cut. But then i looked at the "diagnostics" screen and found all the g52 offsets are exactly zero! Despite i do not remember i zeroed it manually, and after manual stop they should remain the same. Regardless of this, as you can see, the aforementioned movement command is issued in G53 key, i. e. in the most absolute machine coordinates ever possible! So regardless of any g52 or any other offset it should lead us to exactly the same machine coordinates every time, namely the coordinates mentioned in the command! But clearly this is not the case.

So i dare to say we have severe felony here.

But who is guilty? As you could see, i am innocent. So i have two candidates: mach3 and the motion controller ("eth-mci", or more likely its driver plugin).

At one point i had to reset, so this effect was gone. I ran simplified version of the unlucky code:

G017 G21 G49 G80 G90 G91.1
M6 T9
G43 H9 G0 Z50.0000
(Tool Number:9) (8.000 mm dia. slot drill)
M3 S15000
M98 P1005
M5
M30


%


O1001 ; not called, maybe not needed
G52 Y0
M98 P2001
G52 X0Y0
M99

O2001 ; not called, maybe not needed
G52 X0
M98 P3001
G52 X160
M98 P3001
G52 X320
M98 P3001
G52 X480
M98 P3001
M99

O3001 ; not called, maybe not needed
M99

O1003 ; not called, maybe not needed
G52 Y0
M98 P2003
G52 X0Y0
M99

O2003 ; not called, maybe not needed
G52 X0
M98 P3003
G52 X160
M98 P3003
G52 X320
M98 P3003
G52 X480
M98 P3003
M99

O3003 ; not called, maybe not needed
M99

O1005
G52 Y0
M98 P2005
G52 X0Y0
M99

O2005
G52 X0
M98 P3005
G52 X160
M98 P3005
G52 X320
M98 P3005
G52 X480
M98 P3005
M99

O3005
(Tool Number:9) (8.000 mm dia. slot drill)
M3 S15000
G0 X1.0000 Y0.0000 Z50.0000
G1   Z40.0000 F3000
G1 X1.0000 Y285.0000  F7000
G0   Z50.0000
G0 X79.0000
G1   Z40.0000 F3000
G1  Y0.0000  F7000
G0   Z50.0000
G0 X81.0000
G1   Z40.0000 F3000
G1  Y285.0000  F7000
G0   Z50.0000
G0 X159.0000
G1   Z40.0000 F3000
G1 X159.0000 Y-0.0000  F7000
G0   Z50.0000
G0 X0.0000 Y0.0000
G0 Z50.0000
G0 X0.0000 Y0.0000
M99

I also stopped it (first "feed hold", then "stop", then "close g code") slightly before the end. This time the g52 offset was conserved and was still equal to 480, which it should be in the first case. And when i issued tool change command, this time it went to the left to the correct position (previous time it went to the right)! Then i tried to move the machine with simple g0 - it worked fine. But when i commanded G53G0X550, it went not to 550 machine X, but to 390! So this time the shift is not 480, but -160, which is negative offset of the second part (while g52 offset is still 480).

Also this makes my homing procedure impossible, cos it involves slight move from zero, which now is performed to the point beyond the limit switch. Another fun effect is it says "Machine out of limits for SoftLimit Activation.", albeit all machine coordinates are well within soft limits, even regarding aforementioned machine coordinate shift.

So the question is: do you observe this (or maybe another) bug after running this code?

Thanks in advance.

Mach3 version is R3.043.066.

> Its not a fault its a feature that has to be used properly and with care.

Are you really sure that g52 should affect motion in machine coordinates? And should affect it by amount not equal to the g52 offset value displayed at the "diagnostics" screen? And if you are, can you post some evidence for such a bold claim?

I tried older driver/firmware for eth-mci and mach3 Version R3.043.062 demo and got exactly the same bug.

But then i found that mach3 shows not the actual g52 offset, but offset from the future! So i thought it may have something to do with lookahead parameter which i had recently set to 200 as some man from youtube advised.

I set the lookahead to 2. And the bug was gone! So it most likely is mach3's own poor future prediction issue, so i will never get a fix, unless somebody decides to revive mach3 development.

Another fun thing is mach3 shows (on "diagnostics" screen but also with message getoemdro(16)) g52 from the "future", actually uses g52 from "present" and shifts g53 movements by g52 from the "past" (sometimes with negative and sometimes with positive sign).