Adjustments by Traumflug:
- Rebased to current 'experimental'.
- Some whitespace adjustments.
- Renamed labelWidth_homing to labelWidthHoming.
- Fixed an issue in printer.py which would write only the first
character of an option ('x' instead of 'x_positive', 'n'
instead of 'none', etc.)
Thank you very much for the code, Matt!
Configs are always included via a config_wrapper.h now, and configs always
must include this safety-definition for a missing DEFINE_HEATER. Let's
simplify the configs by moving it to a common location.
You can reduce the max. power of each heater.
With the max_pwm value between 1 and 100% you reduce the active pwm.
For example you could reduce the power of your hotend.
My hotend for example is 12V 30W but connected to 24V. So it has
normally 120W. This is very huge. Setting the max_pwm to 25, it has
again ~30W.
This should fix issue #235.
Recently ConfigTool has been very slow for me on Ubuntu Linux.
When I run the app there is a 15 second wait before the window is
first displayed. I bisected the problem and found it was tied to
the number of pins in `pinNames`, and ultimately that it was
caused by a slow initializer in wx.Choice() when the choices are
loaded when the widget is created. For some reason, moving the
load after the widget is created is significantly faster. This
change reduces my startup time to just under 4 seconds.
Further speedup could be had by using lazy initialization of the
controls. But the controls are too bound up in the loaded data
to make this simple. Maybe I will attack it later.
There is still a significant delay when closing the window, but I
haven't tracked what causes it. Maybe it is caused just by
destroying all these pin controls.
In the process of making this change, I wanted to simplify the
number of locations that bothered to copy the pinNames list and,
to support lazy loading, to try to keep the same list in all
pinChoice controls. I noticed that all the pinChoice controls
already have the same parameters passed to the addPinChoice
function which makes them redundant and confusing. I removed the
extra initializers and just rely on pinNames as the only list
option in addPinChoice for now. Maybe this flexibility is needed
for some reason later, but I can't see a purpose for it now.
Notes by reviewer Traumflug:
First of all, which "trick"? That's an excellent code
simplification and if this happens to make startup faster (it
does), all the better.
Measured startup & shutdown time here (click window close as soon
as it appears):
Before: With this commit:
real 0m4.222s real 0m3.780s
user 0m3.864s user 0m3.452s
sys 0m0.084s sys 0m0.100s
As the speedup was far more significant on the commit author's
machine, it might be a memory consumption issue (leading to
swapping on a small RAM machine). Linux allows to view this in
/proc/<pid>/status.
Before: Now:
VmPeak: 708360 kB 708372 kB
VmSize: 658916 kB 658756 kB
VmHWM: 73792 kB 73492 kB
VmRSS: 73792 kB 73492 kB
VmData: 402492 kB 402332 kB
Still no obvious indicator, but a 300 kB smaller memory footprint
is certainly nice.
If you attempt a Steinhart-Hart table in the configtool with
parameters (4700, 25, 100000, 209, 475, 256, 201) it fails with a:
...
File "/Users/drf/2014/RepRap/GIT/Teacup_Firmware/configtool/
thermistortablefile.py", line 169, in SteinhartHartTable
(i, int(t * 4), int(delta * 4 * 256), c, int(t), int(round(r))),
TypeError: not enough arguments for format string
Catched and fix provided by dr5fn, this should fix issue #246.
Heck, that's simply forbidden. A C compiler had catched this in a
split second at compile time, Python didn't until the faulty code
section was actually executed (a section of code for rare cases).
The simple fix is to replace the old tuple with a changed, new
tuple.
This resolved issue #242.
This allows to use EWMA_ALPHA in an #if clause, which is needed
for the next commit.
Review changes by Traumflug: made changes to comments more
complete, added rounding ("+ 500") and also adjusted Configtool
for the change.
Because these two pins have no presence in Configtool's GUI, they
got dropped when writing a board config file. These pins are
needed for Gen3 Extruder Board support.
This should solve issue #179.
Teach configtool to save ini, board and printer files with the
--save commandline switch. Add a feature to Printer and Board
to let us pass None for the "values" to save; this causes the
class to save the previously loaded settings instead of taking
new settings in the argument.
Also add --quit switch to tell commandline not to continue to run the
GUI. There's not much point in running the gui after many of these
switches, but that will change in the future. Add this --quit option
to quit early so we can begin to use this new mode for test validation.
Instead of passing myriad variables around in arguments to
classes and functions, put the global settings like "verbose" and
"cmdFolder" in the Settings object and pass that in to the top.
Move model functionality out of printerpanel.py into a new class,
Printer, so we can more easily add commandline driven tests in
the future and to help identify code reuse opportunities.
New boolean options were all enabled, which was a problem
especially with the boolean choices DISPLAY_BUS_xxx and
DISPLAY_TYPE_xxx: all choice entries were set to True, so display
code was not only enabled behind the users back, but also set to
an arbitrary value (depending on the Python implementation).
Previously, #defines requiring a value, but configured as boolean,
broke GUI code. While Configtool its self should never write such
broken #defines, they can happen with manual config file edits.
IMHO it's fine to do such repair attempts as long as it doesn't
hobble other functionality. Whatever was broken at read time will
end up disabled at write time, unless the user changes that value
in the GUI.
This is done by parsing values from the generic config before
parsing those in the user config. Values existing in the user
config overwrite those in the generic config; values not
existing there stay at the value in the generic config.
Previously, only boolean #defines were handled properly (and
by code somewhere else). Missing #defines with value were
written as boolean #define, making the file unparseable on
the next read.
We can't magically find out what the right pin is, but we can at
least make sure it gets written with valid syntax next time. This
also ensures pins can be handled in the GUI, avoiding failures
like the one reported by inline comments here:
b9fe0a5dd0
Some target devices need extra avrdude command line switches to
get them to upload successfully. There are dozens of options which
may be useful to different people. Instead of breaking all the possible
options out into separate fields, provide a generic "Program Flags" text
field which the user can fill in similar to the CFLAGS and LDFLAGS
settings.
The Arduino Mega2560 bootloader was changed[1] to report an error when
asked to erase flash because it has never actually implemented erasing
flash. To program this bootloader with avrdude requires the -D switch
to avoid flash erase. But it seems that every arduino will work fine
with -D, as evidenced by the fact that the Arduino IDE always [2]
includes -D in the avrdude commandline. Presumably the flash is erased
during/before programming anyway and the separate erase step is unneeded.
Perhaps the -D should be always added to avrdude command line in
configtool and in Makefile-AVR. But I haven't tested any other boards
yet, and I'm being more cautious even though the Arduino IDE does
otherwise.
[1] arduino/Arduino#543
[2] d8e5997328/app/src/processing/app/debug/AvrdudeUploader.java (L168)
So far for choices based on boolean sets, only, because choices
for values typically need no more readable names.
This elegantly removes the somewhat ugly check for '(', too.
Having a choice with a defined set of options is nice, but it
also requires these options to be #defined somewhere _before_
entering config.h. To keep class-like encapsulation, we'd need
two header files for each code unit, one for the options, another
one for the usual header.
That said, we use other examples of such options, e.g. CPU, F_CPU
or KINEMATICS. For CPU and F_CPU it works fine, because their
options are numbers or other values known by the compiler. For
KINEMATICS it kind of works, because this #define is used in only
one place ... and there it's suboptimal already, because no option-
set.
Anyways, I was unsure about this change and if it turns out to be
a poor decision later, it can be reverted.
Most work by Ruslan Popov, collected from various commits and
made compatible with regression tests by Traumflug.
Display test code is now enabled by #defining DISPLAY_BUS to
i2c_twi.
Matt Gilbert
Wurstnase
Phil Hord
Phil Hord
Markus Hitter
Ilya Epifanov
benj919
Ruslan Popov