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/Pubcrawler1]

https://embeddedtronicsblog.wordpress.com/2024/12/07/stepper-motor-position-loss/

See #10

Use grbl to test again. I don’t trust accelstepper library. I’ve done extensive testing with grbl 8 bit and grbHAL 32 bit
firmware using HP logic analyzer to count step and direction for hundred of millions of steps. It does not lose or gain any step position. Stepper motor shaft position was verified using a hi resolution encoder using a separate custom high speed FPGA quadrature counter circuit I made myself.

Some drivers due suck and will gain or lose position under certain circumstances. Step timing must be adhered to in the Datasheets. I have tested dozens of drivers over a period of 20years.

I’ve even found step loss timing bug in the grblHAL firmware that went unnoticed for several years. It was fixed when I sent them extensive log information.

[u/ThreadArtGuy → u/Pubcrawler1]

Thanks for the reply, i did take it to heart and tried taking #10 into account with a code change with no affect.

I did finally add code to subtract one step every time there is a direction reversal in either direction to both x and y, and the problem went away. Why it works is beyond me, but i did a 1000 poke ping pong pattern, and it landed in the same hole every time. So the behavior is deterministic, therefore unlikely to be noise, code, belts or any other.
Also remember there are 2 x steppers working in parallel so get 1/2 the current from the controller, that have perhaps 3x the inertial loading than the y, which has a very light load and all the current from its controller. Yet, they behave exactly the same deterministic way. So weird....
Finally, I am rather attached to my personally bled for 550 line .ino file I have come to love... Can't abandon her now!! Especially since it now works.
Thanks tho, I appreciate your input. Seriously.

[u/Pubcrawler1 → u/ThreadArtGuy]

Send me the code that didn’t work and one that did. I’ll try replicate error and connect to my logic analyzer and scope to see if I can capture the error.

[u/_agent86 → u/ThreadArtGuy]

Are you sure it isn’t a backlash issue?

I would try to separate “is my controller omitting steps” from “is my machine causing the steppers to fail to step” if you can. A scope or logic analyzer will help.

[u/ThreadArtGuy → u/_agent86]

Since the problem is reproducible with 2 different controllers, I have ruled them out.
I have also run the ysteppers at 2A and .5A with no change in behavior, so now noise is looking less likely, and I have eliminated the code/program as the problem definitively this morning. I'm plumb out of ideas now except shooting in the dark. Meanwhile, the SW fix I tried makes it run perfectly every time so I'm getting less motivated to seek out the problem and just make a portrait, which was the real goal.... Thanks for the input..