If enabled (which it is by default), OctoPrint will now send
an M115 to the printer on initial connection in order to try
to figure out what kind of firmware it is. For FIRMWARE_NAME
values containing "repetier" (case insensitive), all Repetier-
specific flags will be set on the comm layer. For FIRMWARE_NAME
values containing "reprapfirmware", all RepRapFirmware-
specific flags will be set on the comm layer.
For now no other handling will be performed.
When setting the tracked target temperature from a sent temperature
command, the changes in tracked temperature were not propagated
from the comm layer to registered callbacks.
But since the standard printer also didn't make a copy of the mutable
dict of tool temperatures, those were in fact updated even without
propagation in the printer implementation when the values in the
comm layer got updated, whereas the bed temperature - an immutable
tupel - was not.
Two wrongs sometimes do in fact make a right. In this case that led
to target temperature changes on the tools immediately reflecting
in printer.get_current_temperatures after the command was sent,
but changes to the bed target taking until the next M105 response
to propagate.
Decoupling the data structures and adding propagation commands
to the comm layer solves this issue.
Fixes#1543
Probably solves the core reason that caused #1428 to be
reported in the first place, totally inaccurate early linear
approximations (when nothing better is available) making
it to the user.
It should now display "Calcuting..." until the approximation
stabilizes OR the configured max percentage or max time without
an estimate are reached.
Seriously though, this topic is driving me nuts...
* track origin of print time left estimate
* less draconian threshold for estimation helper for all prints, not just
sd prints
* sanity check estimated/statistical total print time, if not sane force "dumb"
estimate
* force "dumb" estimate if no other estimate is available after set percentage or
print time
Added name and path various event print job events and
the upload event, deprecated the file property.
Had to move event triggering of the print job events to
the printer implementation, since the file manager
is not available in the comm layer. Added new callbacks
to the PrinterInterface to allow for that to be possible.
RepRapFirmware enumerates the gcode files starting at /gcode, it will
also interpret any relative path as being relative to that folder.
However a full absolute path will actually interpret as from the real
root of the SD card :-(
(cherry-picked from ac68570)
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
