Set read timeout on serial port to a much shorter value (default 2.0s)
during a heatup. Firmware should usually send the current temperature
back every second, so if that stops we can consider the heatup to be finished
even if we don't see an ok.
That is important in cases such as SD printing, where we might see a
heatup sequence we didn't trigger ourselves, during which we shouldn't spam
the printer with commands it potentially can't process but after which we
still should take up normal communication again. In case of a heatup sequence
triggered by an SD print we won't see an ok and hence only can now through a
timeout that things are now done printer side. In such a case the user should not
get thrown a scary timeout message in their general direction either.
Solves #1409
So far the sending routine did not track the amount of bytes that were
actually sent. This is now fixed such that if the number of sent bytes
is less then the number of bytes of the whole message, the sending
rountine will continue to send the unsent parts of the message until
it succeeds (or a timeout occurs).
Also adjusted the virtual printer to imitate a real serial interface with
regards to having it return the written bytes and allowing a partial
sending (returning the number of bytes that actually were sent).
Added name and path various event print job events and
the upload event, deprecated the file property.
Had to move event triggering of the print job events to
the printer implementation, since the file manager
is not available in the comm layer. Added new callbacks
to the PrinterInterface to allow for that to be possible.
In some situations an error could be displayed otherwise since
online.gif was available, intermediary.gif wasn't anymore, but pinging
the latter timed out before the next ping of the former.
(cherry picked from commit 7809ba8)
Also user window.location.reload if URL to reload is the same as the current one,
otherwise reloading will be a no-op if a fragment is provided.
(cherry picked from commit a367902)
RepRapFirmware enumerates the gcode files starting at /gcode, it will
also interpret any relative path as being relative to that folder.
However a full absolute path will actually interpret as from the real
root of the SD card :-(
(cherry-picked from ac68570)