Get answers & advice for all of your 3D printing & Free Software needs here!
As much as it might amuse me to try explaining RX buffer size overrun to you it really is not worth it. The data was received just not kept.
I will express my CRAZY ideas at any time! So you have been warned. None of my opinions are Lulzbots and can be wrong at any second.
That might actually amuse everyone. But which is it, a timeout from a long running M20 command, or a buffer overrun? Make up your mind please.
I understand serial comms and buffering (in general, and specific to Octoprint) just fine, thank you. The kind of buffer overrun you describe does not match what is shown in those logs. Neither does Octoprint's long command timeout value. Even in the initial connection response, there are missing characters -- if there was a buffer overrun problem with the firmware and/or Octoprint there, it would be happening to everyone.
Look at this line, for example:
Recv: FIRMWARE_NAME:Marlin FIRMWARE_VERSION:188.8.131.52 EXTRUDER_TYPE:DualExtruder v3 SOURCE_CODE_URL:https://code.alephobjecN2 M21*1iffusion/MARLIN PROTOCOL_VERSION:1.0 MACHINE_TYPE:LulzBot TAZ 6
I agree that LOOKS like a buffer overrun at first glance -- there are certainly characters being lost -- but digging deeper it isn't a simple case of firmware sending too fast / too much for pyserial and Octoprint to process. Octoprint on an Rpi3 has no trouble keeping up with that output, and that output is common to everyone. Something else is causing the character loss -- bad cable or port, or interference perhaps.