Over extrusion mmu gear an extruder light speed !!!

[salocain]

it's possible to do something for the update it's not the first time ... , when an update requiere install.sh , all configuration must be redo... rechecked because to many changes .....

my config worked well , and after update to 2.6 ---> the gear motor cry ....

i understand the necesity of the software evolution but the base system setting grow and grow with many many things and the philosophy change in the same time ....

the update is not an happy moment...

[ningpj]

what version did you upgrade from and what command did you use to run the upgrade? Settings should be preserved and have upgraded multiple times without needing to reapply any changes.
If you used ./install.sh -i (for initial, interactive install) then that would definitely overwrite existing settings

[Belstrekkie]

The update to 2.6 results in a klipper error and requirement to re-run the install script. Came on a unexpected, very unlucky moment for me as well, even though it is mentioned in the wiki.

[salocain]

what version did you upgrade from and what command did you use to run the upgrade? Settings should be preserved and have upgrade multiple times without needing to reapply any changes. If you used ./install.sh -i (for initial, interactive install) then that would definitely overwrite existing settings

the last 2.5 to 2.6 --> but is not the first time....

The update to 2.6 results in a klipper error and requirement to re-run the install script. Came on a unexpected, very unlucky moment for me as well, even though it is mentioned in the wiki.

i think it's my problem too , i test to rerun the script.

it's mentionned in the wiki, great ...but an alert message in the install is better ......

thank's for you're comments

[moggieuk]

The update process via ./install.sh should be painless. I run it many time per day while developing and I get very few questions about it failing. The reason for it is that Happy Hare is much more that just a klipper/moonraker plugin. Therefore an update-manager update cannot update configuration or add options.

A minor patch can be updated easily through update-manager, but when the logic in HH detects a version number change it requires you to run ./install.sh. There is no way around this and no way to alert you to the need before hand. You can review the (long) change log, or look for a version number change and then know that upgrade will be required.

What would be helpful would be to explain the specific upgrade error you have. I only know on one in the past 3 months which is an incorrect upgrade of macro retract_speed.

Upgrade is explained here: https://github.com/moggieuk/Happy-Hare/wiki/Installation#---upgrading

[Belstrekkie]

The error is just the klipper error after the restart, mentioning that you have to run the install script. No problem, but because I didn't see it coming (there are so many backups that I didn't see that it was a .x version change), it was a bit more cumbersome to make backups (because the error maked the macros (for clipper backup) unreachable).

What was a problem on both machines I upgraded is that after the upgrade to 2.6 and after running the script, is that for some reason only 4 configuration files were left in the mmu-base folder (mmu.cfg, mmu_hardware, mmu_macro_vars and mmu_parameters) and the optional folder was missing entirely. So this resulted in additional errors (macro's missing) and LED's not working amongst others.

[salocain]

after any comparaison the setting are the same and the problem is not happy hare, yesterday i test at 1% because the problem is acceleration noise and skipping step of my ercf gear motor --> but at 1% speed i see my extruder and ercf synchronis right, but the result is the same as an error on rotation distance ---> mega over extrusion !!!

my appologise it's the klipper update problem and not happy hare , or it's happy hare ?, now i need to understand why and how reconfigure

edit:

strange , when i ask for extrud a longeur , it's ok , but when i print a file all extrusion is boost x100000 (i test with an old file and a new file for exclude a slicer problem)

now i test without HH.

edit :+1: without HH all work well ....wtf in the hh update to pertube my extrusion setting?

[salocain]

any solution ?

@moggieuk ?

[salocain]

nobody can help me ?

the error message on klipper with the mmu actived

"MCU 'mmu' shutdown: Rescheduled timer in the past This generally occurs when the micro-controller has been requested to step at a rate higher than it is capable of obtaining."

[ningpj]

This use to happen on builds with the original Easy BRD mcu when stepper micro steps where set too high as the seeeduino couldn't keep up.

What was ERCF doing when this happened? E.g homing, loading, unloading? What mcu are you using on your build? What version of HH are you running now? HH 2.5 or 2.6.x?

Also useful to check and include additional information from the mmu.log leading up to this issue. You may need to increase log levels though and try to recreate the error so we have more info to go on.

If you are running the original seeedunio based Easy BRD mcu, try reducing the stepper micro steps to 8 to reduce cpu load.

# log_level & logfile_level can be set to one of (0 = essential, 1 = info, 2 = debug, 3 = trace, 4 = stepper moves)
# Generally you can keep console logging to a minimal whilst still sending debug output to the mmu.log file
# Increasing the console log level is only really useful during initial setup to save having to constantly open the log file
# Note: that it is not recommended to keep logging at level greater that 2 (debug) if not debugging an issue because
# of the additional overhead
#
log_level: 1
log_file_level: 4           # Can also be set to -1 to disable log file completely

[salocain]

**the problem is that since the update to 2.6, previously ok in 2.5, the ercf motor and that of my extruder are out of adjustment, as if we asked them to extrude 100mm instead of 1mm (this is an example).

when I ask to extrude 100mm it is ok (via the klipperscreen interface) the problem occurs when I print, and only when HH is used.

so the problem comes from HH and in my opinion from the processing of the file.

I repeat, without HH (# mmu in printer.cfg ) all is fine

the mcu is BTT mmb i do a test with fresh log and i put here

[ningpj]

So you aren't getting timer in the past errors then? Sounds like you may need to recalibrate your ercf again.

Check settings in mmu_hardware.cfg for the gear stepper are defined correctly

[stepper_mmu_gear]
step_pin: mmu:MMU_GEAR_STEP
dir_pin: !mmu:MMU_GEAR_DIR
enable_pin: !mmu:MMU_GEAR_ENABLE
rotation_distance: 22.7316868   # Bondtech 5mm Drive Gears. Overriden by 'mmu_gear_rotation_distance' in mmu_vars.cfg
gear_ratio: 50:17               # E.g. ERCF 80:20, Tradrack 50:17
microsteps: 16                  # Recommend 16. Increase only if you "step compress" issues when syncing
full_steps_per_rotation: 200

also check your persistent calibration settings in mmu_vars.cfg as these may have been corrupted and will affect feed rates.

mmu_calibration_0 = 1.0
mmu_calibration_1 = 1.002387
mmu_calibration_2 = 0.998409
mmu_calibration_3 = 1.002784
mmu_calibration_4 = 0.998807
mmu_calibration_5 = 1.002387
mmu_gear_rotation_distance = 22.825892

[salocain]

no , with previous version , all is fine , and it's what i post for downgrade , for test.

i verify mmu_var and config , it's ok , same as your (approximativly)

i do test for exclude slicer problems.

edit : no problem in debug file , the gear ratio is ok ..

EBUG: Syncing gear stepper and extruder 20:42:51     TRACE: Updated sync multiplier: 1.0000 20:42:51     TRACE: Setting gear motor rotation distance: 22.528223 (ratio: 1.001667) 20:42:51 Modifying MMU gear stepper run current to 75% for extruder syncing 20:42:52     TRACE: New sync direction: extrude 20:42:52     TRACE: Updated sync multiplier: 1.0000 20:42:52     TRACE: Setting gear motor rotation distance: 22.528223 (ratio: 1.001667) 20:42:54   DEBUG: Un-retracting 2.0mm 20:42:54   DEBUG: Restoring toolhead height (speed:15, accel:5000) 20:42:54   DEBUG: Restored gcode state and z-hop position only (Z:0.0) after change_tool 20:43:01 > MMU_CHANGE_TOOL TOOL=10 NEXT_POS="324,-24" ; T10 20:43:02   DEBUG: Retracting 2.0mm 20:43:02   DEBUG: Saving toolhead gcode state and position (X:0.0 Y:-25.0 Z:0.0 E:-2.0) for change_tool 20:43:02   DEBUG: Lifting toolhead 2.0mm with 5.0mm ramp (speed:15, accel:5000) 20:43:02     TRACE: Disabled runout detection 20:43:02   DEBUG: Tool change initiated with slicer tip forming 20:43:02 Tool T10 is already loaded 20:43:02     TRACE: Enabled runout detection 20:43:02     TRACE: Running macro: _MMU_CLEAR_POSITION 20:43:02   DEBUG: Un-retracting 2.0mm 20:43:02   DEBUG: Restoring toolhead height (speed:15, accel:5000) 20:43:02   DEBUG: Restored gcode state and z-hop position only (Z:0.0) after change_tool 20:43:02     TRACE: New sync direction: retract 20:43:02     TRACE: Updated sync multiplier: 1.0000 20:43:02     TRACE: Setting gear motor rotation distance: 22.528223 (ratio: 1.001667) 20:43:03     TRACE: New sync direction: extrude 20:43:03     TRACE: Updated sync multiplier: 1.0000 20:43:03     TRACE: Setting gear motor rotation distance: 22.528223 (ratio: 1.001667) 20:43:26     TRACE: New sync direction: retract 20:43:26     TRACE: Updated sync multiplier: 1.0000 20:43:26     TRACE: Setting gear motor rotation distance: 22.528223 (ratio: 1.001667) 20:47:49     TRACE: New sync direction: extrude 20:47:49     TRACE: Updated sync multiplier: 1.0000

[salocain]

i test an old file i print before , and same bug....

now , i'm sure is not a slicer problem .

[salocain]

the mmu.log with an old printed file mmu.log

same problem --> extruder go as light speed !!!!

[salocain]

mmu.log

i turned off the MMu_server

after another test , with the same file as before , with extruder factor at 1% , it's little bit over extrusion like normal extrusion.

where this setting is changed in the HH ?

i'm the only one with the over extrusion problem with HH?

[moggieuk]

@salocain There are a couple of things I need to help you: 1) An example gcode file created by your slicer that I can load up locally 2) A klippy.log file. 3) Detail of exactly what klipper version you are running.

Happy to help, but HH doesn't control anything like you are describing so it is something else...

[salocain]

an old file i have printed gcodes-202471-20130.zip

the version of all things i have .

and for the klippy log a put it after (with and without HH)

thank you

[salocain]

the first klippy log with happy hare on .

i see the flowrate move to hight value and down and up and down .

klippy.log

and here the same file print without HH #[include mmu/base/*.cfg] --> and no problem . klippywithout happyhare.log

in HH anithing change my flowrate to the hight level but , why and how turn off

i test different things but...

[salocain]

no enought informations?