Is there a description of the serial protocol that octoprint expects from the printer? For example, when is a "busy" response appropriate? How often should it be repeated? When is "wait" needed instead and what's the difference? What are the expected temperature reporting formats? I see many commands sent that my printer doesn't recognize; is there a list of what's expected to work?
1 Like
I usually just review the code itself if I have a question like this but I do like the question. The forum has many responses from @foosel which talk about specific instances where a printer is misbehaving. It would be good to have the description as you've described.
This is the closest to a spec we have. Since it's a wiki everyone can edit which is a bad idea for a spec, and it's not well defined. But since my past attempts in nailing this down in a slightly more permanent and well defined form were met with hostility it's what we have to make do with.
"met with hostility? You're the king around here, Gina. You get to ignore hostility and rule by fiat, if you want.
Non carborundum illegitimi
The reprap G-Codes wiki is indeed a hodge-podge and more a post-hoc documentation of reality rather than a spec. But I was hoping to see something that reflected Octoprint's interpretation of that, and maybe the subset of commands it uses. I was surprised to see M18 emitted the other day, for instance. Didn't it used to use M84? I can't remember now. I see there's a M84-plugin, but it offers no further details.
I've tried to do the right thing with the "busy protocol", but I got some weird lag from Octoprint afterwards, so maybe I did something wrong. Anyway, the g-code page says "Busy" means "machine is busy for some reason and currently cannot receive or process commands through the serial interface". That's not true in my case, and I don't think it's what Octoprint thinks. I can receive commands and I might act on them if they don't involve movements. Indeed, when I start "waiting for temp" and sending Busy responses, Octoprint still lets me change the target temperature (and my printer does accept the new temperature).
I appreciate that you have to deal with various different firmwares (and many different versions of each, and bugs that crop up in them). I know it's a big task. I'd like to help by making my firmware Octoprint-compatible. That's hard to do when Octoprint's protocol is also a moving target and documented only in the implementation.
What would be brilliant is to write a plugin which measures the usability of a particular firmware, as attached. Presumably, it would walk through a set array of GCODE command sequences and then analyze the responses back and then apply a metric. Add them all together and this would be a grade (out of 100% expected compatibility).
If foosel thought a particular deviance-from-the-norm was bad, this particular criteria could be weighted harshly against the offending manufacturer's firmware version & implementation. And then, youtubers could run this plugin against their collection of printers and let everyone know that a printer design only meets 60%, say, of the expected firmware tests.
It isn't OctoPrint's protocol, and the target is only ever moving in a backwards compatible manner since I also have to sort firmwares from five years ago that never get updated anymore 
That being said, I've been meaning to get around to document the protocol messages that OctoPrint supports (and how it supports them), but you can probably imagine what priority I have to give stuff like that with everything else going on 
About the busy protocol, I wrote that section on the wiki (unless it has been edited since). OctoPrint will in fact stop processing the send queue (I think, can't check right now) when the printer signals being busy. But that behavior can be overridden either by the firmware reporting lack of support of the protocol, or by the protocol configuration in OctoPrint.