search

moggieuk / Happy-Hare

MMU software driver for Klipper (ERCF, Tradrack, Prusa)
GNU General Public License v3.0
427 stars 102 forks source link

Endless Spool function change #340

Open platinumalloy01 opened 1 month ago

platinumalloy01 commented 1 month ago

I have a suggestion for the endless spool function in happy hare on the ercf. Rather than unload the filament once a runout has been detected, I recommend that it instead passes a specified amount of filament through the encoder/selector while continuing to print, then after that specified amount has passed through signifying that the gate is cleared and the selector is able to move to another gate loading the next roll of filament, and using a sensor less homing type function that detects when it pushes against the currently loaded filament then continues the print as normal, and not wasting filament, or pausing the print. Thank you for reading, I understand if this may be a limitation of the host computer, but maybe there’s a way.

moggieuk commented 1 month ago

This has been asked quite a few times before. The problem is that it could work (still not super easy) ONLY with single color endless spool prints... once the filament break is past the MMU gear, there is no way to color change. Also, if the print happens to end with the break still in the bowden it also becomes a hassle.

Frankly, loosing 600mm - 1.5m of filament seems like a better compromise than the extra complexity trying to special case this would bring. That said, the application of this idea to single color prints is on my "might do" list but near the bottom :-)

Based on this I'm going to mark this issue as "won't fix" so folks can find and read the reason...

platinumalloy01 commented 1 month ago

Thank you for responding, I figured it might not be feasible at this time, otherwise it would have been implemented already. Only reason I even thought about it was because of an issue I came across where the filament was unable to backfeed because it was getting trapped in the filament block at the buffer system, ended up being the Bowden but yeah, anyways issue resolved. Thanks again for the response and explanation.

moggieuk commented 1 month ago

You are right about the trapping in the buffer system .. some are more prone than others. Filamentalist will work quite reliably I think. The default ERCT can have issues. I know KinematicDigit is working on some improvements. Also, the v2.6.0 of HH includes a designated "waste gate" option so one gate can be used to dump filament fragment. This is experimental and suggested by KinematicDigit, but the downside is that the pre-gate sensors are ignored for runout because the filament must pass clear through the selector so it can select the waste gate...

k1-801 commented 4 days ago

I know this was already marked as "wontfix", but I believe there is a way to improve the EndlessSpool feature for the scenarios where it would be possible to continue printing with what is left in the filament channel.

The idea is to extend the gcode preprocessing in order to add a parameter to every Tx macro that would specify the length of filament that will be extruded in the specified toolchange (i.e., before the next Tx macro or before the end of file). After the toolchange, we reset the counter to whatever length was specified, and, if we encounter a runout, we compare what is left with the length of our bowden tube.

From here, we have several different scenarios

If the user wishes to continue printing even if the bit will not be able to be unloaded automatically, they can specify the "extruder purge" length to be very long and mark it for manual removal.

Optionally, we can remember that a certain gate still has a certain length of filament mapped to a certain tool unloaded to it, and if we encounter a Tx macro with the same tool and a length greater than that, we can try to "use up" that piece. That would, however, require introducing additional statuses to gates ("R" for "Running out").

UPD: the preprocessing should not just sum up all the extruder movements, but actually keep track of the maximum of that sum, in case there is a large retraction move at the end.

UPD2: it would be really great to also have some kind of a customizable macro that can be called if manual intervention is required... To either put a "Beep" there, or even trigger a HA call so the user would be informed.

UPD3: Just realized that single-color prints may not have any Tx macros specified in them at all, but we still need to calculate the length and mark it in the gcode somewhere.

platinumalloy01 commented 4 days ago

Thanks man, this is awesome, hope it can be implemented.

On Tue, Aug 13, 2024 at 8:15 PM Dmitry @.***> wrote:

I know this was already marked as "wontfix", but I think there is a way to improve the EndlessSpool feature for the scenarios where it would be possible to continue printing with what is left in the filament channel.

The idea is to extend the gcode preprocessing in order to add a parameter to every Tx macro that would specify the length of filament that will be extruded in the specified toolchange (i.e., before the next Tx macro or before the end of file). After the toolchange, we reset the counter to whatever length was specified, and, if we encounter a runout, we compare what is left with the length of our bowden tube.

From here, we have several different scenarios

  • The remaining length in the toolchange is greater than the length of bowden tube. It means, there is no reason to unload the filament, and we can simply continue printing. If there is an extruder entry sensor, we can keep printing all the way until we hit that sensor, then we have to load the next spool. Otherwise, we need to follow the remaining bit of filament with the next spool for this tool since the moment we encounter a runout, in a synchronized manner. Ideally, the selector would move to the next spool and start feeding it wiithout pausing the print. The option with no extruder entry sensor should be available regardless of the actual sensor's presence, as such sensor may be too close to the extruder gears, and an arc gcode command could take too long
  • The remaining length in the toolchange is slightly shorter than the length of bowden tube (by a configurable amount, 10cm or so). It means, we won't have to follow it with the next spool, but there is no reason to stop the print, we can just eject the remaining bit through the nozzle. Optionally, we can ask for the user to just remove the remaining bit manually (should be configurable).
  • The remaining length in the toolchange is significantly shorter than the length of bowden tube. In this case, we unload as we currently do.

If the user wishes to continue printing even if the bit will not be able to be unloaded automatically, they can specify the "extruder purge" length to be very long and mark it for manual removal.

Optionally, we can remember that a certain gate still has a certain length of filament mapped to a certain tool unloaded to it, and if we encounter a Tx macro with the same tool and a length greater than that, we can try to "use up" that piece. That would, however, require introducing additional statuses to gates ("R" for "Running out").

— Reply to this email directly, view it on GitHub https://github.com/moggieuk/Happy-Hare/issues/340#issuecomment-2287606957, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXNOWG6JEI5GALG3YBLXLBDZRKVT7AVCNFSM6AAAAABKWBV6K2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBXGYYDMOJVG4 . You are receiving this because you authored the thread.Message ID: @.***>