Hi, I just got an Tronxy X5SA-400 2019 Printer (with color touch screen and not open source firmware) and it seems it does not implement buffering as defined in: https://reprap.org/wiki/G-code#Buffering
Instead, it will wait to send the OK until it has actually executed the command. The result is, of course, stuttering and horrible print quality when printing from OctoPrint (similar to Ouch! SD card vs Octoprint - what a difference. Help? ).
The Tronxy printer however does buffer commands if they are sent without waiting for the corresponding OK. The OK is issued once the command has been processed (move has finished!). It will send a "busy" when it's internal buffer is full. I have tested this.
Can we add an advance option for a OctoPrint based pre-buffer such that, if activated, a number of commands will be sent even if no OK is received until either a maximum pre-buffer command count is reached or the printer sends "busy"? I think it would help a lot of people whose printers do buffering the other way around.
There is a more or less agreed upon protocol in place. And it's so vague that firmware is already over the place with regards to interpretation and causing me a TON of overhead keeping things compatible and running for the tens of thousands of users out there. If a printer doesn't comply by even that vague protocol it simply isn't compatible to OctoPrint.
Maybe someone could write a plugin to implement this broken behaviour. But I won't add yet another switch for broken firmware.
Thank you for the quick and clear response. I can see what you mean.
True, this printer (and manufacturer) is not listed as compatible and apparently won't ever be.
But I have come to really like OctoPrint and this printer so I would like to make it work....
My plan now is to create a virtual com port pair and have OctoPrint connect to one end and then on the other I want to make a dotnet core C# program (don't know python) to act as buffering proxy translator. That way I can emulate the reprap buffering and maybe also make the SD card work.
I also find it sad that there is no good and clear specification. For example, the expected return values for codes is not defined anywhere? I was looking at M28/M29 as it is not working and it seems OctoPrint is looking for some specific string instead of the "OK" that the Tronxy printer sends.
To be honest "OK" sounds more standard to me than "File opened"... considering neither is defined anywhere?
Welcome to my personal hell. I've worked out what I needed to make OctoPrint work by reading source code of firmware when I could get my hands on it (Marlin, Repetier, Smoothieware, ...) and asking users for serial.logs where I couldn't. The situation is an utter mess. I also tried changing that by starting a standardization effort a couple years ago but got personally attacked for it, so that was that.
ok simply means "I've processed the command, send the next one". It says nothing about the result of the command. That is actually even defined on reprap.org/wiki/G-Code, as are a couple of other ground rules:
But yeah, the bulk of the commands is only defined on request side, nothing on responses, that's up for host software developers to figure out on their own. Yay.