Open ahdinosaur opened 2 years ago
Thanks for reporting this, @ahdinosaur!
I've had problems in the past when running programs in dev mode. I think this library definitely needs optimizations enabled. As far as I remember, this was a pretty obvious issue though, nothing I needed a logic analyzer to track down. That's the only known timing-related issue (that I can remember).
I don't remember how thorough my testing was, before development was halted. I got this library to a point where it provided smooth motion, but it could be that I never got to confirming the timings with a logic analyzer. So it might be that there's some systemic problem, i.e. your reason 2.
So, not sure. This could use some thorough investigation!
Hi,
(No worries Hanno if you're busy :purple_heart: )
I'm using
stepper
and as far as I can tell with a logical analyzer, the actual pulse timings are always longer than the calculated pulse timings, i.e. the stepper speed is slower than expected.I can think of a few reasons why, but am wondering if this is a known issue or if I'm doing something wrong.
Reason 1: The direction is set every pulse, including with delay, even if the no change from previous direction: https://github.com/braun-embedded/stepper/blob/03e9c56/src/motion_control/state.rs#L73-L84Oops now I see this would only happen at the beginning of a new motion, not on every step. Changing this had no effect on the pulse timings.In my case, I don't need 100% accurate timings, I can just as easily bump up the stepper speed, but raising this issue in case.