In some cases when move_step_no is equal to rampup_steps, this
algorithm think it is cruising. When cruising it setup the dda->c
to dda->c_min. Which is wrong in that case.
So we let recalculate the dda->c now. The axis will become a little
bit faster for none-cruising movements. When it hits cruising,
it will be capped anyway to dda->c_min. So the "TODO: check is obsolete"
is not obsolete anymore.
Before, a seemingly valid command like ...
./sim -o sim-log.log -t 0 testcases/triangle-odd.gcode
... would not act as expected (treat both files as G-code source)
and not give meaningful hints on what's going on either. It just
reported 'Could not stat file'. No hint that it tries to open the
intended log file as G-code source.
Now the message reporting opening of a G-code file names it as
'G-code source' and opening of the recorder file gets reported,
too. Which should give a good idea about what's going on.
Adjustments by Traumflug:
- Rebased to current 'experimental'.
- Some whitespace adjustments.
- Renamed labelWidth_homing to labelWidthHoming.
- Fixed an issue in printer.py which would write only the first
character of an option ('x' instead of 'x_positive', 'n'
instead of 'none', etc.)
Thank you very much for the code, Matt!
Only real relative mode with M83.
G91 moves the E-axis relative but position will be absolute.
M83 moves the E-axis relative. Position will be also relative.
Compiler are pretty smart today. sqrt is precalculated for constant values.
E.g. you need to #include <math.h>. But no need to link the libmath.
cos/sin and other stuff should also work.
In dda.c we have some limitation factors. e.g. the calculation
for the move_duration. 'distance * 2400' should be everytime below
UINT32_MAX.
Maybe we find later an other limitation factor. So you can
modify it now in dda.h.
In the endstop_trigger case, we look, if will are cruising.
-> Yes: Take the rampdown_steps for calculation
-> No: We are still accelerating. So we want to decelerate the same amount of steps.
We've got with -Winline:
usb_serial.c:761:13: error: inlining failed in call to 'usb_wait_in_ready': call is unlikely and code size would grow [-Werror=inline]
We want to inline this in the USB ISR. So let's force it and prevent the error.
This script is now reliable enough to no longer need investigation
stops.
One can still stop an ongoing step-rebase by hitting Ctrl-C, then
doing a 'git rebase --abort'.
Git provides a mechanism to record conflict solutions done with
one rebase and replaying that when rebasing another branch. That's
what's Rerere is about. Unfortunately, a rebase still stops after
resolving all conflicts with recordings, so convenience is a bit
limited.
If Rerere is disabled in a repo or there are no recorded solutions,
this option has no effect.
Without --first-parent, 'git rev-list' counts commits on merged
branches, too. Not noticed on Teacup, because we have no merges
here, but in another repo this came up.
Standard mode, like without ignoring whitespace changes. Only if
that fails, try again with whitespace ignorance.
Reason for this attempt is, rebases not ignoring whitespace are
significantly faster and much less verbose. As 99% of all rebases
work fine without ignoring whitespace, it's a good idea to try
that first.
We don't need to save the step_no. We can easily calculate it when needed.
Also some whitespace-work. In dda.h is only a delete of 'uint32_t step_no;'.
Saves up to 16 clock cycles in dda_step():
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 209 clock cycles.
LED on time maximum: 504 clock cycles.
LED on time average: 241.441 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 22589.
LED on time minimum: 209 clock cycles.
LED on time maximum: 521 clock cycles.
LED on time average: 276.729 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 209 clock cycles.
LED on time maximum: 504 clock cycles.
LED on time average: 262.923 clock cycles.
Justus Winter
Nico Tonnhofer
Markus Hitter
Matt Gilbert