Endless-Spool Nozzle drop and mmu_server.py History problem

[niedze72]

I would like to point out two possible errors and ask for a solution.

1. Endless Spool function

When Endless-Spool uses "Cut-Tip", the filament is pushed out of the nozzle before cutting.
After charging, a lot of filament is squeezed out of the nozzle.

But this only happens if you set “variable_retract_length” to > 30 mm. My "variable_blade_pos" = 58 mm

When it comes to color printing, everything works perfectly with my settings.

2. History and file display Mainsail

When Gcode is transferred to Mainsail, they are reworked by mmu_server.py.

If you press update in the order overview - the thumbnails disappear. If you press F5 to refresh, they will appear again. After updating with the Mainsail symbol, go away again until the metadata is updated manually.

If you don't do that, the history data won't appear after the print job.

I reorganized my system and tried it on a different system. Same problem everywhere.

It works without problems with Fluidd, but I like Mainsail better. That's why I'm looking for solutions here.

I've already tried this, among other things:

[file_manager]
default_metadata_parser_timeout: 30
#enable_object_processing: True

[moggieuk]

#1 I'm not understanding the issue... If cutting filament at the toolhead then, yes a fragment of filament is left behind. It can be minimized by tuning variable_retract_length. What is the difference between endless spool usage and color printing? You could argue that if endless spool uses exactly the same filament then it doesn't need to purge but this would be a nuance with a lot of logic to implement a very small improvement.

#2 I have heard of history problems before but note the Happy Hare pre-processing is controlled by this:

[mmu_server]
enable_file_preprocessor: True
enable_toolchange_next_pos: True
update_spoolman_location: True

If enable_file_preprocessor: True then the gcode file will be re-written on first upload. If the pre-processing is successful it should not rewrite the file again so history should be good. Moonraker did accept a PR from me to increase the parser timeout default_metadata_parser_timeout: 30 which can be increased further but it would have to be a huge gcode file and slow rpi to need more time..

I feel that it might be a Mainsail refresh issue -- it might be possible to work around but I'm not seeing the problem on my system. Maybe a good question to ask on the Happy Hare Discord: https://discord.gg/98TYYUf6f2

[niedze72]

Many thanks for the quick response

I have a pi module 4 with 4GB RAM and 32GB eMMC and I don't think it's too slow.

Videos say more than a thousand words

#1 Here are the videos about the Mainsail mmu-server.py problem

https://1drv.ms/f/s!At53nslUCZ5HgoMtILpBD4cRMPL1GA?e=ehegjf
or
https://drive.google.com/drive/folders/1o_d5tOrPJLl2yQ-c6oeJ87o6XopLpTSo?usp=sharing

#2 Here are the videos about the endless spool problem - variable_retract_length - larger than 30 mm, here 45 mm

https://1drv.ms/f/s!At53nslUCZ5HgoMuw7YHGBgAR7Zopw?e=NIZ10m
or
https://drive.google.com/drive/folders/1SOnQyqZdg758erbe-KbmU7gvVomvDp8N?usp=sharing

Here is my config data:
mmu_macro_vars_cfg.txt
mmu_parameters_cfg.txt

I hope it works with the links