You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Communication timeouts during resends trigger the M105 "revival mechanism", without honoring the resend's line number and instead using the current line number in the comm layer (which is too high). This leads to more "Resend" cascades and jumbling of line numbers.
How to reproduce
Have a file with extremely long moves so that the firmware's planner buffer fills to the brim and comm timeouts occur (wrongly...)
Provoke resend request in such a slow part of the file (e.g. via the virtual printer)
Observed behaviour
Send: N62 G1 X-70.472 Y-63.632 Z0.25 F535.8 E2.6067*71
Recv: ok T:255.2 /255.0 B:148.0 /148.0 T0:255.2 /255.0 @:7.29 B@:147.82
// ok for N59
Send: N63 G1 X-63.632 Y-70.472 Z0.25 F535.8 E0.1527*66
Recv: ok
// ok for N60
Send: N64 G1 X-61.753 Y-68.689 Z0.25 F535.8 E0.0409*66
Recv: ok
// ok for N61
Send: N65 G1 E-1.25 F1800.0*58
Recv: ok
// ok for N62
Send: N66 M103*17
Recv: Error:checksum mismatch, Last Line: 62
Recv: Resend: 63
Send: N63 G1 X-63.632 Y-70.472 Z0.25 F535.8 E0.1527*66
Recv: ok
// ok belonging to Resend
Recv: ok
// ok for N63
Send: N64 G1 X-61.753 Y-68.689 Z0.25 F535.8 E0.0409*66
Recv: ok
Send: N65 G1 E-1.25 F1800.0*58
Communication timeout during printing, forcing a line
Send: N67 M105*22
// wrong line number
Expected behaviour / Solution
Tricky to answer, but probably resending the same line that ran into a timeout makes more sense than trying to keep track of correct line numbers if M105 are sent in between active resend requests with increasing numbers.
So this should be the goal:
Send: N62 G1 X-70.472 Y-63.632 Z0.25 F535.8 E2.6067*71
Recv: ok T:255.2 /255.0 B:148.0 /148.0 T0:255.2 /255.0 @:7.29 B@:147.82
// ok for N59
Send: N63 G1 X-63.632 Y-70.472 Z0.25 F535.8 E0.1527*66
Recv: ok
// ok for N60
Send: N64 G1 X-61.753 Y-68.689 Z0.25 F535.8 E0.0409*66
Recv: ok
// ok for N61
Send: N65 G1 E-1.25 F1800.0*58
Recv: ok
// ok for N62
Send: N66 M103*17
Recv: Error:checksum mismatch, Last Line: 62
Recv: Resend: 63
Send: N63 G1 X-63.632 Y-70.472 Z0.25 F535.8 E0.1527*66
Recv: ok
// ok belonging to Resend
Recv: ok
// ok for N63
Send: N64 G1 X-61.753 Y-68.689 Z0.25 F535.8 E0.0409*66
Recv: ok
Send: N65 G1 E-1.25 F1800.0*58
Communication timeout during printing, forcing a line
Send: N65 G1 E-1.25 F1800.0*58
Recv: ok
// ok for N65
Recv: Error:line is not last line + 1, Last Line: 65
Recv: Resend: 66
// expected, since it did receive N65 twice
Send: N66 M103*17
Recv: ok
// ok belonging to Resend
Recv: ok
// ok for N66
The text was updated successfully, but these errors were encountered:
Problem
Communication timeouts during resends trigger the
M105
"revival mechanism", without honoring the resend's line number and instead using the current line number in the comm layer (which is too high). This leads to more "Resend" cascades and jumbling of line numbers.How to reproduce
Observed behaviour
Expected behaviour / Solution
Tricky to answer, but probably resending the same line that ran into a timeout makes more sense than trying to keep track of correct line numbers if M105 are sent in between active resend requests with increasing numbers.
So this should be the goal:
The text was updated successfully, but these errors were encountered: