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.
If a new config setting is set, the virtual printer will now
resend the same resend request twice to allow testing the
comm layer behaviour in OctoPrint for being able to cope with
these possible repetitions like they can happen with Repetier.
Sending "!!DEBUG:action_custom foo 1 2 3" will result in the virtual printer sending "// action:foo 1 2 3" back. Sending "!!DEBUG:action_custom bar" will result in the virtual printer sending "// action:bar" back.
Any unknown commands should just be piped through and not use up an acknowledgement. This
new behaviour can be overridden via the new feature flag "unknownCommandsNeedAck", which will
restore the former behaviour causing even unknown commands to use up an "ok".
Also no line numbering or checksumming will happen. Shouldn't usually be of relevance for other
firmwares, but in case of any compatibility issues introduced by this also added a new feature
flag "sendChecksumWithNonGcode" that causes even unknown commands to be sent with a
checksum if necessary.
Repetier always first sends the ok and then any command output. In case of M105, that makes the response look like from an externally triggered heatup (no ok on the same line), causing polling to stop until that falsely detected heatup is complete. Added a configuration option to disable heatup detection. The disadvantage of this is that when printing via Repetier Firmware from SD, the heatup times won't be substractable from the total print time, leading to a less accurate print time left estimation.
Closes#835
* moved virtual printer into plugin
* made default serial factory use supplied parameters instead of directly utilizing self._port and similar
* documented new hook
2015-04-16 11:43:30 +02:00
Renamed from src/octoprint/util/virtual.py (Browse further)
