Raspberry Pi 4 with Mesa 7c81

.hal and .ini

Gcode for sample rectangle

G90


G17

G0 Z.1


G0 X0 Y-2.4375


G1 Z-.0625 F5

G1 X-4.09375 F20

G02 X-5.71875 Y-1.1125 R1.625

G1 Y1.1125

G02 X-4.09375 Y2.4375 R1.625

G1 X4.09375

G02 X5.71875 Y1.1125 R1.625

G1 Y-1.1125

G02 X4.09375 Y-2.4375 R1.625

G1 X0

I missed your other question regarding whether the tool returns to the correct path after the error...

The tool continues on as though the error was part of the 'correct toolpath'. If I make multiple passes with the same code the error occurs in a similar location but not the same error each time.

One other thing worth mentioning is that on the ellipse the errors occured on the first and third curves.

I stopped the test rectangle as soon as the error occurred but I will run it again to confirm same action.

Interesting that the second and fourth curves ARE the curves where there is a motor reversal, albeit at the beginning of the curve, and no error there while the first and third curves the motors are only moving in one direction throughout and there is error

Is it possible you have a motor stall?

I really don't think so. It seems like a computational error being that it makes the same error cuts in different places.

Also I don't lose position and I assume if a motor stalled I would lose steps.

The cuts were very light as well. .0625" doc at 20ipm with a 2hp spindle in mohagany

Pretty strange,I would think It would have to be an error before trajectory
planning to not violate the acceleration constraints and thereby cause a following error .

Loose coupling?

It's totally strange. My thought is to try something to definitively say that it is not the 7c81 but I can not think of a way to do that. Open to suggestions for that or anything else!

Not a loose coupling

One more thing I just thought of...

I reversed the cutting direction of the ellipse. In the opposite direction the error still occurred in the first and third curves. So no matter which direction it is moving it botches the first and third curves

I still think its either mechanical or lost steps (drive related?) somehow.
Not really anything the 7C81 can do unless its fed a bogus trajectory that still obeys the
velocity and acceleration constraints and at the same time doesn't show up in the backplot.

I have checked everything mechanical. That was the easy part!

Also its too predictable in that it happens in the same places, curves one and three. I can manually command the machine back to zero and it is perfectly aligned. If I restart the program again it will do the same thing in the same place.

I just thought to try a G61 code...?