By default G90/G91 define relativeMode, M82/M83 define relativeE. The
extruder coordinate will be viewed as relative when either
relativeMode or relativeE are set. This mirrors the implementation in
Marlin (current and legacy forks) as well as Repetier.
SmoothieWare's implementation resets the relative mode of the
extruder on a G90/G91. To still accomodate this different
implementation a new settings has been added under Settings >
Feature: "G90/G91 overrides relative extruder mode". Checking this
switches to the alternative interpretation for future gcode analysis
and visualization.
The only difference between the two of them is that the following
segment of GCODE:
M83
G90
will have the extruder still set to relative on Marlin and
Repetier but set to absolute on Smoothieware.
Please note that the setting in all likelihood will be moved to
the printer profile in the future, since it makes more sense to have
it on a per printer basis. It's not part of the set of features
available for auto detection since it's required for GCODE analysis
and hence needs to be known even outside of a connection to the
printer.
Implements #1818
An aspect ratio of 16:9 is assumed, with other ratios showing black
letterbox borders as required.
During loading a text "Webcam loading..." is displayed in the webcam
space. On loading error, the (broken) image is hidden and an error
text is displayed instead.
Solves #478
Otherwise we might run into a rare race condition where the M110 sent
on start of a SD card upload gets prepared for sending after the
source file is already opened. That would then lead to the M110 not
getting processed anymore by OctoPrint and hence the line number
counter not resetting accordingly, leading to one line number
mismatch after the next from the firmware.
Testing if our "isPrinting" flag is ALSO set to true here ensures
that we'll only stop processing commands internally once the state
has actually switched to printing, which only happens after the
firmware responds to the M28 sent after the M110.
Fixes#1882 and probably also the issue encountered by @amd989 in
#1762 (which looks like exactly the same problem)
Disable button when a test is already active. Also have spinner
defined centrally and only made visible on active test.
Should hopefully give better feedback to impatient users ;)
Solves #1897
* Use click data-bind for submit button instead of manual click
binding
* Keep metadata synchronized (otherwise changing identifier, name,
description, overwrite or default flag after adding a file does
absolutely nothing)
* Disable submit button and fields when no file is selected.
* Disable submit button (and show spinned) when request is in
progress.
Related to #1893
This fixes#1893.
Also, only bind click to the "Confirm" button once instead of binding
and unbinding it for each file. Binding it just once seems cleaner.
(cherry picked from commit 83d1921)
If double the speed needed for output during print/fancy terminal
functionality is detected, re-enable that after a timeout of 5s.
Decrease of speed cancels the timeout again. That should prevent wild
toggling.
Should solve #1862
Some users get confused by having to use the blue "Print" button in
the state panel for consecutive prints of the same model, let's solve
this once and for all.
Move the AutoScroll function to an animation frame to prevent layout thrashing and to keep it in sync with fastForEach
Remove the <br> tag from the terminal and use display: block; on span tags to prevent increasing DOM nodes and faster processing of the terminal
On call of the lazyload plugin, all matched img elements will be
checked if they have a data-src attribute. If so, their src attribute
will be replaced with the contents of the data-src attribute
(effectively loading the image) and the data-src attribute will be
removed (so that multiple calls don't call multiple processing).
* Don't restrict the list of compatibility values to check against
to only those we have mapped, also support unmapped more exotic
ones.
* Allow 1:1 check against sys.platform values (with startswith).
Combined with the above that allows very granular compatibility
modelling ("freebsd11", "freebsd12") if required.
* Instead of only whitelisting ("linux", "freebsd") now also black
listing is possible ("!windows").
A detected os must match all provided whitelist elements (if the
whitelist is empty that is considered always the case) and none of
the backlist elements (if the blacklist is empty that is also
considered always the case).
See the included unit tests for examples of how this works.
Apparently python setup.py develop tries to re-install all scripts
provided by plugins (maybe only under Windows?). Since that includes
OctoPrint's own executable, things will explode with an access denied
error there. Switching over to pip install -e . fixes that, and also
is more conform with the install approach the plugin will take in
production anyhow.
So far using the "... from URL" or "... from an uploaded archive"
mechanism for installing a plugin would fail without further
information if the plugin to be installed was already installed.
The plugin manager will now detect this situation by parsing the
corresponding message from the pip output and trigger a reinstall
instantly.
A message about this will be logged to octoprint.log and the install
output.
Additionally the error handling for installation errors has been
slightly improved (install output no longer says "Done!" but "Error!"
with the reason as provided by the server) and the "could not install
plugin from URL unknown" issue should also be solved.
