Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect line numbers after reset #1676

Closed
camnewnham opened this issue Dec 29, 2016 · 7 comments

Comments

Projects
None yet
3 participants
@camnewnham
Copy link

commented Dec 29, 2016

What were you doing?

Resetting the printer while idle or during single motions (not while printing), using the hardware button/LCD.

What did you expect to happen?

The printer would reset, and OctoPrint would not issue any immediate commands.

What happened instead?

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.

Branch & Commit or Version of OctoPrint

Version 1.3.0 (master branch)

Printer model & used firmware incl. version

Custom corexy. Repetier 1.0.0dev.

Browser and Version of Browser, Operating System running Browser

N/A

Link to octoprint.log

log

Link to contents of terminal tab or serial.log

Terminal 1 - requesting line that is no longer in the buffer
Terminal 2 - requesting and executing non-current commands after reset!!

Link to contents of Javascript console in the browser

N/A

Screenshot(s) showing the problem:

N/A - however testing different values for 'Max Consecutive Timeouts While Idle" had no effect..

I have read the FAQ.

@nophead

This comment has been minimized.

Copy link
Contributor

commented Dec 29, 2016

Yes it all worked a lot better when immediate commands were sent without line numbers.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 9, 2017

@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.

@nophead

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2017

@foosel, Thanks for that, but where is it? I can't find such an option in Version: 1.3.0 (master branch).

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 9, 2017

@nophead you need to disable firmware detection and then set "Send a checksum with the command" to "Never":

image

That should do it hopefully.

@nophead

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2017

Got it, thanks very much.

foosel added a commit that referenced this issue Mar 9, 2017

Reset line numbers if printer sends "start" when operational
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
@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 9, 2017

OctoPrint will now reset line numbers via an M110 when it encounters a start (exact match) while already operational. This should help in cases like the above. Needs some more real world tests though.

Change is pushed to maintenance and soon the devel branch and will be part of the 1.3.2 release. Some report back if it indeed helps with the problem described in this ticket would be appreciated.

@foosel foosel added the status:solved label Mar 9, 2017

@foosel foosel added this to the 1.3.2 milestone Mar 9, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

1.3.2 was just released.

@foosel foosel closed this Mar 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.