Instead of disabling capturing of postroll by default (which we actually
don't want and doing so was a mistake thanks to misremembering the
meaning of the variable in question), we now properly reset the
default value for that check box (which wasn't properly set only due to
a very stupid typo).
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
