retract.Reset takes care of setting the green LED to blink.
Might as well turn of the red LED during reset just in case.
Change in memory:
Flash: -30 bytes
SRAM: 0 bytes
Fix a minor issue where once the FILAMENT_EJECTED error screen
is shown on the MK3S+, the LEDs will stay blinking red even after
the user has removed the filament and clicked "Done".
My proposal is to turn the LED off.
Steps to reproduce:
1. Boot up printer and MMU in a clean state
2. MK3S+: on the LCD click "Load to Nozzle"
3. Once the loading is done, click "Unload filament"
4. Once unloading is done, click "Eject filament"
5. FILAMENT_EJECTED MMU error screen appears on the printer's UI
6. Remove the filament and select "Done".
* Expected behavior: Blinking red LED turns off (or goes green).
* Actual behavior: LED continous to blink red with no error screen.
Change in memory:
Flash: +16 bytes
SRAM: 0 bytes
static_assert(sizeof(ChopConfU::S) == 4) would return 5 == 4
static_assert(sizeof(ChopConfU) == 4); would return 8 == 4
using uint32_t on all types instead of uint8_t fixes the issue
No change in memory
This seems to greatly improve overall homing reliability of Idler on MMUs which couldn't home with inserted filaments at all.
The only downside is the fact, that we may actually "home" a blocked Idler correctly.
Needs to be tweaked further to make it a production code.
But my primary concern now is the fact that it doesn't seem to help too much while homing over the too-tightened Idler cover.
Now the whole functionality takes +196B
As noted by @leptun, we cannot reliably check for >1 buttons pressed at once.
Since the left button is the least used, let's use it for invoking the HW EEPROM clear upon MMU start.
Based on long-term test experience - saves some code + prevents the user from entering hard-to-understand states.
Only Retry remains as the one and only way of recovering from errors.
This commit introduces a new set of registers 0x1e, 0x1f and 0x20 which allow reading and writing iRun current values for each axis/motor.
Please note the register contains raw TMC2130 iRun value which needs to be translated into mA to be understandable by people.
Translation table of iRun -> mA is present in tmc2130.cpp for now.
Several issues addressed in this PR:
- CutFilament tuning + error recovery
- introduce register 0x1d (cut filament selector iRun current level)
- optimize setting iRun and iHold currents in the FW
- CutFilament unit test fixed
The reasons for this change are:
- NoCommand is used during the lifetime of the firmware as a fallback in case an unknown command is received (simplifies command handling code). It must remain not doing anything.
- StartUp became a complex infrastructure which needs to "live" until an error is fixed (if any). That requires a "standard" StateInner() function which waits for the user to resolve the error.
Unit tests renamed as well.
Intended for scenarios when FINDA used to be OFF but accidentally became ON without a reason.
The user is obliged to inspect FINDA and tune its switching.
If FSENSOR_DIDNT_SWITCH_ON was caused by misaligned Idler, rehoming it may fix the issue when auto retrying -> no user intervention.
So first invalidate homing flags as the user may have moved the Idler or Selector accidentally.
Beware: we may run into issues when FINDA or FSensor do not work correctly. Selector may rely on the presumed filament position and actually cut it accidentally when trying to rehome.
It is yet to be seen if something like this can actually happen.
MMU-191
This PR is a different solution to what @gudnimg found in PR#233 / PFW-1404.
The benefit of this approach is the fact, that the button press event is generated when the button is pressed and not after it has been released.
The downside is obvious:
CPUFLASH: +28B
RAM: +1B
If QUEUE_FULL error happened, it would be overwritten as INTERNAL
and incorrectly display FW_RUNTIME_ERROR on MK3S.
The fix is to add handling for ERRInternal in every StepInner() and forward the error
to higher application layer
The previous commits by @leptun were correct but there has been one call to Disable axis (and TMC) hidden in `InitMovement`.
Therefore `InitMovement` has been split into 2 separate functions - one is there to allow the original full axis reinit, but the other `InitMovementNoReinitAxis` now only prepares a move without reiniting the TMC driver.
This approach seems to have the benefit of fixing the Idler creep over time.
The disadvantage is the fact, that setting StallGuard threshold is no longer called. We may need to add a special piece of code to handle/apply SGTHRS change at runtime like before.
With PWM_FREQ=2 (fPWM = 2/512 fclk), the idler parked current was quite high since the setting was not actually respected (scientifically tested using hand). In order to allow lower current regulation in stealthchop, TBL and PWM_FREQ need to be adjusted. The lower both of these values, the better. Since TBL affects both stealthchop and spreadcycle, I chose to only modify PWM_FREQ.
This new PWM_FREQ results in half the previous stealthchop PWM frequency and also halves the low current limit (so if previously the minimum achievable current was 300mA, now it would be 150mA). I confirmed that this setting works correctly on a 24V supply. There is no audible noise from stealthChop PWM and the hold current is indeed reduced now (again, scientifically tested using my hand).
This PR is just about tuning the intermediate Idler positions so that the filament gets relieved from the Pulley safely while the Extruder gears take over and the activeSlot+1 filament is not affected by its Idler bearing.
On a test bench filament was creeping about 0.5mm per Toolchange.
Changing the intermediate position from exact middle into 3/4 practically elliminated the creep. We can play with these constants more if necessary in the future.
Unfortunately, there is no way to differentiate between an optimized gpio write (safe always on the atmega32u4) and an unoptimized write (read-modify-write, dangerous if any other pin on that Port is used in an ISR).
While very quickly polling the tmc registers, I noticed that the moving stepper would do some random extra steps. That can only be explained by the following sequence of actions:
- the spi code reads the PORT register
- ISR toggles the step line, changing the value in the PORT register
- the spi code writes the upated PORT back, resetting the step line to the old state
After making the writes atomic, the stepping issue disappeared and the driver checks also worked correctly
- rename stall*guard to StallGuard (match name with the vendor)
- separate TMC2130 module from EEPROM (they do not need to know about each other at all)
- separate SGTHRS settings from motion - moved to globals like all other "global" parameters
- improved EEPROM storage for SGTHRS
This needs some investigation if it is really possible to push the Registers into PROGMEM. I think it should be possible, but the compiler is currently not collaborating.
It is not critical though as we have lots of free RAM at the moment (I can't believe I wrote this on an AVR project :) )
3d-gussner
Guðni Már Gilbert
D.R.racer
Alex Voinea
VintagePC
Yuri D'Elia