mariner: 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.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 1
- Comments: 25 (5 by maintainers)
I made some good progress on this bug today by making these changes:
\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.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
.debthat is attached to this CI run as an artifact: https://github.com/luizribeiro/mariner/actions/runs/894169954Right, 3c9185a34e243a343c6a51e857e681331cba7e80 did that 😃
Those look like solid steps, one thing though, you’ll probably want to add the retry logic to get_selected_file as well. As part of print_status I had the exceptions rising out of that as well.
So adding the flush helps quite a bit, but isn’t a 100% solution as expected.
This was with just leaving the web display up during prints, and not issuing additional commands. So no race conditions, etc.
It probably reduced the issue on my end by 50-70% though.
Okay, going to play with this issue a bit. Have added the basic buffer flush ( self._serial_port.read(size=1024) )to the mars serial send() function. I get this issue super frequently, so it should be easy enough to test how effective a flush is.