As we can always only move towards one end of an axis, one common
variable to count debouncing is sufficient.
Binary size 12 bytes smaller (and faster).
Previously, when backing off of X_MIN, X_MAX was also checked,
which of course was already open, so it signals endstop release
even while X_MIN is still closed. The issue exposed only when
endstops on both ends of an axis were defined, a more rare situation.
Essentially the fix simply makes a distinct endstop check case
for each side of each axis.
This even makes binary size 40 bytes smaller for the standard case.
Offending code were lines like these from Repetier Host:
N8965 M117 ETE 29m 10s *86
When firmware received not-G command (M-command or T-command) with X, Y,
Z, E or F coordinate, it will "change" this command to G1.
Now, firmware do change only if received line is not either G- or M-
or T-command.
Examples:
X10 - is changed to G1 X10
E20 F300 - is changed to G1 E20 F300
M117 E1 - is NOT changed to G1 E1
This commit costs 6 bytes binary size.
This also introduces dda_kinematics.c/.h and a KINEMATICS definition,
which allows to do different distance calculations depending on the
bot kinematics in use. So far only KINEMATICS_STRAIGHT, which matches
what we had before, but other kinematics types are present in
comments already.
Goal is to calculate steps in a separate function to allow different
methods of steps calculation, which is neccessary for supporting
different kinematics types. Accordingly we have to calculate steps
for all axes before setting directions and such stuff.
Note by Traumflug: this
while read -r LINE; do
some commands
done << (some other command)
didn't work here (bash 4.3.11 on Ubuntu 14.04), so I had to swap
the sequence of these two commands for using a pipe. Anyways,
excellent idea, shortens some simulator runs drastically!
Finally had to look it up myself. RAMPS users are apparently all
incapable or too stupid to write such fixes into an issue report.
From IRC:
xxx: oh, motors move now, thanks for helping
yyy: please write the changes into a github issue
xxx: will do
...
xxx: have to run now
... and these are the last words the world reads about xxx :-)
Observed three times now.
This is mostly for less confusion, because analog pins can
be used as digital ones, too. It also matches what other firmwares
do, so people can simply copy & paste pin definitions.
Definitions were taken from Sprinter's fastio.h (which was
initially crafted by copying Teacup's arduino*.h files :-) )
This was the goal: to not bit-shift when calling setTimer(). Binary
size another 40 bytes off, about 1.2 % better performance:
SIZES ATmega... '168 '328(P) '644(P) '1280
FLASH : 20136 bytes 141% 66% 32% 16%
RAM : 2318 bytes 227% 114% 57% 29%
EEPROM: 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 302 clock cycles.
LED on time maximum: 718 clock cycles.
LED on time average: 311.258 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 9124.
LED on time minimum: 307 clock cycles.
LED on time maximum: 708 clock cycles.
LED on time average: 357.417 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 302 clock cycles.
LED on time maximum: 708 clock cycles.
LED on time average: 330.322 clock cycles.
Admittedly it looks like advancing in babysteps, but really
catching every bit shifting instance isn't trivial, sometimes
these shifts are already embedded in other calculations.
Still no binary size or performance change.
While this shifting meant to increase accuracy, there's no actual
use of it, other than that this value gets shifted back and forth.
Let's start to get rid of it.
Performance stays exactly the same:
SIZES ATmega... '168 '328(P) '644(P) '1280
FLASH : 20188 bytes 141% 66% 32% 16%
RAM : 2318 bytes 227% 114% 57% 29%
EEPROM: 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 306 clock cycles.
LED on time maximum: 722 clock cycles.
LED on time average: 315.253 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 9124.
LED on time minimum: 311 clock cycles.
LED on time maximum: 712 clock cycles.
LED on time average: 361.416 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 306 clock cycles.
LED on time maximum: 712 clock cycles.
LED on time average: 334.319 clock cycles.
Markus Hitter
konoppo
jgrjgr
Michael Moon
Erik Jonsson