Unexpected Printer Response while printing from web interface

Hello!

I have mariner3d_0.1.1-1_armhf.deb running on a fresh Pi Zero (2020-12-02-raspios-buster-armhf-lite.img) and so far everything seems to be running fine.

However, when I try to print from the web interface I get an Unexpected Printer Response:

The printer returned an unexpected response: ‘ok N:0\r\n’

Traceback (most recent call last):
  File "/opt/venvs/mariner3d/lib/python3.7/site-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/opt/venvs/mariner3d/lib/python3.7/site-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/opt/venvs/mariner3d/lib/python3.7/site-packages/mariner/server/api.py", line 45, in print_status
    selected_file = elegoo_mars.get_selected_file()
  File "/opt/venvs/mariner3d/lib/python3.7/site-packages/mariner/mars.py", line 102, in get_selected_file
    self._extract_response_with_regex("ok '([^']+)'\r\n", data).group(1)
  File "/opt/venvs/mariner3d/lib/python3.7/site-packages/mariner/mars.py", line 39, in _extract_response_with_regex
    raise UnexpectedPrinterResponse(data)
mariner.exceptions.UnexpectedPrinterResponse: ok N:0

I don’t know what other printer responses there might be, but it might be a fix to change the regular expression to:

ok '?([^']+)'?\r\n

to make the single quotes in the response optional.

The printer:

• Mars 2 Pro
• EL3D-3.0.2
• V4.3.13_LCDC /1620x2560 /F2.23

Edit: I’ve used minicom to debug it further and amongst a lot of simple “ok” responses there a some responses like

ok ‘/lenkrad-v1.ctb’

and

ok ‘lenkrad-v1.ctb’

where lenkrad-v1.ctb is the only uploaded file right now.

[luizribeiro]

I made some good progress on this bug today by making these changes:

1. Adding retries (5b5c5b2046175f8aa5a9feb7981a8d8bc5ec0cba). Fetching print status is idempotent so it’s fine for us to execute it a few times until it works.
2. Adding a delay between retries (2455d9f19fa9ef81b6ceb2249ca2165323a6ec87). This helps a bunch because the printer doesn’t seem to handle multiple commands close to each other in a row for whatever reason. We might also want to try making the delay between retries use an exponential backoff, but I didn’t try that.
3. Ending commands with \r\n (599f4b06a5a988cfb2b27be51bf947a88a224508). I was a bit surprised this worked at all without ending the commands with a new line. Turns out the printer probably waits a bit for a few milliseconds when there’s no new line on the end of the command. If the input looks like a command, it runs it. Otherwise, it just errors out. This helped a bunch too.
4. Flushing input/output buffers (f9847d323e6123d069730258775041e88e019b9a).

Overall after these changes I can only reproduce this bug if I refresh the page multiple times quickly. This makes sense though: we’re probably processing multiple requests at the same time and spamming the printer with commands and running into race conditions. But at that point, #75 becomes more important than any more tweaks to this.

If you would like to try a build with these fixes, download the .deb that is attached to this CI run as an artifact: https://github.com/luizribeiro/mariner/actions/runs/894169954

[luizribeiro]

Right, 3c9185a34e243a343c6a51e857e681331cba7e80 did that 😃