Tooltips don't size their box after line lengths, but have their
own idea on how wide to make it. Accordingly one should display
text with newlines only for paragraph delimiters.
This also required adjustments to all the board and printer
description comments. No functional change there.
This should solve issue #148.
Formerly, both names were arbitrary and the user had to know
that only heaters ans sensors with matching names would work
together. Accordingly, temp sensors can have only names matching
those of existing heaters. With the exception of "noheater",
which is also provided.
This kind of solves issue #143.
This looks like nitpicking right now, but further changes shall
provide only already existing heater names for temp sensor names,
so the former have to be defined first. Lead the user to follow
this strategy intuitively.
The problem was, applying tooltips to the radio buttons directly
showed no effect on Linux. While this is likely a bug in wxPython,
we can't change this behaviour.
The solution is to also apply these help texts to the surrounding
StaticBox. This works, even for the radio buttons.
This solves issue #149.
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.
Markus Hitter
jbernardis
Phil Hord