The binary size impact is moderate, like 18 bytes plus
4 bytes per endstop defined.
The story is a follows:
The endstop logic can be used to use a touch probe with PCB
milling. Connect the (conductive) PCB surface to GND, the
spindle/mill bit to the signal line, turn the internal pullups
on and there you go.
However, doing so with pullups always enabled and while milling
under (conductive) water showed polished mill and drill bits to
become matte after a few hours of usage. Obviously, this small
0.5 mA current from the pullup resistors going through the
rotating mill bit is sufficient to get some spark erosion going.
That's bad, as spark erosion happening also means tools become
dull faster than neccessary.
With this patch, pullups are turned on while being used, only,
so this sparc erosion should go away.
Remove the assumption there's always an extruder temperature
sensor and make reading on single sensors (e.g. M105 P2) more usable.
Apparently works very well, but *sigh* yet another 100 bytes of binary size.
There were a whole bunch of cases where P and/or S were used without
checking for the validity of the value. This led to all sorts of
confusion, for obvious reasons.
These were commits 9dbfa7217e0de8b140846ab480d6b4a7fc9b6791 and
2b596cb05e621ed822071486f812eb334328267a.
There are several reasons why this new approach didn't work out well:
- The machine coordinate system is lost on relative movements.
OK, we could keep tracking it, but this would mean even more
code, so even more chances for bugs.
- With the lost coordinate system, no software endstops are possible.
- Neither of X, Y, Z will ever overflow.
- If a movement planner would appear one day, he'd have to handle
relative movements as well. Even more code duplication.
Instead of converting them to absolute first, then back to
relative and having all the fuzz with working on the queue's
start vs. working at the queue's end, mark a movement as relative
and use this directly.
This is a intrusive patch and for now, it's done for the X axis only.
To make comparison with the former approach easier ...
The advantages of this change:
- Converting from mm to steps in gcode_parse.c and back in dda.c
wastes cycles and accuracy.
- In dda.c, UM_PER_STEP simply goes away, so distance calculations
work now with STEPS_PER_MM > 500 just fine. 1/16 microstepping
on threaded rods (Z axis) becomes possible.
- Distance calculations (feedrate, acceleration, ...) become much
simpler.
- A wide range of STEPS_PER_M can now be handled at reasonable
(4 decimal digit) accuracy with a simple macro. Formerly,
we were limited to 500 steps/mm, now we can do 4'096 steps/mm
and could easily raise this another digit.
Disadvantages:
- STEPS_PER_MM is gone in config.h, using STEPS_PER_M is required,
because the preprocessor refuses to compare numbers with decimal
points in them.
- The DDA has to store the position in steps anyways to avoid
rounding errors.
& tests of the debug_flags. Currently the compiler is able to eliminate
the block and the & operation when the constant is zero, but since
the debug_flags variable is a volatile the compiler does not eliminate
the load of the variable. By pretesting and shortcutting the load is
eliminated. Saves a small number of bytes when the debug build is
disabled and costs nothing when it is enabled.
This costs 2 bytes of ram, but saves 60 bytes of flash. Doing so
also eliminates the need to disable interrupts while clearing flags
in the ifclock macro.
Conflicts:
clock.c
timer.c
timer.h
Markus Hitter
Michael Moon
Jens Ch. Restemeier
Jim McGee
Markus Amsler