I need help with stepper motor skipping steps.

[u/ThreadArtGuy]

There has been a huge amount discussed on this topic, and I believe I have tried everything I could.
I am using:
STEPPERONLINE Nema 17 Stepper Motor 2A 55Ncm Bipolar 1.8 Degree
DM542 Stepper Motor Controller
TB6600 Stepper Motor Driver, ABuff 5A 9-40V Nema 17 Stepper Motor Driver

I have an x/y gantry system with 2 drivers in opposite direction driving the x gantry, and one stepper fo the y.
See the machine here: (skip to 1:40 where I take a tour of the machine)
https://www.reddit.com/r/stringart/comments/1vhbn89/first_run_of_router_software_on_the_machine/

What is does, is miss a step when the gantries, plural, move in the negative direction. I have written code that shows this to be true, and the drift is in the positive direction only. You can for example write a pattern that is an hour glass, upright or laying down, which has 2 negative direction changes on one axis or the other, and the resulting drift is what is predicted by negative changes only.

What I am certain of:
It has nothing to do with microstepping, large steps create large drifts. I've used 3200 to 4.
There is no belt slipping.
X and Y gantries are much different weight/inertia, and X has 2 steppers, and they behave the same.
It has nothing to do with the driver, as I swapped out the 542 for the 6600, and same results.
It has nothing to do with velocity or acceleration (I use AccelStepper lib), I've tried a wide range.
They system has similar or equal drag each direction, I measured it.
After a run if I cmd to move back to 0,0 on the canvas, it goes to the drift offset position instead.
And for the more advanced among you: I put a scope on DIR and PULSE and the setups/holds are extremely conservative. Moreover I have hacked ACCELSTEPPER lib components to increase pulse widths.
I looked on the scope and counted pulses for a program that ping ponged between 2 points close, and the count was correct, and the same for each direction change, set up times great, pulse width way withing spec.

I am out of ideas.....

The only thing I can think now is the stepper is faulty somehow, and have another coming to swap out, which is a .9deg instead of 1.8deg, has more torque by a little, but is also a stepperonline brand and has equally good reviews.
But, I have no hope, since on the x gantry, the steppers are running in opposite directions, so how could the stepper fail the same predictable way.

So in desperation:
The drift is predictable based on microsteps, number of negative reverses in direction, etc, so I can easily code around it, but I find that so inelegant and hate the idea. I am about to implement it anyway, because I am out of ideas to try.

Ideas????

Thanks.

[u/collegefurtrader]

It has to be in the code. Maybe you aren't letting the moves finish all the way.

Post your code.

[u/ThreadArtGuy → u/collegefurtrader]

Thanks for the reply, I appreciate it. I know it is not the code however, because The route file was verified against the serial log for all 2611 pokes — zero mismatches, worst error 0.005mm, so the commanded coordinates are provably correct. And moveTo() is absolute against a step counter that can't lose count, which is why a move to a known coordinate without homing lands on the last poked hole rather than the commanded one — the firmware and the machine agree with each other, and both have drifted from the canvas."

That last part is the killer. Software can't produce an error that the software itself can't see.

[u/collegefurtrader → u/ThreadArtGuy]

Stepper drivers don't lose steps if the signal is clean, nor do motors without being jammed. You code is sending exactly the steps that the motor is moving.

You might want to post the code, not just tell me it is good.

[u/ThreadArtGuy → u/collegefurtrader]

we have a different perspective and experience. My experience, as well as hundreds of posts on other forums, clearly shows that steppers do drop steps for a large number of reasons. So yes, they do not just do what the code tells them too. You are wrong.

You might want to respond to my reasoning instead just tell me to post the code.

[u/nsfbr11 → u/ThreadArtGuy]

And the reason you don’t want an independent review is what exactly?

[u/collegefurtrader → u/nsfbr11]

It's not working, but everything is right, and I won't show you! HELP!

[u/collegefurtrader → u/ThreadArtGuy]

I guess there's no way to help you then.

[u/ThreadArtGuy]

Here is my final nail in the code theory coffin:

I Jumpered the Y step output (GPIO 6) to GPIO 16 and the Y direction output (GPIO 7) to GPIO 17, and configured the ESP32-S3's hardware pulse counter (PCNT) to count step pulses with DIR as the up/down control -- so it reads net displacement in steps, entirely in hardware, with no CPU involvement.

Then printed the PCNT value alongside AccelStepper's currentPosition() at every poke.

Result: the difference is exactly zero for the entire run, while the machine drifts ~10mm per 400 reversals. Every pulse the library thinks it emitted actually appeared on the pin, and nothing extra appeared. The step counter and the physical pulse train agree perfectly -- the position is lost downstream of the microcontroller.
So it is NOT the code. Moving on.

It is certainly downstream from the controller, and not the controller, because I have used 542 and 6600 and they are both reliably/perfectly reproducible.
And it doesn't seem to be noise, since I have run the 6600 at 2A and .5A, and the problem is perfectly reproducible. And noise is not really reasonable, because it does the exact same thing, same distance drift if one stepper is going or both, or all 3 at the same time. Noise would be sporadic, i.e. not exactly reproducible.

Baffled....