Using setready.g starts the next job, but leaves it at the top of the queue
Seemingly everytime I use the setready.g file to set the printer to ready from the printer itself, the job starts perfectly, but it's not removed from the queue. That is, it stays at the top of the queue in Prusa Connect, ready to be started as the next job in line (as well as being the current job). When using Prusa Connect to set the ready state, the started job is removed from the queue as expected. I would guess this is not the intended behaviour?
- PrusaLink type: Pi Zero
- PrusaLink version: 0.7.2 (and 0.7.0)
- Printer type: i3 MK3S+
- Printer UUID: e137edca-35b9-4c56-ad88-297c08226955
- Printer firmware: 3.13.1-6876
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Hmm, I just tried it again, and it might just be a graphical glitch in the print queue view. The duplicated job disappeared on page reload...
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Hi, okay, that might be it, becazse we tried it and weren't successful. I relay that to the team. Thanks
RE: Using setready.g starts the next job, but leaves it at the top of the queue
I've definitely had it happen twice now since then. Not just a visual bug, the job was still there in the queue after reloading the page.
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Welp, that sucks, if you can think of anything we could try to replicate this on our end, please let me know. As is, we cannot get it to happen making a fix unlikely to be made 🫤
Also please let me know whether you can start the print twice just by selecting set ready a second time. Thanks
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Welp, that sucks, if you can think of anything we could try to replicate this on our end, please let me know. As is, we cannot get it to happen making a fix unlikely to be made 🫤
As a developer myself, I know that feel... Will get back to you if I figure out a pattern in the issue. One thing I did notice the last time it happened was that the printer briefly said "No internet connectivity" just after starting (and then saying "Errors resolved" within less than a minute). I don't think I've seen that before, though, and I think this was after Prusa Connect noticed that the print had started. I should probably also mention that I'm using a basic Pi Zero (i.e. non-W) in my printer, with a USB hub with Ethernet connected to it (specifically, this thing).
Also please let me know whether you can start the print twice just by selecting set ready a second time. Thanks
Good point. I'll try to remember to try that next time I see it happen. So far I've just removed the extra job manually.
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Okay, that can do it. Thank you for that tidbit of info. You basically lose one message sent to connect while the print is starting. That definitely can cause weird stuff to start happening. But why do you lose just one? Hmm
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Any log files I should check?
RE: Using setready.g starts the next job, but leaves it at the top of the queue
Could be interesting to see the syslog, just please tell me approx the time it happened
RE: Using setready.g starts the next job, but leaves it at the top of the queue
I found interesting things in daemon.log. It seems like there were connectivity issues both times this happened today:
Oct 30 08:41:34 replicator prusa.link.printer_adapter.print_stats[472]: INFO: New file analyzed. It has inbuilt percent and time reporting. {info():195}
Oct 30 08:41:37 replicator prusa.link.printer_adapter.state_manager[472]: WARNING: State was State.PRINTING {warning():205}
Oct 30 08:41:39 replicator prusa.link.printer_adapter.state_manager[472]: WARNING: State was State.ATTENTION {warning():205}
Oct 30 08:41:45 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 08:41:55 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 08:42:06 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 08:42:06 replicator prusa.link.printer_adapter.lcd_printer[472]: WARNING: Displaying an error message No Internet access {warning():205}
/.../
Oct 30 13:01:00 replicator prusa.link.printer_adapter.print_stats[472]: INFO: New file analyzed. It has inbuilt percent and time reporting. {info():195}
Oct 30 13:01:10 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 13:01:20 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Interestingly, the second time (13:01) was the time I noticed the "No internet" message, but there's nothing about it in the log that time.
RE: Using setready.g starts the next job, but leaves it at the top of the queue
The error system could use a lot of work. The read timed out is causing an exception which is actually triggering this message. I want to improve this, but need to figure out a quick solution that is hopefully a little more true to what's happening. It's related to connect dropping the connection.