Slow pulse timings

[ahdinosaur]

Hi,

(No worries Hanno if you're busy 💜 )

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-L84 Oops 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.
• Reason 2: The pulse timer is set after some calculations, not immediately, and does not take into the clock cycles (time) spent doing the calculations.

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.

[hannobraun]

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!