Can't get LinuxCNC to stop taking "shortcuts"

I randomly get situations where LinuxCNC is not following the gcode precisely, instead taking shortcuts. I have configured G64 as follows:

RS274NGC_STARTUP_CODE = G17 G21 G40 G49 G64 P0.001 G80 G90 G94 G97 G98

And

ARCDIVISION = 32
CYCLE_TIME = 150

The shortcut has a radius of approximately 1-2mm and is not in the gcode program. I double checked it by opening it in another CAM, where the path is shown correctly.

Any hints? The full machine config is here.

 

I should add:
BEFORE configuring "G64 P0.001", I had the problem in the XY direction.

AFTER configuring "G64 P0.001", I have only now seen the problem again - but this time in the XZ direction: While moving up in Z out of a hole, X starts already moving.

• G61 - exact path mode. G61 visits the programmed point exactly, even though that means temporarily coming to a complete stop.
• G61.1 - exact stop mode. Same as G61

Ok, that would be an "extreme" zero-tolerance measure and much slower.

But why does G64 P0.001 apparently not work here? Shouldn't that force the machine to stay within 0.001 machine units of the ideal path?

No, I just used the "Start" button.

I'm running LinuxCNC 2.8.4-1-gb7824717b.

You should try make bigger lenght of steps. Sometime cheap drivers use lowcost optocouplers and step signal is loosed.

Edit:
I looked at the picture again and realized that it probably wouldn't be the fault of losing a step.

You can try decrease:
FERROR = 10.0
MIN_FERROR = 1.0
This can help you test machine off.

Then you can try increase:
STEPGEN_MAXVEL = 250
STEPGEN_MAXACCEL = 1875
I use 100% larger.

Then you can try decrease P in PID.
PnConf use default value 1000.

Then you can try velocity mode.
control-type     1

 

Yes, I would lower the following error limits to see if its a setup error
in the hal or ini files causing a following error.

I would not use larger than say .02 mm for limits, and when properly setup
a 0.005 mm local feedback error should never happen.