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.

So I started with the overhaul in earnest. After thoroughly lubing up the new rail, and getting it mounted, I attached the new CNC tap v2. The design is improved over v1, but the belts are as much of a pain to attach as before. The belt tensioner worked really well, even though the readout is confusing.

After getting the chamber done, I flipped the machine over to find the brackets for both the power supply and CPU had failed. Going to need a new set. I proceeded to transfer the connectors over to the new board, and reroute a lot of the new connections from the past couple years.

Held my breath, and flipped on the power. No smoke. printer powered up and I was able to connect in. No errors. From there I bumped all the steppers and found I had z3 flipped, so I just flipped the direction pin and then confirmed it was moving right. I then lifted the toolhead, and did an end stop check. The TAP probe seems to be working well. I held my breath and homed X, then Y, then Z. All went well, then I did a gantry level and that succeeded as well.

Testing the extruder went fine as well, so I decided to go ahead and attempts a test print. I was sure Z height was going to be off a tad, and I was right. One nice thing about TAP is the extruder has some “give” to it and will float a couple mm on the bed if you screw up. I ended up lifting Z quite I bit compared to the old sensor, but now appears to be giving perfect first layers.

Now that’s all settled, I tossed to ASA in the spool holder and printed up my new brackets for the MP8 and PSU. Printing came out well! Not too bad. Flipped the printer up and installed the new brackets and got everything secured.

The only issue I’m tracking for now is the filament buffer switch is not triggering. I don’t know if its programming or hardware, but I’ll need to track that down. For now the main extruder is working ok by itself. Over all a very successful maint.

I began maintenance on Koth this morning, starting with removing the toolhead. I have a replacement TAP that uses an optical sensor instead of a microswitch. After removing the old TAP, I found its rail was mostly seized with filament debris. The switch was still operable, but barely. Additionally, the X rail on the gantry was gouged, and the carriage was excessive debris in it as well. All of this is strange as things were fine and lubricated recently.

I then took the extruder apart and found some rather severe damage on the rear motor plate. The failed bearing allows the axle to shift against the stepper, drilling a hole in its face.

Its obviously been overheating, and its failed pretty badly. Looking over my config, I had the current set at 1 amp, so I’m going to drop that down and maybe put a sensor on it to track its temp. I also found some damage on the blower housing where the power cable for the heater core runs through.

The screw that hold the housing in place seems to be limiting damage, but I may been to add some insulation here.

On a positive note, the copper brush I use to clean the hotend is working really well. I just need to shift the brush a couple mm to cover the entire face.

So I have ordered up a new X rail that should be here this weekend. I’m unfortunately kind of stuck until then.

Last night I was able to get the new RGB toolhead lights reprogrammed for the 10 neopixels. This afternoon I finally got around to configuring the shutdown relay for the bed and heaters along with testing the new TMC5160T drivers for X/Y. I have had them forever, but have been too busy with other issues and printing. This is a perfect opportunity. Up until now I have operated everything in uart mode for simplicity, but the 2130 and 51260 require SPI for communications.

The Manta board is setup to jumper all the communications pins into the driver rather than just the data/CS/uart pin. I plugged in all the jumpers for X. Then grabbed a generic config for the TMC2130(X) and pasted in before my TMC2209 block.

## Motor1
[tmc5160 stepper_x]
cs_pin: M1_x_uart #CS/uart data pin
spi_software_mosi_pin: M_MOSI
spi_software_miso_pin: M_MISO
spi_software_sclk_pin: M_SCK
#diag1_pin: PF4
run_current: 0.800
stealthchop_threshold: 999999

Commented out the old driver block, and then renamed the new block to be TMC5160. Next I replaced the pins on the section with aliases I had previously configured, then reloaded. Once it came back online, I ran a quick query:

DUMP_TMC STEPPER=stepper_y

The printer dump all the registers and confirmed communications. It looks like I’m good to go. I then followed the same steps for the Y stepper driver and confirmed it as well.

When I first decided to go ahead with this upgrade, I of course looked over the change log for this new revision to get some idea of what I was in for.

V2.0 Upgrade Notes
 Upgraded MCU to ARM Cortex-M7 STM32H723ZET6 550MHz.
 Added interfaces: servo, I2C, 5V detection, TFT expansion ports.
 Changed EXP1+EXP2 to FPC connectors.
 Increased USB output current.
 Added large-capacity energy storage capacitors to the 5V circuit,
especially at the core board 5V input port, to prevent the 5V supply from
breaking due to excessive current during CM4 startup.
 Upgraded 12V power supply for increased capacity and resistance.

There are a couple items that made it worth while to me. The largest being the updated MCU. Butt here was one thing not listed here in the changes that has kind of thrown me for a loop. All of the pin-outs have changes addresses.

My biggest complaint about Klipper and hardware vendors has been the lack of standardization on pin addressing or aliasing.

• Klipper should have a community maintained list of available PIN names for as many functions as possible, all named in a predictable fashion
• ALL hardware vendors should be required to produce an alias file that maps their internal pin addressing to the Klipper standardized PIN names

This accomplishes two important goals.

• All macros and Klipper CFG files now become hardware agnostic.
• Klipper configs can easily be moved from machine to machine without localized readdressing
• Klipper based printers can easily swap out MCUs by simply swapping out an alias file to match.

So frustrating. I had started on this the first time around, but never fully adopted it as I was not familiar with Klipper. Now, I’m building up an alias table for the new board, and will post it once I finish the migration.

When I first built Kosh, canbus was still in its first weeks of release, and getting it going was a challenge since very few had gone down this route. Klipper/canboot was still being loaded raw in DFU mode making updates difficult. This time things are far easier with help from Esoterical and Butter Pocket Prints.

I did run into one snag though. Since I’m upgrading to a CB2 and Manta Mp8, I went ahead and pulled down the latest linux image from BTT that’s based upon linux 6.1. Everything went really well until I tried to bring up canbus on netplan. I was able to get netplan to see the interface, but nmcli just refused to bind or configure it. The linux distro has legacy networking disabled, and I didn’t like the idea of shutting down netplan and reverting. So instead I pulled an older linux4 version that worked perfectly.

Katapult loaded without issue, and chain-loaded Klipper with canbus enabled.

Relevant info:

• Mainboard flashing info
  • Instructions for mainboard
• Toolhead flashing info
  • instructions for toolhead

The basic idea is this:

1. Load Katapult (bootloader/flash tool)
2. Load Canbus enabled Klipper using Katapult

Command history:

service klipper stop
cd ~/katapult/
make menuconfig
make
lsusb
sudo dfu-util -R -a 0 -s 0x08000000:force:mass-erase:leave -D ~/katapult/out/katapult.bin -d 0483:df11
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
python3 ~/katapult/scripts/flashtool.py -i can0 -q
cd ~/klipper
make menuconfig
make clean
make
python3 ~/katapult/scripts/flashtool.py -i can0 -q
python3 ~/katapult/scripts/flashtool.py -i can0 -f ~/klipper/out/klipper.bin -u 0ac8f7c0c631
python3 ~/katapult/scripts/flashtool.py -i can0 -q
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
service klipper start