mcbeen.com

After speaking with BTT, I confirmed that PS-ON(PD14) pin needs to be brought high on power on. This needs to happen before the RPI boots. So I recompiled the main MCU firmware to include this change, and flashed it. I’ll need to retune klipper next so I can make sure the printer cleanly shuts down when triggered.

Additionally, I have wired the E-Stop into pin (!)PF2. This is normally used for the Z endstop (motor 3) but I’m using a virtual endstop through TAP. When pressed the printer executes:

    {action_emergency_stop("Emergency Stop Triggered. Shutting down!")}

I’m still working out how best to cleanly shut down the rpi. I’m kind of surprised this isn’t already built in. Here are my power macros

[gcode_button ESTOP_BUTTON]
pin: !M3_z_diag
press_gcode:  
    {action_emergency_stop("Emergency Stop Triggered. Shutting down!")}

[gcode_macro POWER_ON]
description: Turn on the printer via the relay
gcode: 
    { action_respond_info('Switching Relay ON') }
    SET_PIN PIN=power VALUE=1

[gcode_macro POWER_OFF]
description: Turn off the printer via the relay
gcode:
    { action_respond_info('Switching Relay OFF') }
    SET_PIN PIN=power VALUE=0

[delayed_gcode shutdown_machine]
gcode:
     POWER_OFF
     {action_call_remote_method("shutdown_machine")}
     initial_duration: 0.0

Then Run

UPDATE_DELAYED_GCODE ID=shutdown_machine DURATION=1

When I want to power off the printer. Initial tests have gone well.

This requires the installation of a community module “G-Code Shell Command” through KIAUH

Since upgrading the electronics and firmware, I have had a very unusual error popping up randomly:

Missed scheduling of next digital out event

It appears this may be related to reattaching the webcam to the main MCU. I have disconnected it again to see if the errors goes away.

I decided to tackle getting the brush mounted over the weekend. While the assembly was pretty rigid when I printed it out, but now it feels like it has loosened up a lot. After adjusting it, I may glue the slides in position.

One of the big reasons I wanted to relocate the toolhead brush was to eliminate the need to home Z before cleaning. I use TAP for Z endstop, so the created a bit of a catch 22, that results in having to home the printer twice. Once to allow cleaning, then once again to get accuracy.

With the brush mounted, I can now just home X and Y, then scrub the brush. From there I can directly go home Z and then level the gantry.

With a few more optimizations I was able to to reduce motion_init by more than 50%.

Last night, I wired in the relay and immediately encountered a Catch-22 I hadn’t anticipated. The relay relies on a dead man’s switch signal from the MCU. However, the Raspberry Pi must set the signal high, and it takes longer to boot than the relay’s timeout period allows.

Complicating matters, I’m using an integrated MCU/Pi board without a dedicated power connection for the Raspberry Pi. As a result, cutting power to the 24V PSU shuts down the entire system, including the Pi.

I have asked BTT about this, and I’ll see what they come back with.

As an interim solution, I have wired the relay to cut power only to the SSR. I configured Klipper to assert PS-ON (pin PD14) at boot, which keeps the relay open after pressing the reset button. I’m still considering whether I want to enable this programmatically. For now, I simply press a green button when starting a print.

[output_pin power]
pin: PD14
value: 1
shutdown_value: 0

[gcode_macro POWER_ON]
description: Turn on the printer via the relay
gcode: 
    { action_respond_info('Switching ON SSR Power') }
    SET_PIN PIN=power VALUE=1

[gcode_macro POWER_OFF]
description: Turn off the printer via the relay
gcode:
    { action_respond_info('Switching OFF SSR Power') }
    SET_PIN PIN=power VALUE=0

I have added the POWER_ON and POWER_OFF macros to PRINT_START and PRINT_END. I’m not sure if I want to override the SHUTDOWN_HEATERS macro to simplify things.

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.