Not an MPCNC, so I came to off-topic. Because I am STUMPED, I’ve spent the last 3 weeks trying to find an answer, can’t find help anywhere, and this place has the biggest brains I know.
Grbl (enducross fork) with external drivers (DM542), ballscrews, linear rails, kfb 3.0 control board (atmega2560), from cncjs.
This thing is drifting on me. It has been suggested already that my couplers were loose, the grounds on the driver weren’t done correctly, driver current too low, machine binding, maybe a couple more things that I don’t remember now.
I have tried twisting the signal/ground to the steppers(on the x, at least, and when that didn’t work I didn’t bother with the others), verified that there is ZERO slop in the machine, confirmed easy and free movement in each quadrant, so I moved on.
Handwrote some code to run a square in the air a couple hundred times so I could get an idea of the magnitude across a few runs. Well, what do you know…it’s off by exactly the same amount each time.
I home and reset the zero (that’s the marked 0,0), run the program, and send it back to 0,0 only to end up at the second dot.
It does this regardless of speed and acceleration (across 8 different runs or so). If this was lost steps to noise, binding, or slippage, I’d expect it to have a random error.
I reduced the microstepping by half (from 1600 to 800) and got about 2/3 of the error. I inverted the step signal and no change. I learned that vanilla grbl now supports autosquare on on uno, and since I have one I put that on it (back at 1600 for microstepping) and got a little more than half the error. It was suggested I unplug the enable because low=enabled, and that was no different.
I ran my test just a couple dozen iterations, and I got an error not too far from the origin. The code does not drift on my primo.
Whatever is happening is systemic, and stacks with movements (longer program=more movements -> larger error). It’s somehow tied to steps. And the uno creates less of it than the mega.
Next step might be to call a priest.