search

Doodle3D / doodle3d-client

The Doodle3D web interface that people can access on computers or tablets to draw doodles and control the Doodle3D WiFi box.
www.doodle3d.com
GNU General Public License v2.0
3 stars 8 forks source link

Bad WiFi stops print part sending #304

Closed peteruithoven closed 8 years ago

peteruithoven commented 8 years ago

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

woutgg commented 8 years ago

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).

peteruithoven commented 8 years ago

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?

woutgg commented 8 years ago

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.

peteruithoven commented 8 years ago

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.

woutgg commented 8 years ago

Implemented in https://github.com/Doodle3D/doodle3d-client/commit/533968bb049a1cb9b2aaeebb903c9d6e6017c05e (and supporting commits in other repos: https://github.com/Doodle3D/doodle3d-firmware/compare/develop...feature/304-recover-bad-wifi and https://github.com/Doodle3D/print3d/compare/develop...feature/304-recover-bad-wifi).

peteruithoven commented 8 years ago

This is released with version 0.10.10.