chendo/bufferbuddy

An Octoprint plugin that aims to improve print quality when printing over USB by ensuring the buffers stay filled.

bufferbuddy's Issues

Stops timelapses to early

Hello,

after a few days of tracing code in octoprint..... While running bufferbuddy octoprint finishes the print to early.

Depending on the buffersize config this will be more or less obvious, but mine are large enough that i have around 100 moves 'left' when the final m400 is send by octoprint.

because octoprint doesn't wait for all the buffers to drain on this point the printer is happily printing the finals lines while octoprint thinks the printer is finished.

tested this theory by adding 100 times M400 add the end of the file to make sure the buffer is completely filled with NO-OP's and then the timelapse is just fine.

i don't expect that this plugin can fix this, but it might be usefull to document it as knows issue with workaround

Missing from Octoprint plugin repo

As title states

works great otherwise, thank you

BufferBuddy sending multiple commands at a time with out receiving an OK causing the target to fall way behind, causing printer lockups or the host to initiates an Estop

Discussed here on the marlin Repo MarlinFirmware/Marlin#21119

We deduced that commands are doubling up causing the printer to far behind the host, eventually the host (octoprint) starts simulating OK messages, and as it rapidly fast further behind the host (Octoprint) will either initiate an emergency stop, or the printer will lock up leaving the heaters on.

Not sure if you're still working on this plugin but on large prints it causes them to fails because of the above as the target starts to fall way behind. Which is actually the reverse effect of what the plugin is trying to achieve.

BufferBuddy breaks RepRap protocol and Marlin

The protocol says that the next line should be only sent when the host receive 'ok' from the board:
https://reprap.org/wiki/G-code#Replies_from_the_RepRap_machine_to_the_host_computer

This plugin send more than one command at time. It generate unpredictable behaviour on Marlin.

Sum this plugin with the octo "simulated ok", and things will get really unpredictable. "Firmware didn't send an 'ok' with their resend request. That's a known bug with some firmware variants out there. Simulating an ok to continue..."

It would be a good addition to marlin, to support more than one command at time. But it's not the case of the current code.

Thanks for the project - want to contribute / beta test

Thank you for doing this. I saw your post in the Cura git issues thread. I will be using the plugin and reporting back any issues I find. My configuration:

printer: Sovol SV01 / Creality v2.2.1 silent board 32 bit
marlin: CopterTec 1.6.4 RC1 (https://github.com/CopterTec/Marlin-Sovol_SV01/releases) over Marlin 2.0.5.3
octoprint: 1.4.2 on Python 3.6.9 on Ubuntu 18.04.5 running on an Intel Computestick

Was using Cura 4.6.1 - upgraded to 4.7.1 and abandoned it for IdeaMaker 4.0.0 due to the quality issues. I have Cura 4.8.0 beta loaded and am starting more tests after I get some customer projects completed.

Best regards,

Mark

Status: Ready (disabled) even though plugin shows enabled

Installed BufferBuddy 0.1.0 and rebooted Octoprint

BufferBuddy shows Ready (disabled) but plugin shows enabled.

BufferBuddy is not showing any stats

Octoprint 1.4.2 / Python 3.6.9 / Ubuntu 18.04.5