* Sponsors => Supporters
* Links to individual About dialog tabs from start page
* Slight rewording here and there
* rel="noopener noreferrer" for external links
When SD card support is disabled on the server, remove any client side
filtering to just SD files since there aren't any and there won't be UI
turn remove the filter either. Should address #1300
We don't want to wait indefinitely for our send and command queues to empty, so
we don't use .join but instead a busy timeout wait routine.
Also fixed a couple of small issues found while preparing comm unit tests.
Added parameter "wait" to "close" method, defaults to True. Will have the
close method wait for all lines to be sent that are currently in the send queue.
In case of an error, no waiting will be done.
Made it necessary to correctly track task completion in the send queue, also
made that change to the command queue while at it.
Backported from devel, commit 7f2476e513
"Error:" lines can also be produced by OctoPrint itself in case of serial exceptions or
connection failures, so "the firmware reported" was misleading.
That way no M105 cascades can be triggered by the M105 polling timer (or the M27
polling timer).
Adjusted logging output to make clear which queue rejected typed entry.
Made timeout handler send M105 with type "temperature" as well to make sure
we don't suddenly have two M105 directly after each other in the send_queue,
one from the polling timer, one from the timeout handler.
Fixes#1275
put and get are now overwritten to create t-tuple out of provided item
and item_type on put, and to only return item on get.
_put and _get extract item_type and use that for managing the
lookup set.
Running comm.py with parameters port, baudrate, local file, remote file will
upload local file to remote file on the printer's sd using the provided connection
parameters.
Example:
python -m octoprint.util.comm /dev/ttyUSB0 115200 /path/to/some.gcode test.gco
No plugin support! Only regular serial connection supported.
Had to reorder message processing a bit in order to be able to
properly handle further resends in timeout situations.
Has the added benefit that "ok" now gets processed very early
and now extra state based processing is needed anymore.
Should prevent slicing result to contain bed temperature settings even if
printer has a heated bed configured unless slicing profile also contains a
temperature.
Fixes#1268
Option to log last terminal lines before a resend (defaults to off for now),
more exception logging in octoprint.log in various error cases, also log
unsolvable resend requests with requested and current line number.
Also pushed more advanced config option into an initially hidden
"Advanced Options" section, similar to other places.
(cherry picked from commit 84b343a)
"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.
We suffer from the same problem as commands being suppressed in the
send queue here. If a non-GCODE-command we send to the printer
produces no output, our _monitor loop will wait until the next response
produced by another command. Which we won't send though since
we are stuck waiting in the _monitor loop waiting for a response. Hence
we need to manually trigger further command processing from the
send loop here in order to ensure things keep going.
Also make sure that if we have a pkg_resources version that returns
tuples we not only remove any intermediary version parts if the base
version is requested, but we also append "*final" to the tuple afterwards,
otherwise the compatibility check will fail.
That way people will not see connection failed messages while the server is
still starting up.
Served intermediary page als "pings" an image on the backend to detect if
a) the backend is still responding at all ("intermediary.gif") and b) whether the
server has fully started up ("online.gif").
If the backend stops responding for 5s, a message is output that tells the user
that something went really wrong and to please check the log file.
Once the server becomes online, the intermediary page reloads/switches to the
actual UI.
When autoscroll was disabled, terminal could run on endlessly, eating
memory until the browser crashes. Now a hard upper limit ensures
that not more than 3000 lines are ever stored in the terminal. If autoscroll
is disabled and the limit is reached, no more log lines will be added. That
ensures that the log will not scroll and the current log excerpt will stay put.
UI + assets should actually have ETag and LastModified headers and proper
IfMatch handling on the server side and hence the server should do the
right thing on its own.
That should improve performance tremendously.
Both ETag and LastModified depend on all files the template rendering
depends on. If any of the depended on files changes, both values will
change as well. That allows us to track whether our cached copy is
still current (and force a refresh if not) and also process IfMatch request
headers and reply with a 304 directly so that we do not even have to
transfer the data if nothing changed and the browser still has it.
Also now tracks timestamps of last access to a preemptively cached
resource and cleans up stuff that hasn't been accessed in a while (7 days
by default)
Introduced a @preemptively_cached decorator that for decorated views
persists the provided data in ~/.octoprint/data/preemptive_flask_cache.yaml
in a list indexed by the view's path if the data is not yet part of the list.
During initialization the server will iterate over the persisted paths and data
and for each persisted path and entry in the list initialize a temporary WSGI
environment based on the data (which is interpretated as keyword arguments
to werkzeug's EnvironmentBuilder) which will then be used to call the view
function in the correct context.
The current implementation for / and /i18n/<locale>/messages.js utilizes
that decorator to allow preemptive caching of those views (/ being probably
the most expensive one in the whole core application) utilizing request base URLs
(internal access, external access, reverse proxy with prefix url etc) that had been
encountered in the past.
Through the new config setting server.preemptiveCaching.exceptions it is
possible to define a set of base URLs to never cache. Preemptive caching can
be globally disabled by setting devel.cache.preemptive to false.
This way we create separate caches for URLs access via different schemes/prefixes/etc.
Otherwise our generated page might not work when accessing OctoPrint from external
after accessing it from internal once.
Otherwise the GCODE Viewer will get stuck "half way through" if
"sync with progress" is enabled but the tab/browser tab loses focus
during printing and only regains it after the print has finished.
This might help with #1065 if indeed is related to background tab suspending behaviours in
browsers, but is a completely blind guess at this point since I still have not been able to
reproduce that issue myself.
Backported.
(cherry picked from commit 720cdad)
