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.
start the simulation with ./parse_clean xyz, where 'xyz' can be anything to name the created files.
in the end you will get 3 pictures.
swan-reference-xyz.png how it should looks like.
swan-current-xyz.png how it will looks now.
swan-diff-xyz.png is the difference.
This 3 pictures show only the X-axis.
you will get also a forth file. pp-xyz.asc. you can open this file for example with meshlab and you can see that current model in 3d.
If you want to use your own gcode, please do the following:
Create a normal gcode. Delete any M116 (temp waitings). Maybe you want also deleting comments.
Then add M114 for every x line.
I do this with the swan-test.gcode:
sed '1~2 s/$/\nM114/g' < swan.gcode > swan-test.gcode
In `ACCELERATION_RAMPING` code we use the dda->id field even when we do
not enable `LOOKAHEAD`. Expose the variable and its related `idcnt`
when `ACCELERATION_RAMPING` is used.
Add a regression-test to catch this in the future.
Simple trick: raise the feedrate, no need to care about a milling
bit when running a simulation. This reduces simulated time and as
such, duration of the simulation (by about 50%).
Also remove G-code which was never executed because simulations
are chopped at 1 minute of simulation time and smooth-curves.gcode
took about 1.5 minutes.
Step pulse measurements remain about the same:
ATmega sizes '168 '328(P) '644(P) '1280
Program: 17944 bytes 126% 59% 29% 14%
Data: 1920 bytes 188% 94% 47% 24%
EEPROM: 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 202 clock cycles.
LED on time maximum: 380 clock cycles.
LED on time average: 232.092 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 22589.
LED on time minimum: 194 clock cycles.
LED on time maximum: 423 clock cycles.
LED on time average: 254.425 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 220 clock cycles.
LED on time maximum: 380 clock cycles.
LED on time average: 245.575 clock cycles.
Distinction between straight-speeds.gcode and
straight-speeds-Fsep.gcode is that the latter has all speed
changes in a seperate line. If queueing works properly and
nullmoves get removed, both should produce identical results.
Our standard performance test is to run these three G-code files
in SimulAVR and recording step pulse timings. While this certainly
doesn't cover everything related to possible performance
measurements, it's a good basic standard to compare code changes.
Current performance:
ATmega sizes '168 '328(P) '644(P) '1280
Program: 19808 bytes 139% 65% 32% 16%
Data: 2191 bytes 214% 107% 54% 27%
EEPROM: 32 bytes 4% 2% 2% 1%
short-moves.gcode statistics:
LED on occurences: 888.
LED on time minimum: 308 clock cycles.
LED on time maximum: 729 clock cycles.
LED on time average: 317.393 clock cycles.
smooth-curves.gcode statistics:
LED on occurences: 23648.
LED on time minimum: 308 clock cycles.
LED on time maximum: 726 clock cycles.
LED on time average: 354.825 clock cycles.
triangle-odd.gcode statistics:
LED on occurences: 1636.
LED on time minimum: 308 clock cycles.
LED on time maximum: 719 clock cycles.
LED on time average: 336.327 clock cycles.
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.
To the best of my bash script knowledge, this also means we have
to break on the first error, because pipe terms run in a subshell,
so they can't pass variables to the parent.
Add a test that puts the stock config files through the
Configtool input/output parsers and verifies the output matches
the input. If Configtool breaks down in the future and produces
different output, this should catch it.
If this fails because of some intentional change in the tool or
in the stock config files, then the tool or stock config files
should be updated to be compatible again before merging the result.
(Ab)use the old Gen7 v1.3 configuration for this, as this is
rarely in use and because this board also happens to be the board
where the tested code was developed on.
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.
Implemented and tested for both platforms. This is quite a big
commit. Unlike with the previous changes to now choosable PWM
frequencies, all board configuration files and Configtool had
to be changed immediately to deal with the additional parameter
in DEFINE_HEATER() and keep AVR builds working (and regression
tests passing).
These were dropped accidentally, I assume, during the Configtool
template conversion. Without them the INTERCOM feature does not
compile and so board.gen3.h is broken.
Add the gen3 config to testcases and regressiontests to ensure
this does not drop again.
For now this is just a number of different configurations and a
makefile target, "make regressiontests", to build with them.
Further tests, e.g. using SimulAVR or the hostside simulator
to check actual behaviour of the firmware are welcome.
Nico Tonnhofer
Phil Hord
Markus Hitter
Phil Hord
Ruslan Popov
Witold Sowa
Phil Hord