Hey all. Need help !
+Peter van der Walt and I are going to be working on a project : https://github.com/arthurwolf/fabrica
I’ve started coding it a bit, and I’m getting to a point where there is a huge non-programming task to do, that would be reasonably easy to get done by many folks at a time.
The task is essentially to describe all of Smoothie’s configuration options : their name, a short description of what they are, their type, their unit, and a more complete few-lines documentation.
The file that needs to get added to is here : https://github.com/arthurwolf/fabrica/blob/gh-pages/src/screens/configuration/definitions.html
You essentially need to do what has been done for the first few options, but for the rest of them.
Note that you don’t even need to know GIT : If you have a github account, you can edit the file directly from the github website.
If anybody wants to help with this, please let yourself known. It’s relatively easy, and it will help a lot make something really awesome for everybody.
Counting on you !
Cheers 
Arthur, I can start working on it Monday the 21st. Shouldn’t take me too long to finish. Let me know if you want me to proceed with this, or any other documentation you need help with. Not too busy helping Peter right now, so I have the time available.
I’ll be ready to submit a pull request in an hour or so, I’m about 1/3 of the way through.
Neat project. Our “micro host” approach also tackles the UI for small screens. It’s not android specific and will probably run locally on a rpi. It separates a minimalist UI via web (local or cloud) and a color touch LCD running its own UI also connected to the server. It’s really two separate systems that either stand alone or work together. The local touch screen w wifi adds additional functionality, or maybe better explained by saying it adds further ease of use.
Mobile screens are good but the slight lag and not-always-on nature of phones gives a local, instant and always-on touch screen an edge for quick manual control and in-the-room monitoring.
Our micro host will mimic current offerings if they had a touch screen. They will be hackable (open source) to theoretically run any RepRap as a wifi host computer to send gcode to the printer. They also leverage ridiculously cheap components and ultra light communication to the web/web server to both keep cost and requirements down. No current UI is pushed to the small screen from the micro host- all UI for touch screen is internal and all UI for small screen control is hosted on the server (local or cloud). This keeps everything light, modular and responsive.
The cloud brings different features like messaging, sharing, persistent access to the print queue, bot farm access to multiple people on separate accounts, fast slicing, services and someday perhaps access to model repositories.
Focusing these projects first on Printrbot hardware narrows the scope and has forced us to quickly solve problems inherent to current electronics. Problems you won’t be able to solve easily, I fear. For instance, Marlin has bare minimum communication outbound to inform any host of what is or isn’t happening, so we have added json communication of a bunch of things the host may need to know. There is a list of deficiencies in Marlin that we addressed. Also, adding features like a filament sensor make the most sense in firmware, not the host, so we can add those to firmware.
I love that this project addresses a need in the now-stale niche area of host UI, so none of this is intended to discourage. It’s fun to see two different approaches to some of the same problems. Maybe we can both be a part of driving some renewed innovation toward the overall problem state of user experience!
Brook
@Brook_Drumm Have a link ?
No links yet. It’s all in development currently. Just spilling the beans a little.