Traumflug

Nice graphs you have there. Just 7% error on such long moves is actually less than what I expected. (2) sounds good. Looking at dc42's code I currently see no...

You're right, it's 2 milliseconds. Can be changed to 1 or 4 ms without further code modifications. Regarding axes reversing: good point! Direction is given in dda_start() and isn't rewritten...

> I am in the process of setting up the simulator to try to see what is going on. I just noticed SimulAVR chokes on a firmware compiled for an...

> If the define STEP_INTERRUPT_INTERRUPTABLE is 0, then dda_clock is never called (or never completes a call) for faster feed rates, or is rarely called for modest feed rates (60...

``` #if ... ! defined ACCELERATION_RAMPING sei(); #endif ``` So, with ACCELERATION_RAMPING the sei() doesn't happen and the global interrupt flag stays cleared, disabling all interrupts. That said, your snippet...

Perhaps you've seen it, there's a re-entry protection some 20 lines of code into dda_clock(). It's certainly a good idea to update the clock counter before this.

> Which clock counter? If you want to calculate on movement time you ineviteably have to keep track of how much time has passed since the movement started. Currently there...

Yes, you're right. I actually missed this when doing clock based acceleration (for ACCELERATION_RAMPING), thanks for showing it. Looking at it, I see a few caveats: - move_state.last_time isn't reset...

@NickE37: Perhaps you've seen it in issue #121, I rewrote step scheduling for ACCELERATION_TEMPORAL. It's on the interruptreliability branch, especially the last 3 commits. To my tests dda_clock() works reliable...

Nice! These observations at least show it's apparently pretty reliable to calculate across multiple calls. Yes, your math is complex. It looks even a bit more complex than dc42's. ATmegas...