I noticed this is how the order is in 3.13.0 and before.
I want to keep it exactly the same.
This somehow saves 2 bytes of flash. Probably compiler magic.
Change in memory:
Flash: -2 bytes
SRAM: 0 bytes
If vSense changes at runtime due to Run current
being changed. Then we must always shift the Hold current
correctly. Whether the vSense is changing 1 -> 0 or 0 ->1
Change in memory (with TMC2130_SERVICE_CODES_M910_M918):
Flash: +76 bytes
SRAM: 0 bytes
The firmware will ensure that the Hold current can never
exceed the Run current. In this scenario we must update
the global current array so that M913 reflects the register settings.
Added a echo to serial when this truncation happens
Change in memory:
Flash: +54 bytes
SRAM: 0 bytes
- Always re-calculate the Vsense flag when the currents are changed
- Make sure Hold current is not larger than Run current
- Added SetCurrents() function from MMU FW
- Added MotorCurrents structure from MMU FW
- Various code size optimisations e.g. in power panic
Change in memory:
Flash: -10 bytes
SRAM: +4 bytes
move dedge preprocessing out of tmc2130_setup_chopper
We can use default_dedge_bit to initialise
the dedge bit in the chopconf constuctor later
No change in memory
Previously Z-axis would not be reset to
TMC2130_GCONF_DYNAMIC_SGSENS
in tmc2130_home_exit() when
TMC2130_STEALTH_Z is defined
Pulled configuration code into one common function
this ensures the registers are set correctly like in tmc2130_init()
Change in memory:
Flash: -206 bytes
SRAM: 0 bytes
!variable.running() || variable.expired()
is equal to
variable.expired_cont()
The latter required less flash memory
Change in memory:
Flash: -28 bytes
SRAM: 0 bytes
There is no need to check if every axis bit with each for-loop
iteration. We just need to check if a given axit bit is set.
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
Scale extruder motor current linearly with speed.
49% less heating when running at low speed and standstill, 4% more torque at maximum extrusion rate (15mm^3/s), 15% more torque in high speed movements (un/retractions).
StealthChop mode is used for low speeds (below 900mm/min)
spreadCycle is used above. Transition speed is well above maximum extrusion rate of 15mm^3/s (275mm/min) so mode transition is not expected to be visible on printed surface.
StealthChop is expected to improve printed surface quality (less artifacts).
Warning you can burn extruder motor if it is not the same impedance as original Prusa i3 Extruder stepper motor. There is no current feedback in low speed so lower impedance motor can be burned by over current.
Even there is no direct current feedback, there is no risk for original motor thermal runaway, as motor resistance increases with temperature, current decreases.
Standstill peak phase current is expected to be 500 mA and linearly increase with speed to 970 mA at 900mm/min where spreadCycle constant current regulation takes over and keeps peak current at 805 mA to maximum speed possible.
As motor heating increases with current squared, lowering low speed current from 700mA to 500mA decreases heating 49% in thate mode, where motor spends most of the time.
Enable E-motor cool mode in farm mode only (and experimental menu) - the experimental menu is visible AND the EEPROM_ECOOL variable has a value of the universal answer to all problems of the universe - i.e. two conditions must be met at the start of the FW to enable the E-cool mode. If the user enables the experimental menu, sets the E-cool mode and disables the menu afterwards, on the next start of the FW the E-cool mode will be DISABLED. This is still subject to discussion how much obscure (security through obscurity) we'd like this option to have .
Additional stuff:
* Add serial debug msg to verify if E-cool mode is on
* Avoid access to E-cool mode switch on machines without TMC2130
* Do not allow only M907 E in case of E-cool mode+warn the user on the serial line that the command was skipped
Co-authored-by: D.R.racer <drracer@drracer.eu>
Introduce new macros TMC2130_MINIMUM_DELAY/STEPPER_MINIMUM_DELAY for
blocking pauses.
If MINIMUM_PULSE has defined to be zero, avoid the delay call entirely.
Add constants for the various required delays in tmc2130.h,
which will come in handy for stepper.cpp as well.
Move the delays in the _set functions and remove the pauses
from the various calling points and macros.
Note that the hard-coded pause wouldn't cut it for the stepper ISR,
but it's fine for other use cases.