Resetting the printer while idle or during single motions (not while printing), using the hardware button/LCD.
The printer would reset, and OctoPrint would not issue any immediate commands.
Line numbers were not reset in OctoPrint, so the printer was requesting the incorrect data (ie.. OctoPrint was sending whatever it was previously at, eg. 59, but the printer had just been reset and hence was requesting line 1.) This occasionally meant that a sequence of incorrect commands were executed.
Version 1.3.0 (master branch)
Custom corexy. Repetier 1.0.0dev.
Terminal 1 - requesting line that is no longer in the buffer
Terminal 2 - requesting and executing non-current commands after reset!!
N/A - however testing different values for 'Max Consecutive Timeouts While Idle" had no effect..
I have read the FAQ.
Yes it all worked a lot better when immediate commands were sent without line numbers.
@nophead I added an option explicitly for you to disable line numbers altogether ;) But they are necessary for a lot of printers out there to work reliably.
@camnewnham I'll look into it. It should hopefully suffice to simply send a reset line number command when a start is encountered during regular operation, since that usually indicates that the controller was reset. If that doesn't proof as sufficient though, my hands are tied - any externally triggered actions on the printer that don't produce some kind of feedback on the serial are nothing I can react to.
@foosel, Thanks for that, but where is it? I can't find such an option in Version: 1.3.0 (master branch).
@nophead you need to disable firmware detection and then set "Send a checksum with the command" to "Never":
That should do it hopefully.
Got it, thanks very much.