Order of heater and temperature sensor can differ, so they can get
different numbers. When printing extruder temperatur, we want to
print the temperature of the sensor matching the extruder heater,
not that of the temp sensor with the same number as the extruder
heater. Same for the bed respectively.
This should partially solve issue #96.
The problem was, that settings distributed in
configtool.default.ini were overridden once a configtool.ini was
created. Accordingly, users upgrading sources wouldn't see changes
in this file.
The solution is to move settings set by the distribution into a
separate file which isn't replaced by a user-saved one.
This should fix issue #142.
In case communications to the bootloader doesn't work as expected,
avrdude often takes many many minutes to recognize this, so it's
very convenient to be able to abort these fruitless attempts.
This should solve issue #131.
The Steinhart-Hart algorithm allows more precise thermistor
tables, but also requires more parameters, which aren't
available for all thermistors. Accordingly, add support for both,
the traditional logic using the beta parameter as well as the new
one.
This also adds thermistor-presets, so users can simply choose
from a pulldown-menu to set their thermistor.
Also, identical thermistors get merged into one table, saving
binary size.
Last not least, a few bugs in this area got fixed.
Usually, all these things go into separate commits, but they were
contributed all in one and separating them is a bit error-prone
for little gain.
This should address issue #130, #134 and #135.
This was previously made obsolete in the firmware code already.
See previous commits.
This should solve issue #138.
In case it ever turns out this was a poor decision, it's likely
a good idea to re-add this to the board configuration instead of
the printer configuration.
Debug stuff is meaningful for developers, only. Also often
enabled on a per-file basis depending on the problem at hand.
Two reasons to remove it from Configtool and one reason to
remove it from the config files.
This should solve issue #137.
This is the expected outcome, so explicitely reporting this, with
requiring the user to click a dialog box away, is kind of clutter.
This should solve issue #136.
These are no longer needed, as they're now created on the fly by
Configtool.
Also pick unique information from there over to Configtool, see
the change in configtool/addsensordlg.h.
See comments in the code for the result.
This also fixes a bug where corner cases like delay(0) or
delay(13107) whould result in an extra long pause.
Note: 65535 / (F_CPU / 4000000) = 13107 on 20 MHz.
This costs 28 bytes binary size.
Previously, loading default configurations for board or printer,
then modifying them without saving them, then attempting to
build lead to a big mess, like attempting to save the board file,
failing in doing so and then building anyways.
Inserting a dummy value is better than risking an exception with
failure to write a thermistor table at all. Happens when for one
of the usual thermistors accidently a nominal resistance of
1000k instead of 100k is used.
pgm_read_word() was already defined, but pgm_read_dword() did not
get in our way during earlier testing. These functions force the
arduino to read these "defined in program" constant arrays from
"program memory" instead of RAM as a means to save on RAM usage.
The PC-based simulator doesn't need such tricks and only needs to
read the value directly from the in-RAM array. Therefore it is safe
to convert read directly from the pointer being passed.
pgm_read_word() already does this. Define pgm_read_dword()
similarly to it. Fixes#125.
Now it waits for an "ok" before sending the next line, like all
the G-code sending hosts do. This allows sending arbitrarily long
G-codes. The 60 seconds simulated time limit is still in place to
avoid endless simulations.
The standard performance simulation now runs more G-code and
results in slightly different numbers accordingly:
cd testcases
./run-in-simulavr.sh short-moves.gcode smooth-curves.gcode triangle-odd.gcode
FLASH : 20540 bytes 144% 67% 33% 16%
RAM : 2188 bytes 214% 107% 54% 27%
EEPROM : 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 304 clock cycles.
LED on time maximum: 720 clock cycles.
LED on time average: 313.256 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 36511.
LED on time minimum: 304 clock cycles.
LED on time maximum: 706 clock cycles.
LED on time average: 349.172 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 304 clock cycles.
LED on time maximum: 710 clock cycles.
LED on time average: 332.32 clock cycles.
... simply because P is used for many commands and none of them
cares to clean it after usage.
This fixes a bug where setting the default heater without temp
sensor (M106) worked only after a G4 Pxxx command.
... instead of trying to fire an interrupt as quickly as possible.
This affects ACCELERATION_TEMPORAL only. It almost doubles the
achievable step rate. Measured maximum step rate (X axis only,
100 mm moves) is 40'000 steps/s on a 16 MHz electronics, so
approx. 50'000 steps/s on a 20 MHz controller, which is even
a bit faster than the ACCELERATION_RAMPING algorithm.
Tests with temporary test code were run and judging by these
tests, clock interrupts are now very reliable up to the point
where processing speed is simply exhaused.
Performance with ACCELERATION_RAMPING: this costs 10 bytes
binary size and exactly 2 clock cycles per step interrupt or
0.6% performance even. We could avoid this with a lot
of #ifdefs, but considering ACCELERATION_TEMPORAL will one
day be the default acceleration, skip these #ifdefs, also
for better code readability.
$ cd testcases
$ ./run-in-simulavr.sh short-moves.gcode smooth-curves.gcode triangle-odd.gcode
SIZES ATmega... '168 '328(P) '644(P) '1280
FLASH : 20528 bytes 144% 67% 33% 16%
RAM : 2188 bytes 214% 107% 54% 27%
EEPROM : 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 838.
LED on time minimum: 304 clock cycles.
LED on time maximum: 715 clock cycles.
LED on time average: 310.717 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 8585.
LED on time minimum: 309 clock cycles.
LED on time maximum: 712 clock cycles.
LED on time average: 360.051 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 304 clock cycles.
LED on time maximum: 710 clock cycles.
LED on time average: 332.32 clock cycles.
Performance for ACCELERATION_RAMPING unchanged:
$ cd testcases
$ ./run-in-simulavr.sh short-moves.gcode smooth-curves.gcode triangle-odd.gcode
[...]
SIZES ATmega... '168 '328(P) '644(P) '1280
FLASH : 20518 bytes 144% 67% 33% 16%
RAM : 2188 bytes 214% 107% 54% 27%
EEPROM : 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 838.
LED on time minimum: 302 clock cycles.
LED on time maximum: 713 clock cycles.
LED on time average: 308.72 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 8585.
LED on time minimum: 307 clock cycles.
LED on time maximum: 710 clock cycles.
LED on time average: 358.051 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.
Pure cosmetical change.
Performance check:
$ cd testcases
$ ./run-in-simulavr.sh short-moves.gcode smooth-curves.gcode triangle-odd.gcode
[...]
SIZES ATmega... '168 '328(P) '644(P) '1280
FLASH : 20518 bytes 144% 67% 33% 16%
RAM : 2188 bytes 214% 107% 54% 27%
EEPROM : 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 838.
LED on time minimum: 302 clock cycles.
LED on time maximum: 713 clock cycles.
LED on time average: 308.72 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 8585.
LED on time minimum: 307 clock cycles.
LED on time maximum: 710 clock cycles.
LED on time average: 358.051 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.
It's rarely a good idea to overwrite files coming with a
distribution. Not for users, because they can't reset to factory
values; not for developers, because Git would pick up such changed
files.
Instead we read from configtool.default.ini now, but write to
configtool.ini. If configtool.ini is already present, it's
prefered over configtool.default.ini.
It's also possible to do this by stringifying MCU, but this
requires double redirection, which isn't easily readable in a .c
file. For stringification, see the bottom example at
https://gcc.gnu.org/onlinedocs/cpp/Stringification.html
- "Traumflug" and "Markus Hitter" are the same, mention him only
once.
- Add more common F_CPU choices in comments.
- Hint to another choice in Makefile-example.
It was so far unnoticed that the "simulavr" program is only a
script when run from within the build directory. Still killing it
by name worked, because bash's exec didn't terminate the initiating
script.
Apparently this week Ubuntu updated bash and the new version now
terminates the initiating script (which is a good idea), but now
the executable to kill by name has a different name. It's prefixed
with "lt-". As this "lt-" is hardcoded we can rely on it.
Forgotten in commit 74808610c7,
"DDA: Move axis calculations into loops, part 5.".
This and the previous commit makes ACCELERATION_TEMPORAL building
(and working!) again.
Next time, please at least try to compile the code section in
question when explicitely changing the section. In this case,
with ACCELERATION_TEMPORAL enabled. It didn't build.
Was broken with commit 95926a3f113809bde8ff0c84b94c55c73e398f67,
"DDA: Rename confusing variable name.".
Markus Hitter
jbernardis
Phil Hord