Originally shared by Arthur Wolf
On Octoprint and why I’m a hypocrite :
One of the main ideas in the Smoothie project is : let’s make a controller that’s for all digital fabrication machines, so that for example if somebody codes grid-based bed probing for 3D printers, CNC mill users can profit from it for PCB milling.
That way work contributors do is useful to many more people than if we had projects for each machine type.
It’s all about preferring integrating rather than forking, and compromise : Smoothie has a few years now, and is still ( mostly ) a single project, that has been able to integrate new features rather than requiring their implementers to start their own project, or fork.
Now I’ve recently had to solve a problem : Smoothie’s web interface sucks. We have an ethernet port on the board, it can serve web pages, and all we’ve been able to put on there is this super minimal/basic/barebones/ugly page. It works, but it doesn’t do much.
Now when trying to solve that problem, I went immediately to : « Let’s make the best web interface of all times … and let’s start from scratch ». It was going to have modularity, and shiny buttons, and you’d be able to design directly in there, and it’d support lasers, and dropbox, and unicorns and chocolate ( - YouTube ).
I worked on that for 2 months, and in the end all I had was a super great framework to build a web interface on, but it didn’t do anything useful. People offered to help, but it was about as much work getting them up to speed with how things were supposed to be done, as it was to do it myself. A year later, still not much more has been added ( GitHub - arthurwolf/Mousse )
*So, I’m a hypocrite. *
Why start something from scratch, when the Open-Source digital fabrication community already has a perfectly fine web interface : the awesome @OctoPrint …
Not only did I fail at getting the project anywhere interesting, but if I had gotten it to work, I’d essentially have been dividing efforts where they don’t need to be divided.
After all, not duplicating efforts is what Smoothie is all about …
So, it took some time to realize that mistake, but I’m throwing Mousse into the garbage can, and I’ll be working on adapting +Octoprint to be able to run on Smoothieboards.
There are some obvious problems with that : for example, Octoprint requires a python server to run. You can’t run python on a Smoothieboard.
So we’ll essentially need to modify the web interface side of Octoprint to be able to talk directly to a Smoothieboard over http.
I’ll start doing this in a fork, but hopefully once we’ve proven it can work, we can find a way to get this to integrate in a clean manner into the “normal” Octoprint. I’m not sure if that’s something @foosel would be interested in merging back in, but we’ll cross that bridge when we come to it.
Anybody want to help ? 
Challenges :
- Get all of octoprint into a single html file. Smoothie doesn’t like to get many files requested at once. Already did that for Mousse, so should be easy to port.
- Get octoprint to talk to Smoothieboards. Will probably do this by adding some javascript code that’ll replace some critical bits of how octoprint talks to it’s server, and make it think it is, when it’s actually a Smoothie answering.
- Add some smoothie-specific features, like wizards for configuration, and figure out how to do these both as addition to the original unmodified Octoprint, and to the modified Smoothie-specific octoprint.
Yay, adventure
Smoothie essentially allows you to send gcodes as http requests, and get an answer, that’s about it, it’s very simple.