BufferBuddy 0.3.0

Fixes from a full review of 0.2.0, tested on the Aquila. Still nothing to set up on a stock OctoPrint, and still requires a Marlin build with ADVANCED_OK.

Install

Plugin Manager → Get More → ...from URL:

https://github.com/kagebarton/BufferBuddy/archive/0.3.0.zip

Upgrading from 0.2.0 keeps your settings. The "Upload to SD Inflight Target" setting is gone, and a saved value is ignored.

What's new

Fixes

• The raised clear-to-send limit no longer outlives a print. In 0.2.0 it stayed raised between prints, so the oks for the last lines of one print banked credits, and the next print spent them by sending about 30 lines back to back while the printer was busy with its first long command, such as homing or heating, with no RX buffer check. Pausing did the same. The limit now goes back to OctoPrint's own value outside a print, and comes back up when the next one starts.
• The RX buffer check counts real bytes (each line's text, line number and checksum) instead of assuming 48 bytes per line. On a 128-byte buffer that allows 3 typical lines where 0.2.0 allowed 2. On a 1024-byte buffer, 0.2.0 could overflow it with long lines.
• Uploads to SD use the normal inflight target. The separate setting could be set higher than OctoPrint's resend history, so a resend during an upload could ask for a line OctoPrint no longer had.
• A settings field left blank no longer breaks the plugin (it used to log an error on every ok and do nothing). Any other error now logs once, hands the connection back to stock OctoPrint and says so in the sidebar.

Faster ramp-up

• No minimum interval between extra lines. Inflight now climbs one line per ok, instead of at most 10 lines a second, which took about 3 s at the start of a print and after every resend.

Sidebar

• "In flight" says what's holding it back: the RX buffer, the command buffer or the target.
• "Extra lines sent" is replaced by In flight average over the job, which is what the plugin achieves (stock OctoPrint keeps 1).
• Shows Paused. It no longer shows Ready after a print fails by disconnecting, or a misleading lines/s right after heating or a pause. The planner average is weighted by time.

Housekeeping

• Dead code and cookiecutter leftovers removed (about 280 lines).

Results

One printer, so treat these as indicative: Aquila (Marlin, 250000 baud), an 18,000-line × 0.3 mm circle at F6000 (54 s of motion, plus homing).

Firmware	Plugin off	0.2.0	0.3.0
RX 128 / BUFSIZE 8	238 s	125 s
RX 1024 / BUFSIZE 32	238 s	83 s	78 s
RX 1024 / BUFSIZE 32, plugin's RX setting at 128			77 s

The last row is the new finding. With the RX setting at Marlin's default of 128, the print was as fast as at 1024, because once the planner is full, Marlin's command queue holds nearly every line in flight. BUFSIZE is what matters, not the RX buffer as the 0.2.0 notes implied. Set "Printer RX buffer size" to your firmware's value either way.

Resends still happen at full streaming (2 to 6 episodes per 18,000 lines on the Aquila), and all recovered.

Known limitations

• OctoPrint treats a print as done when it sends the last line, so "print done" comes up to BUFSIZE - 1 lines early.
• oks for earlier lines arrive while the printer is busy with M190/M109, which can cause "Communication timeout" messages around heat-up.
• On a slow host (the Aquila's is an Android phone running octo4a), OctoPrint's serial.log can cost enough CPU to starve the planner at high line rates. Leave it off unless you're diagnosing something.

Full diff: 0.2.0...0.3.0