Might have been an external reset of the printer we didn't otherwise
detect, and unless we reset the line numbers we'll now be off and run
into resend requests.
Solves #1676
* leading and trailing null bytes will now be stripped
* while connecting, a "wait" will also trigger switch to connected
state - relevant when connecting without reset and initial "ok" for
M110 gets mangled
* extended virtual printer by new options to test the above:
* mangled "ok" can now be injected via "preparedOks" setting and
prepare_ok DEBUG command
* simulated reset lines on beginning ("start" etc) now only sent
if new setting "simulateReset" is true
Should fix#1770
Support multi-extruder setups that share a single nozzle and heater,
like the E3D Cyclops, Diamon hotend or probably the upcoming Prusa Mk2
multi-extruder upgrade.
The Control tab will still allow tool switching and extruding for
the configured extruders, the Temperature tab will only display
one hotend temperature though.
Printer profiles have been extended by a new option
extruder.sharedNozzle that defaults to False. Extruder offsets are
not displayed in the profile editor if that setting is checked and
reset to (0,0).
Long lines (longer than rx buffer) could not be processed at all, leading
to a serial timeout exception thrown by the virtual printer. Adjusted
to allow for partial processing like on maintenance
Set read timeout on serial port to a much shorter value (default 2.0s)
during a heatup. Firmware should usually send the current temperature
back every second, so if that stops we can consider the heatup to be finished
even if we don't see an ok.
That is important in cases such as SD printing, where we might see a
heatup sequence we didn't trigger ourselves, during which we shouldn't spam
the printer with commands it potentially can't process but after which we
still should take up normal communication again. In case of a heatup sequence
triggered by an SD print we won't see an ok and hence only can now through a
timeout that things are now done printer side. In such a case the user should not
get thrown a scary timeout message in their general direction either.
Solves #1409
So far the sending routine did not track the amount of bytes that were
actually sent. This is now fixed such that if the number of sent bytes
is less then the number of bytes of the whole message, the sending
rountine will continue to send the unsent parts of the message until
it succeeds (or a timeout occurs).
Also adjusted the virtual printer to imitate a real serial interface with
regards to having it return the written bytes and allowing a partial
sending (returning the number of bytes that actually were sent).
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.
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.
