Skip old line numbers on boot #1046
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Small option in case our serial reboots quite fast and our host might accidentally send a linenumber from the previous instance. (or if we somehow still have something in RAM)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a small problem where on reboots we'd try to ask-for-resend to linenum 1 when given a linenum from the previous connection.
Without this, firmware would replay a few previous (maybe dangerous) commands.
I also caught a very small bug in Repetier-Server:
The server seems to be sending a M105 right on connection start using an old linenum.
Mesg:12:51:05.071: Connection closed by os.
Mesg:12:51:06.072: Dtr: true Rts: true
Mesg:12:51:06.073: Connection started
Mesg:12:51:06.073: Dtr: true Rts: true
Send:12:51:06.083: N18 M105 <--- bad M105 sent when connected using old linenum
Recv:12:51:06.198: skip 18 <--- Now only skipping using this fix.
Recv:12:51:06.198: Response while unconnected:ok
Recv:12:51:06.203: ok
Send:12:51:06.203: N0 M110 N0 <--- Server sends my good first <connectionCommands> and resets linenum
Here's a reboot during printing and what would happen before this fix:
Recv:13:05:43.570: Error:expected line 1 got 388
Recv:13:05:43.570: Resend:1
Mesg:13:05:43.570: Resend after 7436ms
Recv:13:05:43.581: skip 389
Recv:13:05:43.582: skip 390
Recv:13:05:43.582: skip 391
Recv:13:05:43.582: skip 392
Send:13:05:43.582: N1 N1 M110
Send:13:05:43.582: N2 G0 X43.279 Y55.164
Send:13:05:43.582: N3 G0 X24.476 Y36.36
continues to replay G1's, etc...
I've left the fix as a #if macro; REJECT_PREV_LINENUM_ON_BOOT, because I think this might break something by rejecting the line numbers in some cases. I also don't know what effects it has with octoprint atm.
I haven't been able to use the server's rescue system before this, actually. The resends would happen before the rescue commands.
Edit: I forgot to mention; in some testing I've found it to be related to some more USB related anomaly when power flicks and we reset quickly. This has been difficult to debug and catch. That is why I left a onetime serial flush when rejecting the linenums too.