Bad WiFi stops print part sending
Closed this issue · 6 comments
Currently, when a print part is send successfully the printer state is checked, when it's printing or buffering it will send the next part. But when a part was send and then the connection to the WiFi-Box is lost (bad WiFi connection) (a request to /info/status fails) and the printer state is changed to wifibox disconnected it won't send the next part. See:
https://github.com/Doodle3D/doodle3d-client/blob/master/js/Printer.js#L195-L197
One solution I can think of (with a catch, see below) is to add an else at the indicated lines, where sendPrintPart() calls itself. We could then set an event handler (called from handleStatusUpdate()?) there so that whenever the printer state switches back to buffering/printing again, we can retrigger the sendPrintPart loop.
The catch is that we have to check that it is the same printer (still working on the same job); we know that it was the wifibox connection being lost (since the state is Printer.WIFIBOX_DISCONNECTED_STATE) but we still lost sight of the printer. If it has been disconnected in the meantime, or run out of code to print, we should reset the print.
A (non-foolproof) solution to this could be to check if the printer has the same amount of total lines set as kind of a fingerprint and if its buffer is still non-empty (i.e. it is still printing).
And a final thought: is it possible that the wifibox has received the last printpart but we did not receive the OK? In that case we should also be able to check which part the wifibox expects next (i.e. allow sequence numbers to be requested or passed along in a status message).
One solution I can think of (with a catch, see below) is to add an else at the indicated lines, where sendPrintPart() calls itself.
Won't that have the same result as removing the if statement completely? What if we add a else if check if it's disconnected and if so do a retry after a timeout? When it's not the same printer the next call will just give an out of sequence error.
We could then set an event handler (called from handleStatusUpdate()?) there so that whenever the printer state switches back to buffering/printing again, we can retrigger the sendPrintPart loop.
But tis depends on a very specific state change (disconnected > printing/buffering), that seems fragile?
What if we turn the check around, only send it when the state is not idle or 'connecting'?
And a final thought: is it possible that the wifibox has received the last printpart but we did not receive the OK? In that case we should also be able to check which part the wifibox expects next (i.e. allow sequence numbers to be requested or passed along in a status message).
Which part are you referring to here? Print3D not getting an ok from the printer?
Won't that have the same result as removing the if statement completely? What if we add a else if check if it's disconnected and if so do a retry after a timeout? When it's not the same printer the next call will just give an out of sequence error.
You're right, I meant an else-if. I think you're also right that just retrying is enough so we don't need any event handlers, so probably no need to turn the check around either?
And I didn't think of the sequence numbering, but that will indeed automatically make sure we are talking to the same printer running the same job. So it appears to be simpler than I thought, good!
Which part are you referring to here? Print3D not getting an ok from the printer?
I was referring to the AJAX response, so the request arrives at the wifibox intact, but the response gets lost underway.
Always nice when things are simple ;)
Which part are you referring to here? Print3D not getting an ok from the printer?
I was referring to the AJAX response, so the request arrives at the wifibox intact, but the response gets lost underway.
Ah, but we didn't see a timeout error (from the send printing parts requests), so probably not.
Implemented in 533968b (and supporting commits in other repos: Doodle3D/doodle3d-firmware@develop...feature/304-recover-bad-wifi and Doodle3D/print3d@develop...feature/304-recover-bad-wifi).
This is released with version 0.10.10.