Okay, so we started last weekend with zero working printers and ended up with zero working printers. Let’s see how this weekend goes…
The SKR Pico and Formbot support
Yaaj on the Vorom forums had the same problem. I’m unclear on if it’s “Hey, we really need to get a small Ender-sized board out that doesn’t use a STM32 because we exhausted out favors out of our suppliers and the RP2040 is still available” or it’s there to make it a bit easier to not screw up the wiring.
Hard to say, in spite of having very strong opinions on a bunch of things, I’m absolutely not a trained electrical engineer. I will be trying my hands at rework for this SKR Pico when I have a replacement at hand.
Either way, I’m not sure if I were to get angry and replace it with … say the SKRat … I’d have a second crappy board because everybody just tolerates bad BTT boards or if it’s just that I need to get a board from someone else.
It took a bit of back-and-forth but I was able to convince Formbot to send me a new SKR Pico, but it’s on the way.
The Klipper Expander I already have…
It hit on Wednesday that I have a complete and reasonable solution to my problem already.
I got myself a Klipper Expander because it seemed to be useful. And it’s able to handle 3A per MOSFET, which means that 24V × 3A = 72W, which is more than the hotend is capable of. Which I was in the middle of something else so I didn’t remember how ampere the capacity of the MOSFETs were so I realized that, worst case scenerio, I can breadboard a Klipper-Expander-like-thing solely using parts sitting around my geekroom.
While the RP2040 devices can just mount as a filesystem, STM32’s use DFU, so I had to re-arrange my dockerized provisioning scripts. I’m not sure what the final version thereof is, but this works well enough for now. Because each board has a unique klipper.config file to drive the build, I now have a build-image-skr-pico.sh script that loads the config for the SKR Pico and a /home/wirehead/klipper/build-image-expander.sh script that loads the config for the Expander, plus a /home/wirehead/klipper/dfu-utils.sh script that runs dfu-utils inside of the docker container.
Once I got that moved over, I was able to follow the Klipper Expander flashing guide to flash the firmware.
Bonus points: I have a DIN rail mount that I’ve already printed that can be pressed into service as a temporary bracket.
A digression on Klipper and commercial printers
I would suggest that a lot of things in the open-source and reprap-derived world of 3D printing may tangentially or otherwise make some people some amounts of money, but one thing I do push back hard on these days is the idea that an open source developer must necessarily act such that other people can make money on their hard work.
Klipper and the way that it has been structured make this a bit convenient at the cost that commercial klipper products will cause you to eventually waking up, realizing that your 3D printer has filled your house with autonomous killbots.
Klipper requires a reasonable chunk of a real operating system. This makes all of the higher-level Klipper tasks real easy because you can just write yourself some Python instead of screwing around with Arduino firmware.
However, it’s basically impossible to package a complete operating system plus Klipper in such a way that it doesn’t necessarily phone home and that it won’t eventually get hacked in a distributed fashion such that a bunch of people wake up to house-fires and/or a geekroom full of autonomous killbots. It’s sadly part of the nature of the beast and why IoT devices, as a general class of devices, kind of suck. This looks a lot worse when you realize that doing this right requires that you need have a company with a well-developed site reliability and software infrastructure team, including people who know security very well… and then they also have to get good at all of the mechanical and sourcing and everything else… and then they have to deliver the printer at an astonishingly cheap price. Bambu’s misstep where they triggered phantom print jobs in the middle of the night is one example of the difficulty here.
Vorons and other open source printers don’t solve this problem, but at least it’s now my problem to patch my own darn Linux devices, which I can do using whatever patching mechanism is appropriate for the environment within which I exist.
Mainsail + Moonraker + Klipper
What wasn’t initially obvious to me is that Mainsail and Fluidd don’t have a server-side component to them. But, yeah, any storage is done in the browser or on the local machine.
Which makes things make a lot of sense. Of course neither Mainsail or Fluidd would have plugins because everything’s in the browser!
So I ended up setting up Mainsail on my NUC using an Ansible-ized version of the instructions, making a simple Ansible role named klipper-control to represent the control plane, and then I used a config file that looks something like this:
{
"defaultLocale": "en",
"defaultTheme": "dark",
"hostname": null,
"port": null,
"instancesDB": "json",
"instances": [
{ "hostname": "xxx.xxx.xxx.xxx", "port": 7125 }
],
"remoteMode":true
}
Klipper and Moonraker took a bit more effort. I’ve been adding everything to a klipper role that represents everything that needs to actually run on the Pi. I’m using the prind containers but only the containers, because I replicated what it was trying to do in docker-compose with Ansible.
Prind’s containers are hardcoded to run the process with a UID of 1000 which forced me to do probably the right thing, which was to create a klipper user to sit at that UID.
And then also, because Mainsail is a single-page-app with no functionality inside of the browser, you need to use the include functionality to insert a mainsail.cfg provided by Mainsail into the klipper.cfg file. This feels awkward in terms of long-term print-farm maintenance to me.
The advantage to the way this is working is that when I build a second Klipper printer, all of the pi-side work is completely done; it’ll go much faster than the non-containerized build processes.
Machine bringup
- I flashed the display using the V0 Display flashing guide to make sure everything was current.
- I checked to make sure I’ve got the same motors and thusly used the pre-calculated values from SrgntBallistic’s config to get started.
- I started going through the general Initial Startup guide first.
- I went through testing the fans and stuff and discovered that the Triangle Labs 3D sensor I put in place of the stock 3950 sensor has some bad wires, so it’s back to the stock sensor. Also, I realized that the hot-end fan wasn’t turning because the wires are reversed, so it’s back to the stock fan as well, ugh.
- Then I had to check out the sensorless homing guide to try and get that calibrated. It’s really confusing when you are calibrating because every time you run a
G28 X0orG28 Y0command, it will lower the Z axis slightly… which is arguably probably a safe operation, but this also caused some confusion. But I have a printer that’s properly homing. I ended up, while going through the process of setting up homing, using theM18code to turn off all of the stepper motors and manually re-setting the positions.
Summary
Everything seems to be working?
