"Hello" command sent to printer to trigger initial handshake can now be
configured. Commands that _always_ necessitate to be sent with checksum/
line number (e.g. M110 on Marlin) can be configured as such too.
Also fixed an issue causing the "Hello" command to not be actually enqueued
first thing on opening a connection. Seems to not have caused harm in the
wild, but was unintentional.
(cherry picked from commit 5c2ae37)
Improved connecting for some printers, destroyed it
completely for others, so this needs some more work/
thought before it's ready for prime time.
This reverts commit c82ec3d3af.
M110 is now sent every second until either a connection is established or the connection
attempt times out. That should prevent connection handshakes from failing due to
some initial garbage on the line that swallows an ok.
We currently do not have a storage configured for SD card since
that hasn't yet been ported to the storage interface. So on an
SD card fail we need to capture that error when attempting to log
the print recovery data, or there will be issues processing
the cancel properly. A bit more of error handling is a good
idea here in any case too.
Fixes#1226
In case of trying to switch to state printing with no selected file that
scenario is now caught by setting an internal manualStreaming flag.
That will stop the M105 polling until M29 is sent (through whatever
means).
Note that printing is not disabled... this is merely for testing stuff and
not encouraged to be used for actually streaming files to the printer,
use the built-in functionality for that!
This reverts commit 1e429606e1.
Commit used functionality that currently is only available in
Chrome and maybe Opera. No alternative solution could be found
that works reliably across browsers.
* persistent notification on ongoing timelapse render job (#485)
* non-colliding timelapse snapshot name generation to not delete
existing snapshots when new print starts and timelapse has not
yet been rendered, also only delete snapshots if timelapse rendered (#318)
* list of unrendered timelapses, with option to delete files
or to render timelapse
Use this carefully. An error reported by your firmware usually hints
at something being off about your printer (e.g. thermistor troubles)
or the firmware not being fully compatible to OctoPrint since
it doesn't recognize a lot of commands.
If you print with this option enabled, it will still fail if you firmware goes
into lockdown, but now it will keep trying to send data to your printer.
That might cause issues. So best not use that option, only if you absolutely
have no other way to get some misbehaving printer to work with
OctoPrint.
The client now tries to detect if it's fast enough to process the
state updates usually send every 500ms, and if not notifies the
server to throttle the rate (e.g. to 1/1s, 1/1.5s etc).
Additionally, since the terminal tab of the client turned out to
be quite CPU intense when line number calculation, filtering etc
is enabled, the terminal tab now also falls back into a bit less
fancy mode if it detects its being processed too slow and optionally
even disables logging completely during printing (where a lot
of log messages need to be processed in a minimum amount of
time).
That way the UI should stay responsive even on very low powered
clients (e.g. chromium on a Pi), while printing.
