Octoprint communication issues

Get answers & advice for all of your 3D printing & Free Software needs here!
kmanley57
Posts: 1111
Joined: Sun Feb 01, 2015 3:53 pm

Re: Octoprint communication issues

Post by kmanley57 » Wed Mar 07, 2018 3:43 pm

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.

ScottW
Posts: 452
Joined: Thu Dec 10, 2015 1:00 pm

Re: Octoprint communication issues

Post by ScottW » Wed Mar 07, 2018 3:51 pm

kmanley57 wrote:
Tue Mar 06, 2018 6:01 pm
Having an SD card plugged in with LOTS of files on it falls into this condition! AKA: It takes TOO LONG to list ALL the files..
kmanley57 wrote:
Wed Mar 07, 2018 3:43 pm
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.
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:1.1.5.44 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.

Post Reply