Skip to content

Releases: kagebarton/BufferBuddy

BufferBuddy 0.3.2

Choose a tag to compare

@kagebarton kagebarton released this 17 Oct 17:59

Fixes for the sidebar after a reconnect, and corrected advice on the firmware's RX buffer size. Still nothing to set up, and still requires a Marlin build with ADVANCED_OK.

Install

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

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

Upgrading from 0.3.x keeps your settings.

Fixes

  • After a reconnect the sidebar could stay on its inactive text. BufferBuddy now checks compatibility before it reads the buffer sizes from ok N0, and redraws the status when it changes.
  • An error while reading the buffer sizes could be cleared by the next line. It now stays.
  • A settings save, pause or page load could bring back an old lines/s figure. The stats now carry their age, and during a print the sidebar shows 0 lines/s for stats more than 3 s old.
  • The "Printer RX buffer size" setting is now saved with the settings page's minimum of 48 bytes. Below a line's worth, every extra line was held back with nothing to show why.
  • The sidebar no longer blames the RX buffer for lines the inflight target holds back.

Firmware advice

The README said a small RX_BUFFER_SIZE costs little. That was wrong: the RX buffer has to hold every line in flight. When Marlin's main loop stops reading serial while its command queue is empty, every line in flight lands in the RX buffer at once, and whatever doesn't fit is dropped and resent. Allow about 64 bytes per line: 2048 for BUFSIZE 32, 512 for BUFSIZE 8.

The octo4a fix for swapped lines (two pty reader threads) is now released as octo4a 2.1.0-webrtc.2.

Tested

Aquila (Marlin, RX_BUFFER_SIZE 2048, BUFSIZE 32, 250000 baud), OctoPrint 1.11.8 on octo4a 2.1.0-webrtc.2: a 56-minute print of 214,767 lines with 8 bad lines, each recovered with a single resend, and no swapped or wrong lines. The same print had 14 to 15 bad lines with a 1024-byte RX buffer.

BufferBuddy 0.3.1

Choose a tag to compare

@kagebarton kagebarton released this 16 Oct 17:06

A fix for a resend case in which the printer could run the wrong move. Still nothing to set up, and still requires a Marlin build with ADVANCED_OK.

Install

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

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

Upgrading from 0.3.0 keeps your settings.

Fix

With about 30 lines in flight, one bad line makes the printer reject the lines already sent behind it, and some firmware asks for a resend for each of them. If one of those requests names the line OctoPrint is about to send, OctoPrint (1.11.8 at least) answers it by sending the oldest line in its history under that line number, with a valid checksum, so the printer accepts it and runs the wrong move.

During a resend, BufferBuddy now hides a resend request for the line OctoPrint sends next. The printer already has every line before it, so the request is stale. It shows in the terminal as echo:BufferBuddy ignored a stale request: Resend: N, and in octoprint.log.

Tested

Aquila (Marlin, RX_BUFFER_SIZE 1024, BUFSIZE 32, 250000 baud), OctoPrint 1.11.8 on octo4a: a 56-minute print with 17 bad lines, each recovered with a single resend, and no wrong lines. On that firmware the guard never had to fire. It covers firmware that answers in-flight lines with their own resend requests, as stock Marlin does.

BufferBuddy 0.3.0

Choose a tag to compare

@kagebarton kagebarton released this 04 Oct 23:33

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

BufferBuddy 0.2.0

Choose a tag to compare

@kagebarton kagebarton released this 03 Oct 17:03

BufferBuddy now works on a stock OctoPrint with nothing to set up: no comm.py patch and no "ok buffer size" change. Requires a Marlin build with ADVANCED_OK.

Install

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

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

What's new

Zero-config

  • Raises the connection's clear-to-send limit at runtime (to the inflight target + 2) and restores it when the plugin is disabled. Your saved setting is never touched. At the old limit of 2, every ok that arrived while OctoPrint's send loop was behind was thrown away, and each one permanently dropped a line out of flight.
  • Queues a line for every pending clear to send. OctoPrint only refills an empty send queue, so several oks arriving together used to send one line.
  • During a resend it stops adding lines but never swallows an ok. Swallowed oks could hang a print on Marlin.
  • New Printer RX buffer size setting (default 128 bytes). An extra line is only sent if everything the printer hasn't queued yet fits in its serial RX buffer. Set it to your firmware's RX_BUFFER_SIZE.
  • Checks the OctoPrint internals it relies on at every connection. If any are missing it shows "Unsupported OctoPrint version" and stays inactive.

Sidebar

  • Shows status, throughput (lines/s), in flight, planner fill now and averaged over the print, resends, and extra lines sent. Totals stay after a print and survive a page reload.
  • The two underrun counters are gone. They measured when Marlin sends its ok, not starvation, so they fired on nearly every line.
  • Stats also count during an SD upload.

Housekeeping

  • API is protected and templates are autoescaped, which clears OctoPrint's two deprecation warnings.
  • Update checks point at this fork.

Results

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

Firmware Plugin off Plugin on
RX 128 / BUFSIZE 8 238 s 125 s
RX 1024 / BUFSIZE 32 238 s 83 s

Resends still happen at full streaming (about 12 per 18,000 lines on the Aquila). Each was a single byte dropped by the firmware, and all recovered.

Full diff against fflosi's 0.1.1: 0.1.1...0.2.0