This can be counterproductive if the actual zero point is
outside the available build room. For example, if an additional
bed probing is going to happen. It also costs quite some
time on the Z axis. If you actually want this behaviour,
send a simple G0 XYZ after homing.
Many places in the code use individual variables for int/uint values
for X, Y, Z, and E. A tip from a comment suggests making these into
arrays for scalability in the future. Replace the discrete variables
with arrays so the code can be simplified in the future.
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.
For now for X min only, but it works excellently already.
Tested quite a few combinations and raising acceleration
or endstop clearance raises homing feedrate just as expected.
Quite a chunk of the code is for testing the given configuration,
only. A thing which would ideally be done for every macro
used in each code file.
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.
Some M-codes apparently need this. Perhaps it could be avoided,
but it costs just 8 bytes binary size and 2 bytes RAM, so not
really a reason to make a headache.
Problem spotted, described in a helpful manner and over-fixed
by @zungmann. This fix picks up his basic idea and implements it
with already existing state properties.
Instead of just two columns (x and y) in the trace file, treat
every column as a function and calculate the first derivative
of it without regard for its supposed "meaning". In addition
to getting more data from this, it also allows us to calculate
the 2nd derivative easily by running the script again on the
resulting data.
Also convert time in column 1 from microseconds to seconds.
Simulator assumes a basic set of config pins. Most it ignores
and redefines. But the INVERT_DIR pins it did not, and these
could be useful to simulate. So teach Simulator to respect them.
Move builds for non-avr target (simulator) into a $(BUILD_FLAVOR)
build subdir (build/sim) to isolate it more completely and
cleanly from the AVR builds. This allows AVR and SIM to use common
build rules again.
Move newly bits out of Makefile-{SIM,AVR} and into Makefile-common.
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".
There's no apparent documentation for this on the AVR variant of GCC.
Likely it means to optimize "more aggressively". Uhm, is gcc
intentionally wasting cycles otherwise? Likely not.
Also, the compilation result is exactly the same size with or
without this attribute.
This macro is pretty expensive (700 bytes, well, stuff is now
calculated at runtime), so there's no chance to use it in multiple
places and we likely also need this in dda_lookahead.c to achieve
full 4 axis compatibility there.
For now this is for the initial rampup calculation, only, notably
for moving the Z axis (which else gets far to few rampup steps on
a typical mendel-like printer).
The used macro was verified with this test code (in mendel.c):
[...]
int main (void) {
init();
uint32_t speed, spm;
char string[128];
for (spm = 2000; spm < 4099000; spm <<= 1) {
for (speed = 11; speed < 65536; speed *= 8) {
sersendf_P(PSTR("spm = %lu speed %lu ==> macro %lu "),
spm, speed, ACCELERATE_RAMP_LEN_SPM(speed, spm));
delay_ms(10);
sprintf(string, "double %f\n",
(double)speed * (double)speed / ((double)7200000 * (double)ACCELERATION / (double)spm));
serial_writestr((uint8_t *)string);
delay_ms(10);
}
}
[...]
Note: to link the test code, this linker flag is required to add
the full printf library (which does print doubles):
LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm
Keeping the hack causes the previous move to decelerate, which isn't
intended when movements are joined with lookahead.
Removing only the hack breaks endstop handling on those axes which
set a huuuge number of acceleration steps for the lack of a proper
calculation algorithm. We have this algorithm now, so we can stop
using this kludge.
Solves part 1 of issue #68.
Previously, ramps were calculated with the combined speed,
which can differ from the speed of the fast axis by factor 2.
This solves part 2 of issue #68.
Markus Hitter
Phil Hord
David Forrest
Roland Brochard