In preparation for more efficient and scalable code using axis-loops
for common operations, add two new array-types for signed and unsigned
32-bit values per axis. Make the TARGET type use this array instead of
its current X, Y, Z, and E variables.
Traumflug notes:
- Did the usual conversion to spaces for changed lines.
- Added X = 0 to the enum. Just for peace of mind.
- Excellent patch!
Initially I wanted to make the new array an anonymous union with the
old variables to allow accessing values both ways. This way it would
have been possible to do the transition in smaller pieces. But as
the patch worked so flawlessly and binary size is precisely the
same, I abandoned this idea. Maybe it's a good idea in other areas.
Well, optimizer isn't _that_ smart. It apparently removes
empty functions in the same compilation unit ( = source code file),
but not ones across units.
This saves 10 bytes binary size per endstop not used, so 30 bytes
in a standard configuration. All without any drawbacks.
This meant to be a firmware-provided retract feature but was
never really supported by G-code generators. Without their support
(by issueing M101/M103), it's pretty hard to detect extrusion
pauses, so this feature simply has no future.
As this was on by default, it saves over 200 bytes binary size
in a default configuration.
Test code which wants to customize config.h can do so without
touching config.h itself by wrapping config.h in a macro variable
which is passed in to the compiler. It defaults to "config.h" if
no override is provided.
This change would break makefile dependency checking since the selection
of a different header file on the command line is not noticed by make
as a build-trigger. To solve this, we add a layer to the BUILDDIR path
so build products are now specific to the USER_CONFIG choice if it is
not "config.h".
This code was accidentally removed long ago in a botched merge. This
patch recovers it and makes it build again. I've done minimal testing
and some necessary cleanup. It compiles and runs, but it probably still
has a few dust bunnies here and there.
I added registers and pin definitions to simulator.h and
simulator/simulator.c which I needed to match my Gen7-based config.
Other configs or non-AVR ports will need to define more or different
registers. Some registers are 16-bits, some are 8-bit, and some are just
constant values (enums). A more clever solution would read in the
chip-specific header and produce saner definitions which covered all
GPIOs. But this commit just takes the quick and easy path to support my
own hardware.
Most of this code originated in these commits:
commit cbf41dd4ad
Author: Stephan Walter <stephan@walter.name>
Date: Mon Oct 18 20:28:08 2010 +0200
document simulation
commit 3028b297f3
Author: Stephan Walter <stephan@walter.name>
Date: Mon Oct 18 20:15:59 2010 +0200
Add simulation code: use "make sim"
Additional tweaks:
Revert va_args processing for AVR, but keep 'int' generalization
for simulation. gcc wasn't lying. The sim really aborts without this.
Remove delay(us) from simulator (obsolete).
Improve the README.sim to demonstrate working pronterface connection
to sim. Also fix the build instructions.
Appease all stock configs.
Stub out intercom and shush usb_serial when building simulator.
Pretend to be all chip-types for config appeasement.
Replace sim_timer with AVR-simulator timer:
The original sim_timer and sim_clock provided direct replacements
for timer/clock.c in the main code. But when the main code changed,
simcode did not. The main clock.c was dropped and merged into timer.c.
Also, the timer.c now has movement calculation code in it in some
cases (ACCELERATION_TEMPORAL) and it would be wrong to teach the
simulator to do the same thing. Instead, teach the simulator to
emulate the AVR Timer1 functionality, reacting to values written to
OCR1A and OCR1B timer comparison registers.
Whenever OCR1A/B are changed, the sim_setTimer function needs to be
called. It is called automatically after a timer event, so changes
within the timer ISRs do not need to bother with this.
A C++ class could make this requirement go away by noticing the
assignment. On the other hand, a chip-agnostic timer.c would help
make the main code more portable. The latter cleanup is probably
better for us in the long run.
Teacup handles motor on/off automatically and if your
intention is to stop the printer, M0 is appropriate (and
conforming with the NIST G-code standard).
That said, M84 is kept as a synonym for M2 to enhance compatibility
with slic3rs default end-G-code.
The requirement was simply neither obvious nor intuitive. Drawback
is, the indices of temperature sensors can now differ from these
of the heaters. That's easier to recognize for newbies, though.
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.
Markus Hitter
Erik Jonsson
David Forrest
Phil Hord