Faster Printing requiring Filament Buffer feeding

[goofballtech]

On 11/17/2025 at 2:41 PM, ss1gohan13 said:

If everyone can give me a little more time to work on this, I'm happy to try and make the config better. 

One of my biggest goals was to have this device not appear as an additional extruder on the system. With that, I believe that I over complicated the in's and out's of how I was remembering the buffer to work OOB. 

My overall goal is to achieve/keep:

- Remove the "extruder 1" from the config
- Auto filament loading until the buffer hull sensors trigger
- increase the feed speed/alter the feed rate/remove pulsing

And the basics like filament run out. 

EDIT:

If anyone wants to fork what work I've done thus far, please do so. 

I am working on some of these. I didnt do it as a fork though but i certainly used you repo an the klipper flash and base config. i have loading and unloading working. I have it set up as a manual_stepper so its not an extruder. Working on trying to get auto feeding clean at various flow rates without letting it hit min or max constantly. It has been a challange finding that balance. May end up with a slicer variable tell me the max flow rate or something so i can tune per print... not sure yet. 100% going to share when i get it level though. 

@Penatr8tor Moving the talk to this string since i dont want to highjack the other physical build thread. 

[goofballtech]

@ss1gohan13@Penatr8tor

I am still trying to tweak the auto to be able to keep up with a range of feed speeds. I just forked your repo and dropped my modded config into there. I have load and unload and all that working well but those are controlled from my main macro.cfg file using the functions present in this config. Things like a long single move on load based ont he entry sensor state then inching up to the nozzle from about 200mm away. Fill the buffer then start the load portion. On the unload side i fill the buffer to 50%, do the tip forming, then have the buffer pull the filament at a lowered current while the actual unload happens. Then pull back 2 meters of filament which gets me back to the buffer. Seems to be working pretty consisatnly after days of cursing and pulling things apart to unclog jams. 

I have been through a varity of methods to control auto and keep up with print speeds ranging from 5mm3/s at the nozzle up to about 30mm3/s at the nozzle. Since the macros are limited in how they can respond and are not true coding logic like the stock firmware uses i am limited in how i can handle those bumps in a "live" way.

• I started with just static bumps but the next state read would happen before the move was done. That "double bump" would cause the toolhead to pause. 
• So i added a read delay to prevent the double bumps, this would work ok at the lower speeds but the delay would cause the buffer to run out at higher print flows because it was too much. Makign the delay too short would cause the slower flows to just have the buffer max out and extuder to slip as it kept trying to feed extra because the double bumps would come back. 
• Then it was set so it had a seperate delay time for each size of bump based on how long that move is expected to take with that motor speed which helped a lot to prevent the double bumps. This is pretty close but keeping up with such a range of flows and tweaking bump size vs delay time is finicky. 
• I added the active flow to the debug log so i can see in one line when the buffer is low/high in the same lines with the flow in that moment. i am considering taking that active flow into account in some form of a dynamic way now. Just not sure how yet that will get along with the macro work flows. 

It works for the most part as it is now, i'm just trying to find a really good balance and it is a pain. I considered getting the flow rate from ORCA as a variable in print_start and using that to inform a buffer profile but the flow of a print at any given moment can change so much between long straight runs and bridges a more dynamic solution based on the print is prefereable. 

I was looking at the LLL-Buffed project and considering trying the stock firmware with I2C comms but i havent commited to that yet as i really wanted this klipper style to work. 

 

*Disclaimer, some AI was used in here to add variables to existing flows for tuning as well as to add comments because i didn't want to type all that crap out. 

[goofballtech]

Ok, my final straw of trying to get this to work consistantly over different print speeds. 

[extruder_stepper buffer0_motor]
extruder:
#   Empty on purpose. Buffer0 starts unsynced and is attached by macro.
step_pin: Buffer0:PC13
dir_pin: Buffer0:PA7
enable_pin: !Buffer0:PA6
microsteps: 16
gear_ratio: 50:17
rotation_distance: 18.80

[tmc2208 extruder_stepper buffer0_motor]
uart_pin: Buffer0:PB1
run_current: 0.4 # .2 to .5 is usable range. If using higher end monitor for motor heat
stealthchop_threshold: 999999

Side note - There are probably macros in this file that are overlap or not really useful in themselves. I was trying things and i never went back to do a clean pass and remove ones that werent used anymore. 

https://github.com/goofballtech/BufferPLUS-klipper/blob/main/printer_data/config/mellow-plus_syncd.cfg

I set this up as an exturder stepper so i can try to get them synced. I managed to force move the stepper and get the load and unloads working again and recreated all my base functions. I think it would work in theory. The pain for me was getting them to sync perfectly. I tried to do the normal mark, measure, extrude series like in ellis' print guide for the hot end extuders.

I tried to sync them and compare, i tweaked a bit up and a bit down based on how the prints were going and tried again. I just could not make them match long term. I dont know if they were fighting and causing skips over time or what.

I can put the buffer right in the middle before the print using the center macro and it would track closely for a while. For prints longer than an hour or two though it would work its way to the high or the low end ever so slightly. I would hesitate to set up and do multi-hour or multi-day print and be confident in the ability to stay sync'd. If i for a delayed macros to watch the buffer for min or max radings then the head pauses for amoment when it does the correction. Probably not the end of the word to happen once every couple hours (assuming a very tight calibration to start) but not ideal either. 

If someone has a good idea on how i can tie these together more consistantly or additional troubleshooting that may help that happen i'm open to ideas. 

I am installing the platformIO extension in VSCode so i can try the buffed version and maybe use the serial commands to do all the things i want but let the buffer be an island during a print. 

 

[therm_virtual0y]

20 hours ago, goofballtech said:

Ok, my final straw of trying to get this to work consistantly over different print speeds. 

[extruder_stepper buffer0_motor]
extruder:
#   Empty on purpose. Buffer0 starts unsynced and is attached by macro.
step_pin: Buffer0:PC13
dir_pin: Buffer0:PA7
enable_pin: !Buffer0:PA6
microsteps: 16
gear_ratio: 50:17
rotation_distance: 18.80

[tmc2208 extruder_stepper buffer0_motor]
uart_pin: Buffer0:PB1
run_current: 0.4 # .2 to .5 is usable range. If using higher end monitor for motor heat
stealthchop_threshold: 999999

Side note - There are probably macros in this file that are overlap or not really useful in themselves. I was trying things and i never went back to do a clean pass and remove ones that werent used anymore. 

https://github.com/goofballtech/BufferPLUS-klipper/blob/main/printer_data/config/mellow-plus_syncd.cfg

I set this up as an exturder stepper so i can try to get them synced. I managed to force move the stepper and get the load and unloads working again and recreated all my base functions. I think it would work in theory. The pain for me was getting them to sync perfectly. I tried to do the normal mark, measure, extrude series like in ellis' print guide for the hot end extuders.

I tried to sync them and compare, i tweaked a bit up and a bit down based on how the prints were going and tried again. I just could not make them match long term. I dont know if they were fighting and causing skips over time or what.

I can put the buffer right in the middle before the print using the center macro and it would track closely for a while. For prints longer than an hour or two though it would work its way to the high or the low end ever so slightly. I would hesitate to set up and do multi-hour or multi-day print and be confident in the ability to stay sync'd. If i for a delayed macros to watch the buffer for min or max radings then the head pauses for amoment when it does the correction. Probably not the end of the word to happen once every couple hours (assuming a very tight calibration to start) but not ideal either. 

If someone has a good idea on how i can tie these together more consistantly or additional troubleshooting that may help that happen i'm open to ideas. 

I am installing the platformIO extension in VSCode so i can try the buffed version and maybe use the serial commands to do all the things i want but let the buffer be an island during a print. 

You are way above me on this.  Thanks for sharing your experience and hard work!  I have a lll mellow fly pro buffer that just runs on OG firmware and only keeps tension off my extruder.  I have a PicoMMU but it keeps breaking so I need to reprint the newest one and start over.  Even with Happy Hare I will need a buffer switch to readjust the rotation distance of the pico to keep things in equilibrium.  I used to run it without the buffer but same as you are saying, things would get too compressed or too tight and my extruder would over heat on long prints.  Wish I could help but good luck and sounds like you are almost there 

[goofballtech]

On 5/16/2026 at 12:12 PM, therm_virtual0y said:

You are way above me on this.  Thanks for sharing your experience and hard work!  I have a lll mellow fly pro buffer that just runs on OG firmware and only keeps tension off my extruder.  I have a PicoMMU but it keeps breaking so I need to reprint the newest one and start over.  Even with Happy Hare I will need a buffer switch to readjust the rotation distance of the pico to keep things in equilibrium.  I used to run it without the buffer but same as you are saying, things would get too compressed or too tight and my extruder would over heat on long prints.  Wish I could help but good luck and sounds like you are almost there 

Yea. I ended up forking the lll-buffed version so i can do my nerdy macros but put it back in auto mode and let it do its own thing when printing. Their version had some of what i needed but i am building a tool changer and the filament/buffers/filamentalist rollers are in an enclosure the printer is sitting on. I2C is a finicky protocol on longish wires so i wanted to move the I2C portion closer to the buffers. I ended up using an Amazon CP2112 I2C/USB Bridge. So i am coming form the Pi as USB, going to a keystone on the back of the voron skirt and jumping down tot he bridge in the lower enclosure. The intention is to make the lower poertion 24 rolls of activly dehumidified storage in addition to the printing rolls.

Took a bit to get it all working but i am running flow tests now and have two spools operating I2C via Macros using a python helper in klipper. Tests look promising! Pictures and some basic documentation coming. Considering doing a proper write up or making a repo for the whole thing as the whole assembly is something different than anything i have seen. 

 

[NikosSprocket]

Nice setup!

Edited May 19 by NikosSprocket

[goofballtech]

Its coming along. i wanted to get one reasonable, then expand to 2 and make sure the changing and calibrations were ok, then go crazy with the rest. Im still working to get consistant tool changing and all the pins to line up every time and all the other tool changer\2.4 challanges. But man its cool to watch when its working. 

[therm_virtual0y]

Yes nicely done!  I have several filaments in a dry box and works great with the lll fly buffer but not for tool changes or even filament changes.  Really interested in building something like this and seeing what you come up with.  kudos. 

[therm_virtual0y]

just found this GitHub - Nitrooxyde/Mellow-LLL-Plus-Klipper-Firmware: Klipper MCU firmware for the Mellow FLY LLL Buffer Plus — autonomous in-firmware auto-feed (halls->TMC2208) + Klipper USB MCU runout. Best of standalone + Klipper. · GitHub

loaded it and it acts like the base firmware but now you have access via MCU and don't have to run all the wires.  Power and USB only

 

[goofballtech]

1 hour ago, therm_virtual0y said:

just found this GitHub - Nitrooxyde/Mellow-LLL-Plus-Klipper-Firmware: Klipper MCU firmware for the Mellow FLY LLL Buffer Plus — autonomous in-firmware auto-feed (halls->TMC2208) + Klipper USB MCU runout. Best of standalone + Klipper. · GitHub

loaded it and it acts like the base firmware but now you have access via MCU and don't have to run all the wires.  Power and USB only

Nice share! I must have been working this problem parallel to them. What i ended up with was to build the I2C firmware to include all the states so i can read the buffer status, force moves, etc. Esentially replicating all the native functions but via I2C commands and have tha bility to read the active status during macros like load and unload. 

I have one USB connection from my Klipper RasPi to the box where the buffers are located and an I2C bridge there. That bridge runs all 5 of my buffers that have different addresses so Klipper can query/control them individually. I need to Adjust the ReadMe to reflect all this in my fork of depau's lll-buffed repo. 

Edited 22 hours ago by goofballtech

[therm_virtual0y]

so its all working now huh?  thats awsome.  I have I2C because my toolhead uses CAN.  Im not familiar with how I2C works other than this default setup as a bridge.  I assume you have the buffers set up daisy chain?  I would be interested in trying it out.  I did find a different one GitHub - river29/Mellow-LLLBufferPLUS-klipper: Buffer Firmware · GitHub but it didn't work right on my system for some reason.  I think there is some other setup in the cfg files that i needed to do because  the hall effect switch wouldn't feed or retract when triggered.  

[goofballtech]

 

8 hours ago, therm_virtual0y said:

so its all working now huh?  thats awsome.  I have I2C because my toolhead uses CAN.  Im not familiar with how I2C works other than this default setup as a bridge.  I assume you have the buffers set up daisy chain?  I would be interested in trying it out.  I did find a different one GitHub - river29/Mellow-LLLBufferPLUS-klipper: Buffer Firmware · GitHub but it didn't work right on my system for some reason.  I think there is some other setup in the cfg files that i needed to do because  the hall effect switch wouldn't feed or retract when triggered.  

Not daisy chained. In parallel. So each buffer has an address 0x10 for T0, 0x11 for T1, etc. When doing a query the macro will call the python script and tell it which address it needs to talk to. That goes out on a common bus and only the properly addressed one takes the command or replies as needed. 

Below is an example of a simplified move command for illustration:

If i want Buffer_0 to move forward by 20mm. I would do

`BUFFER_MOVE_0 distance=20` for pushing to hot end or `BUFFER_MOVE_0 distance=-20` for pulling back to buffer. 

That would take all the below defaults for the other options and send a command to the 0x10 address as configured int he "Main Variables" block _VARS at the top of the file. That command is grabbed by the python helper and send to the CP2112 via USB where its then placed ont he I2C bus and goes to all the buffers. It's ignored by four of them. The 5 one that has the proper address would start moving. 

The second section of the macro is id i used the "wait" paramater. That for macros use in klipper. So i want it to move the 20mm and assume it is fine or so i want to wait for it to finish before i do the next thing. This could be like a load operation. If i want it to be at the hot end, command a move, as its moving i start rolling the extruder there may or may not be filment there to grab. So i want time/distance amount of milliseconds. Its not a "positive confirmation" but its close enough that the hard was a chance to get the job done before i do my next commanded thing. 

[gcode_macro BUFFER_MOVE_0]
description: Move Buffer0 a bounded distance using firmware MOVE_DIST
gcode:
    {% set vars = printer["gcode_macro _LLL_BUFFER_VARS_0"] %}
    {% set distance = params.DISTANCE|default(0.0)|float %}
    {% set speed = params.SPEED|default(0.0)|float %}
    {% set wait = params.WAIT|default(0)|int %}
    {% set auto = params.AUTO|default(0)|int %}
    {% set max_dist = vars.max_move_distance|float %}

    RUN_SHELL_COMMAND CMD=lll_buffer_cp2112 PARAMS="--addr {vars.addr} move --distance {distance} {speed_arg} --max-distance {max_dist} --allow-motion"

    {% if wait %}
        {% set wait_speed = speed if speed > 0 else vars.default_speed|float %}
        {% set wait_ms = (((distance|abs / wait_speed) * 1000.0) + vars.move_settle_ms|float)|int %}

        # Give firmware time to complete the bounded move before Klipper continues.
        G4 P{wait_ms}

        {% if auto %}
            # Return to native sensor control only after the bounded move window.
            BUFFER_AUTO_0
        {% endif %}
    {% endif %}

 Maybe more than you cared for? Not sure if you were commenting in passing or asking, but here it is anyway.