mcbeen.com

Not having the filament buffer was a super pain. I’ve become rather dependent on it since I like using large 10kg spools. It just was not working well. In the past couple days I have found and solved a number of issues.

1. The gearing for the extruder turned out to have incorrect dimensions, and could not properly engage the filament causing skips and terrible extrusion. I went ahead and transferred in the parts from my old extruder, and its working fine now. I need to measure everything and figure out WTF is going on as this is not the first time I have run into this.
2. The buffer filament switch connection I was using on the manta v1.1 is no longer on the v2 board. I tried using a number of alternatives including the servo and induction probe, but none would run in the mode I needed for the filament switch. I ended up using the end stop pin from motor 6.
3. Buffer stepper would not power up. I had the motor assigned to m8, but for some reason it just would not work. I moved it back to m7, and it worked fine. I still don’t understand it.
4. I was having tons of issues with the filament switch events getting dropped. The cause was me trying to use filament_switch_sensor vs gcode_button. Getting this to work at all in vanilla klipper is a pain since klipper appears to act like a realtime solution. This means that some lower priority things just get ignored until klipper has spare cycle to deal with them. And that totally makes sense for a filament sensor. Its not a critical resources. To get around this in the past, I instead us a combination of a gcode button and delayed(queued) gcode. in the button I set a variable that lets klipper know that the buffer is full, and then starts a delay trigger for the gcode. Once the dlayed gcode triggers, it starts or stops the buffer stepper, and resets the trigger. If any of these events are missed, it can cause the buffer to jam and fail the print. The gcode delay is great for this as it just keeps retrying execution until it gets through. The buffer generally has 2-3 seconds of filament in it, so plenty of margin. So. I put things back the way they were before, and re-enabled the duplicate pin function so I could still read out the status in mainsail.
5. After all that, I did my first major test print, just to find x and y to be drifting all over the place. Like the printer was drunk. It appears to be missing steps due to high microstepping. I had it set to 256, I lower it back to 16 like it was with the TMC2209s. The steppers are a lot more noisy now, with no real benefits that I can tell. I may just switch the drivers back to the 2209s. Do I really care if they run in spi vs uart? It’s all just serial anyways.

A second print seems to have confirmed the issue is solved.

I think I have found a good 4-1 ECAS filament hub finally, and plan to start working on adding a second buffer to the printer so I can start multi material swaps.

One other small thing annoyance: the error “Communication timeout while homing Z” is still present with the new MCU. so the problem is either with the the toolhead MCU, or something related. I have seen complaints of the LED driver causing problems, but I’m a bit skeptical. So once again I’m back to upping the TRSYNC_TIMEOUT value in “/home/pi/klipper/klippy/mcu.py” file from 0.025 to 0.050 each time I update. I was really hoping the new katapult/klipper firmware would resolve all of this.