As I have ranted about a couple of times already, what makes developing host software (aka OctoPrint) tremendously difficult is the heterogeneous protocol environment that is our current state of the art in consumer 3d printing. Since there is no well defined standard of communication every firmware under the sun does it slightly different enough that getting a communication layer to work with everything, ideally without the user having to configure anything, is a huge nightmare. (Just to avoid any confusion: I'm talking about the communication between the host software, e.g. OctoPrint, and the firmware on the printer, e.g. Marlin, which usually happens via serial)
After my initial rant a couple weeks ago (see further below in this collection) a healthy discussion in the comments of that post ensued and made me give in and - with the help of +Andreas Gohr
who provided the wiki and +Justin Nesselrotte
who acted as a valuable sparring partner - start my own attempt at trying to get a minimal standard together.
Thanks to work on OctoPrint's imminent next stable version and some private stuff my pace working on this has been way slower than I'd hoped, but the ground works have been laid. In the meantime another issue with Marlin made me show what I already had over in their bug tracker, so I thought why not give out the link here too :)
My current approach:
- Wiki with limited write access but public discussions - only for the initial collaborative effort to get a definition done, the final spec would be read-only and static, I'd suggest something like hosting it on github pages ("reprapcode.github.io
" or a custom (sub) domain even)
- Defined transport protocol as close to the current realities across the multiple firmwares as possible, basically a subset of all possible variants we have today - to minimize adaptation impact on both host as well as firmware developers
- Proper definition of requests and responses (this is something that is lacking nearly completely right now, leading to things like four or five different possible versions of a response to M105 alone)
- Properly defined points for vendor extensions (we need to end this "M4711 does X on Marlin and Y on Repetier" madness)
- Proper documentation of effects on the printer
- Responsibilities of the host & of the firmware in terms of request/response processing
- Long term: Proper test suites to allow hosts and firmwares to test their compliance with
My goal with this right now is to create a basis for discussion first and foremost (there's disqus setup for that). I'm still far off a complete spec so no need to rub that in, a day only has so many hours ;) But if you want to get an idea of what I mean with "well defined" requests and responses, take a look the M20 spec in that page.
Now, I hope that I can get some of you 3d printing people out there to make this less of a "me" and more of an "us" thing so that the life for us software developers out there on both the host and firmware side may involve more moving things actually forward and less fiddling just to get our software to speak with our hardware in the future. In this sense, let's talk :)