"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.
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!
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.
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.
Use new synchronized sending method and also make sure that heaters
will get disabled in case M112 is NOT understood by the firmware
before disconnecting. That's about all we can do for now.
(cherry picked from commit 5406b2b)
Closing the printer connection and then reopening (when the users clicks
connect) will create a new fresh MachineCom object so the queues will
start out empty. Plus ClearableQueue was even more tied to the Queue
implementation that the current _get/_put overrides.
(cherry picked from commit e7584cd)
That's where all other protocol specific settings are currently located.
Will be migrated at a later date into the printer profile instead (that
makes way more sense).
(cherry picked from commit d0f61e5)
Repetier might resend the same resend request to make sure it arrives.
This commit makes OctoPrint not react to such a repeated request and
instead ignore up to a configurable amount of repeated requests for
the same (current) line.
(cherry picked from commit 6f83695)
T-only lines were not properly parsed. Should now be fixed to
be associated to currently selected extruder. Also added unit
tests for the temperature parsing.
While at it also extracted regexes and added unit tests for command
parsing (gcode & parameters)
(cherry picked from commit f6a259f)
Readline could still be stuck in a read loop, leading to an exception on Mac
when closing the connection from another thread. This should now be captured
correctly.
Fixes#1021
(cherry picked from commit c829b27)
Readline could still be stuck in a read loop, leading to an exception on Mac
when closing the connection from another thread. This should now be captured
correctly.
Fixes#1021
(cherry picked from commit c829b27)
If the SD card fails to initialize with a volume.init failure, that's
not a reason to break off all diplomatic relations with the printer.
(cherry picked from commit 9caf13d)
Custom exception should be derived from Exception, not BaseException.
Not only is this specified in the python documentation, but also
tornado will be able to handle Exceptions in requests perfectly fine
and return an HTTP 500 for them, but crash hard (as in, server shut
down follows) for BaseExceptions.
(cherry picked from commit 29b047b)
This should allow users to adjust the behaviour of the communication stack more granularly in case the regular settings which only consider G4, G28, G29, G30, G32 to be real long runners without output are not sufficient.
Added phase specific hooks for queuing, queued, sending and sent phases of a command ("octoprint.comm.protocol.gcode.<phase>"). Removed old queuing phase hook and declared as obsolete hook in plugin manager to prevent plugins that depend on it from being enabled.
Adding those new hooks also necessitated refactoring the whole command processing, made it more modular and added phase specific handler functions that allow handling all blocking commands centrally for example.
