Amazing to see OctoPrint on HN. In a weird way I owe my career to it and specially Gina.
8 years ago I started working at a 3D printing company as a support engineer, where the UI of the printer was not up to par. In a short period of time during my off hours I developed a different front-end that could sit on top of OctoPrint. The printer was able to be sold again and I got offered a software engineering job. Gina was so helpful on IRC, she often pushed me into Python documentation instead of solving the problem for me. We build the first plugins for OctoPrint at that time. The plug-in is still running on many printers in the wild.
I have huge respect for Gina and OctoPrint, being able to make your opensource project your job.
I've been browsing Hacker News for several years now and this is the post that pushed me into making an account, just to comment here.
Klipper is a better choice in almost every way. It actually uses the CPU of your pi to improve the print, as opposed to Octoprint which basically just spits the gcode straight over to the microcontroller.
Upgrading to Klipper has been the second best upgrade I've made to my Ender3, with the best being a main board with silent stepping.
Klipper is a 3D printer firmware. You would compare it to Marlin, which is a common stock firmware on 3D printer microcontrollers. OctoPrint is a web application, built on a Flask/Tornado stack.
I agree that Klipper's features are excellent! The resonance compensation is most interesting to me. I'm someone who is deeply invested in algorithmically grading/estimating print quality. If you're reading this and want to learn more about how Klipper improves prints, check out Klipper's kinematics doc: https://www.klipper3d.org/Kinematics.html
Please note that Octoprint and Klipper are at different levels of functionality. It's not a choice between the two in any way.
Octoprint is for job management/monitoring and is SUPER extensible. It gives you a web interface/camera view/manual control of the printer. You can do things like install a slicer plugin so you can drop an .stl file into the browser then it will slice and print.
Klipper is more like printer firmware. It's lower level than Octoprint.
In practice, it is a choice between the two. Klipper based communities tend to stick to Klipper stuff and same with OctoPrint based communities. But yes, dedicated persons can use any combination of firmware + software that they want. It is one of the best parts of the open source 3D printing world!
Interestingly Klipper recommends installing octopi on their website: https://www.klipper3d.org/Installation.html
I think some of the comments here are too hard on octoprint, it is still kind of a universal pocket knife for 3d printing.
That's funny. I've been using octoprint with klipper for several years. I've tried to research alternative frontends to octoprint, and there doesn't seem to be a clear winner for klipper. What's the official klipper frontend these days?
What makes that the official UI other than the repo description? What's the deal with mainsail? Both fluidd and mainsail look like the same project. Is there drama? What UI does Kevin O'Connor use?
Has octoprint improved its slicer? From what I remember and accorded to a quick web search [1], the inbuilt slicer has been abandoned. For me, an inbuilt slicker would be worth mixing octoprint and Klipper firmware.
As an aside, I've been using combo of a container running xfce, cura, plus a vnc server and another container running guacamole, all on a proxmox host as a stand in as a web slicer.
I'll add that I prefer mainsail's ui to octoprint, but functionally they're basically equivalent, though I'll cede that Octoprint probably comes out on top as far as integrations. I had my Octoprint instance set so that I could control my 3d printers power relay through Home Assistant. I've yet to figure out how to do that in mainsail.
OctoPrint is meant to be used with many different 3D printers and their default firmware. But that also means it is restricted to using a common interface most printers support, and there isn't anything else than sending text-based G-Code directly. And even that has varying levels of brokenness on different printers, the manufacturers don't seem to care that much about interoperability.
Switching out the entire Firmware, which is what you need to do to use Klipper is an entirely different thing than adding a nice web UI in front of your existing 3D printer.
The author of OctoPrint also said that she tried at some point to convince people to define a binary G-Code format, but apparently that went really badly. A more efficient format for transferring the data to the 3D printers would help to avoid the problems OctoPrint has to fight to get reasonable performance when printing. But it does not seem feasible to get the manufacturers and firmware writers to agree on anything there.
Earlier this year, the "Additive Manufacturing Forward" program was announced. One of the goals of this program is to set industry standards and develop training/certifications. I'm hoping the NIST and other standards-governing bodies (ISO, ASTM, ASME) will be in a position to accept RFCs for printer communication protocols, Gcode encoding, and other standards within coming years. AM Forward puts a 1-2 year timeline on proposed milestones. (edited: typo)
The klipper community seems extremely hostile towards marlin and octoprint (which isn't really the same or replaces it) for what ever reason. Klipper is good but it isn't the "end all be all".
I personally use klipper together with ocotprint using octoklipper.
I wish there was more working together than this unnecessary hostility sometimes.
I remember Thomas Salanderer (a very prominent 3d printing YouTuber) saying he refuses to use Klipper just because of how toxic their community is. God knows what lead to that kind of behaviour around a 3d printer firmware!). On the other hand I’ve experienced nothing but friendliness from Gina and the Octoprint community!
I upgraded to klipper a long time ago over marlin, and whilst its great and improves print quality (especially on slow 8 bit boards).
It is not _better_ than marlin. Its very user hostile and generally the support between upgrades is very poor. Any error and Klipper will abort your print, when in most cases it absolutely does not need to.
Basically its great for fast printing but you are nuts if you think the everyday 3d printer should run it in its current state.
Totally, but the flip side of that configurability is i still cant get my filament runout sensor to work without klipper throwing an unrecoverable error and aborting my print.
Very strong agree. Octoprint is incredibly slow, bloated, and just a poor performer overall. Klipper + Mainsail is such an insane upgrade that I feel like a fool for sticking to Octoprint for so long.
Using Octoprint reminds me of maintaining a bloated Wordpress + jQuery blob website, and then someone shows you a snappy React version running on a cached edge provider. Night and day difference.
Klipper and Klipper based UIs are making huge strides. They are just so responsive and capable.
I am reading their website and I am a bit confused. It says, it's firmware. If I use Mainsail + Klipper, do I need to flash my 3D Printer's firmware to make it work?
2) You run Klipper's server software ("Klippy host") on a Raspberry Pi (or other single-board computer). Klipper provides a JSON RPC API for communicating with your printer, without having to worry about serial baud rates or other low-level details.
https://github.com/Klipper3d/klipper/blob/master/docs/API_Se...
3) You must connect Klipper server (Pi) to the microcontroller running Klipper firmware.
Quote from a klipper's benefits page I found [1] "Klipper uses the extra computing power and built-in algorithms to better calculate step movement times for motor actions, achieving movement precision of 25 microseconds or lower. Scheduling movements with an external computer also allows your machine to can carry out more actions in a given period."
It ends up meaning quicker, better quality prints. Input shaping and resonance compensation make a world of difference when printing quickly.
I also have a bltouch on my ender3; I found the bed leveling procedure with the bltouch to be way easier and more precise with Klipper.
Indeed, Klipper can work with an accelerometer and cancel out harmonic resonance in the printer. It is the killer feature of Klipper IMO — along with a configuration that is dirt simple (no compiling C and flashing firmware).
Of note of course is that some of this is theoretically possible via OctoPrint as well.
RRF supports both of those features, but hasn't been ported to many devices. With how hard Raspberry Pis are to get now, being able to run everything off the microcontroller is nice.
The improvements are mostly higher quality prints, especially when printing fast.
It also has a much better and more powerful configuration system. So for example if you want to edit the menu on the screen of the printer, you can, and it doesn't require a recompile.
Prusa's firmware has a lot of features that Klipper doesn't support, such as the crash detection and the auto-calibration. It's one of my printer of mine that I have no plans to switch to Klipper on.
I think what I'll do instead is get a good coreXY printer which runs klipper natively (like the Voron).
But I think I really want is a tool changing printer a la the prusa xl. Prusa tends to do a lot of up front engineering that you just don't see. Plus the support I've got from them has been just fantastic.
Congrats. I'm going to wait for the reviews before I order one, though I expect they'll be spectacular.
I feel like with the likes of the Bambu(sp?) X1 and their fancy shmancy lidar sensor, it's only a matter of time before Prusa is going to need to push that into their printers. E.g. the lidar could show width, heighth, and any stringing from the filaments -- ideally making it easier to determine the specs for a new filament.
I’m about 8 months in to 3D printing and I’ve done direct drive, bltouch and dual z upgrades on my Ender 3. Through all that research I’ve not stumbled across Klipper. I’m fascinated and excited about it. I think I like nodding my printer almost as much as prototyping parts for other machines I’m making. Thanks for your choice to signup and share this.
i've been running octoprint for a long time, but i'd love to try klipper just to experiment because i hear such glowing things about it.
the main thing that stops me adopting it is the absolute inability to get a raspberry pi right now to run mainsail on. i've got alerts set up for stock on plenty of sites, but they're basically like gold dust.
OctoPrint is what inspired me to create https://printnanny.ai/ - I originally released PrintNanny as an OctoPrint plugin over holiday break!
I ended up rolling my own Linux distribution (PrintNanny OS) to roll out over-the-air updates and share files/jobs/profiles across a mixed fleet of printer controller softwares (Moonraker API/Mainsail UI, Repetier, OctoPrint).
This and Obico/Spaghetti Detective are really neat. I've been wondering about a version that was aware of the intended model being produced and could detect failures by considering the exact 3D shape. It feels like it should be better at detecting something going wrong, but frankly the two cases you've got covered, spaghetti and shift, covers like...almost everything.
It looks like this runs entirely on a Raspberry Pi 4? That's pretty neat. As far as I know, Obico needs a significantly meatier computer.
Thank you! Your instincts are totally right. I've tried a few experiments using 3D model source as a model input, and...
The good:
It's possible to apply a segmentation model and "mask" expected real-world shape based on a mask extracted from the 3D source files.
The bad:
3D segmentation proposals are expensive to calculate/reduce (imagine rendering a point cloud). The 2D masking experiments I ran were low signal / high noise compared to 2D bounding boxes.
The ugly:
Your camera, printer, and slicer object rotation must all be very carefully calibrated and anchored.
I have ideas about how to use stereoscopic cameras to run an automatic calibration routine, but haven't had time to roll out experiments. If you're curious, I gave a talk about PrintNanny's print quality model [1].
Also yep, I run a TensorFlow Lite model and post-processing directly on the Pi. I'm actually working on a blog post about this now! [2]
Besides TensorFlow Lite, the key pieces of technology in the computer vision stack are gstreamer [3], gstreamer's Rust bindings [4], and nnstreamer [5].
On the calibration side, would it be possible to use fiducial markers (even a single Aruco) on the print bed to make an ortho projection of the print? You have the issue of print rotation relative to the bed, but I don't think there's an easy way around that if you allow removable beds. My gut feeling is that stereo would work but it'd be a pain to make reliable. ToF using something like a Kinect or RealSense might work at a coarse level (few mm).
I did try inferring depth distance from strategically-placed round colored stickers. Using 1 fixed camera, I didn't see noteworthy results until I cranked up the resolution to 1080+ with FP64 inputs. I used a UNET architecture with skip connections between 1/4th, 1/8th, and 1/16th resolution samples. Diagrams here: https://photos.app.goo.gl/xLmE9Xp7UYmekBwV6
Keep in mind that PrintNanny's video encoding and neural network pipelines are running on-device, so real-world results favor models that perform well when u8 quantized at 320p resolution. The constraints are part of the fun, but there is a bias towards techniques that retain signal when the model is compressed. Segmentation and depth models naturally lose fidelity in that scenario compared to a dead-simple CNN/SSD pumping out bounding box proposals.
Have you ever considered adding microphone support as an additional stream of data for diagnostics? Having sat next to my printer for many prints, seems like there are some audio cues you could tune in on.
I think your intuition is spot on (and I used to listen to my 3D printer before PrintNanny)!
Microphone input is on my experiment list, but I don't think I'll execute on this idea any time soon. I think the mechanical failure detection is "good enough" at the moment, so I'm now focused on stream-lining the experience of managing lots of printers.
Workflow automation (like printing shipping labels or batch QR code labels) and fleet management are at the top of my priority list. The AI is fun and flashy, but it turns out people just need a CRM for 3D printing.
I had planned to install OctoPrint on a Pi4 to leverage my printer as well but I would never have been able to conjure up something this extensive! Thank you for making it and sharing it!
Thanks! OctoPrint's plugin system is what helped me ship a prototype quickly. The project would have ended up in the elephant graveyard otherwise. All of the optimizations (building tuned Linux kernel, rolling a distro, porting code to Rust) would have been daunting without OctoPrint's maker community cheering me on and enthusiastically testing PrintNanny.
I'm using SWUpdate. I distribute an image with a [boot, rootfsA, rootfsB, data] partition scheme [1], and subsequent updates target the non-active rootfs partition. You can even theme SwUpdate's CSS [2] - nifty!
When I was assessing options for over-the-air updates, I evaluated everything between Mender.io (completely managed update service) to building a Coreos distro with OsTree-based patch system. So far Swupdate has felt like the right trade-off between customization and ease-of-use - plus the trail I've walked down feels well-traversed.
OctoPrint is the gold standard for running / monitoring 3D prints. I tried using the Creality cloud tools that shipped with the CR10S, but they paled in comparison.
At the end of the day, I removed the onboard chip that connected to the Creality cloud so I could plug in a raspberry pi with octoprint.
I love Octoprint. The only downside I've run into is that suddenly I've lost all of the smarts the printer had. It didn't seem like that was much of a downside, but for instance the Prusa MK3s could recover from a power loss automatically and resume right where it left off, but once Octoprint was added, that was gone.
But on the other hand, suddenly I've got remote access, permissions, cameras, all sorts of plugins for timelapses and bed level monitoring and all sorts of things. It's generally a great trade-off.
I do wish it had better support for mobile devices. It's weirdly hard to get a Raspberry Pi at the moment, but a bunch of folks have an Android or iPhone a few generations back with a cracked screen or whatever that would do a great job. There are some options, like Octo4a, but they've got some rough edges.
Octoprint is such a huge improvement to the 3d printing experience, combined with some custom Marlin firmware, it drives status messages on the build in display, it shows detailed error messages on the web interface, the plugin ecosystem is incredibly robust, and being able to have the webcam feed on a separate monitor to watch for failures while I'm working are invaluable. I don't think I'd want to use my 3d printer without it.
I go back and forth with it. I do use OctoPrint plugins for bed leveling and as a gcode terminal. But, I mostly print from the SD card because I have a Prusa MK3S and it has power panic support, so a print can be salvaged if power dies in the middle of a print. Additionally, I like having print stats and the printer only accumulates print time done over the SD card. Having OctoPrint work with the SD card is brutally slow.
I also turn my printer off when I'm not using it and OctoPrint's auto-reconnect doesn't work most of the time. If someone isn't paying attention and tries to connect while a print is running, it causes the printer to reboot, which isn't fun. So I largely leave it disconnected. I don't have a camera though. If I were making videos of my prints I'm sure I'd rely on OctoPrint more.
My work flow changed from using one printer to using 8 of them. Octoprint is great but I haven’t taken the time or expense to set so many up since each would need their own pi. They are hard to find these days for a reasonably price. It was great when I did everything off the one printer though, I used an aftermarket runout sensor for filament on the gpio pins of the pi. I also kept track of my filament usage, used the webcam for monitoring from my house to the garage, and arc welder plugin to improve some of the prints. I am still a supporter of the program but I now just organize my SD cards neatly and manually sync them all with updated files. If my operation was bigger I would probably organize a networked solution like octoprint though.
If your operation expands and you want to chat about wrangling networked printer management software, shoot me an email leigh@printnanny.ai. I want to make it dead-simple to manage 10+ printers running a menagerie of software (OctoPrint, Moonraker/Mainsail) and firmwares (Marlin/Klipper). Happy to trade notes!
I run OctoPrint on a RockPi, but I also rolled my own embedded Linux distro (PrintNanny OS) to package this setup.
There are a lot of small papercuts, like OctoPrint using `vcgencmd` to measure CPU throttling. `vcgencmd` is part of Raspberry Pi's userland. Not a big deal (aliased to another util). I've also added WebRTC-based streaming to my build.
The recommended way to use OctoPrint is the OctoPi image, which is based on Raspbian / Raspberry Pi OS. The OctoPi image includes extras like haproxy and mjpg streamer for HTTP-based JPEG frame stream. If you end up baking a RockPi image, here's the OctoPi root file system for reference: https://github.com/guysoft/OctoPi/tree/devel/src/modules/oct...
no, there are many replies in here where people act as such and its kinda a mystery to me in 2022. many other SBCs are arm, and many others are running debian or and can easily run the same software without 'tons of extra effort because its not a rpi'
at this point the mere thought of setting up a sbc that isnt a raspberry pi is job security and frankly im not sure why. its not like the rasberry pi 1 days
I used it for seven years or so before moving to Klipper, and then I started using Mainsail on the same hardware for the more direct integration: https://taoofmac.com/space/blog/2022/07/09/1230
This is a great piece of software - I've printed hundreds of objects using Octoprint. I've also built a few custom 3d printers and since Octoprint runs on common Linux on a Raspberry Pi it doubles as a convenient tool for writing firmware builds to the printer, over the network. Octoprint uses standard APIs such as /dev/ serial ports and any monitoring webcam supported by Video4Linux. A great tool!
I’ve kept the patreon subscription LONG after my workflow moved away from using it. I used it for 4-5 years with my completely homebrewed printers and it was fantastic for it…and reasonable…and stayed reasonable…and was a lot like I remember FOSS being, so I make sure Gina keeps getting funded.
I might be going offtopic... but, what is a 'best buy' (cheap, but good enough) 3d printer for a hobbyist, that is compatible with opensource/linux stuff (like octoprint,..), and has the most "effortless" experience (so, more printing than calibrating and modifying stuff)? Preferably atleast pla and abs.
Ender usually has the best value (price to performance) but most of their printers require a little extra setup and ongoing maintenance. Their new "s" printers are pretty nice out of the box though. Prusa seems to be a pretty reliable brand too, and most of their models are highly recommended in the 3D printing circles I hang out in.
With 3D printers, "cheap" is inversely correlated with "reliable." Something like an Ender 3 will fulfill your requirements, but will require maintenance once it's been "broken in."
If you can find some more cash, a Prusa MK3S or the newer Bambu Lab X1 or AnkerMake will provide more consistent, reliable quality.
I love octoprint, it makes the whole printing experience so much nicer. The integration with Home Assistant is great and allows for automations like turning the printer off after finishing a job.
On the other hand, I don’t think “snappy” is the adjective that best describes octoprint
I use Octoprint, but honestly the UI is just awful.
Pronterface seems to be the standard goto look for 3d print software, but honestly it's not a good look, nor is it fun to use.
I see it as an extra tool in my toolkit. Sometimes it is best to use some wood. Sometimes it is best to design and 3d print something.
Currently designing and printing protection for my racing bike shoes; those shimano cleads wear quickly when walking. I need to walk quite a bit before being on the street and also like to take a break somewhere at a restaurant. So I designed some tpu clead-protectors.
Also use my self designed kitchen-aid tool-hangers are used a lot. I have made hooks to hang the espresso machine filter holders on. Used daily. A pin to fix something in my car. A button for the piezo starter on my parents kitch hob. Handles, USB charger case + hangers for cables... parametric-configurable stand for plant pots. etc etc.
But you need some 3d cad skills. Downloading existing models and printing them does not offer that much. Im a developer who studied mechanical engineering :) I worked at Ultimaker as a developer. Worked on their digital factory, a cloud offering for their printers.
My kids tease me because they say all I print are things to hold other things. For example, I printed a bracket to attach a 4-port router and a USB power supply to the underside of my desk. I’ve printed tool holders and little boxes to store 3d printer parts in. I printed a stand to hold my laptop in clamshell mode.
I’ve also printed jigs and router templates used in some minor woodworking projects.
Not super useful, but it’s pretty satisfying to have and idea, create it in TinkerCAD or Fusion, then see it materialize on the build plate.
I fix broken stuff for my house all the time. A 50 year old exterior crawlspace vent broke, and so I modeled up a new one and printed it in two pieces. Sliding closet door brackets, folding table feet, pieces for light fixtures even.
I replaced a Hi-ho-cherry-o board game piece that got mistakenly thrown out.
I've made anti-tip brackets for furniture.
I made replacement nuts for a handed-down Fisher Price activity center.
I made a new encoder wheel for a Logitech force feedback joystick.
I made a sharpie egg plotter a few years ago. That's fun to pull out for Easter. I can run the same gcode files from previous years.
My half-decade hobby project has been to build a force feedback steering wheel from scratch. I started it before I got into 3D printing. Printing became my hobby for a few years, and last year I started over with primarily 3D printed components. I did some prototypes with cycloidal gearboxes, but it was a dead end. I designed a compact 2-stage planetary gearbox with an 80:1 reduction and printed it all out. I printed a bracket to mount all the electronics. Most recently, I printed a slick dashboard for it in wood PLA. It's pretty much done now, and looks pretty. It's a full size steering wheel, and can put out more torque than you would ever want.
Most recently, I printed out some custom play coins for my daughter's preschool. They have our dog's face on one side, and the school's name on the other.
Which parts of OctoPrint (or other printer management software) do you miss most when printing SLA?
I have a Prusa SL1S Speed and the network file management [1] is good enough for my personal use, but I've always wondered if there's a missed opportunity here.
Haven’t toyed with it for a while and might not serve your specific use case, but I used this with my custom-made dlp printer : https://www.nanodlp.com/
My controller was a simple stepper motor and display is a DLP projector.
Might not support esoteric controllers and displays though.
8 years ago I started working at a 3D printing company as a support engineer, where the UI of the printer was not up to par. In a short period of time during my off hours I developed a different front-end that could sit on top of OctoPrint. The printer was able to be sold again and I got offered a software engineering job. Gina was so helpful on IRC, she often pushed me into Python documentation instead of solving the problem for me. We build the first plugins for OctoPrint at that time. The plug-in is still running on many printers in the wild.
I have huge respect for Gina and OctoPrint, being able to make your opensource project your job.