Warning: Communication timeout - resetting communication buffer.
Problems occur during heating when first printing is applied. But if the printing is canceled and reprinted, the error occurs during heating. If the Repetier server is deactivated and restarted, the first print does not generate an error. But there is an error during heating other printing.
Not Error first printing;
...
Error other printing:
Not Error first printing;
8:17:52.128: N47 M109 S200.000000
8:17:52.152: X:100.00 Y:0.00 Z:133.00 E:0.00 Count X: 10000 Y:0 Z:27400
8:17:52.152: ok
8:17:52.152: N48 G21 ;metric values
8:17:52.153: N49 G90 ;absolute positioning
8:17:52.154: ok
8:17:52.154: echo: cold extrusion prevented
8:17:52.155: N50 M82 ;set extruder to absolute mode
8:17:52.157: echo: cold extrusion prevented
8:17:52.164: ok (3)
8:17:52.164: T:48.8 /200.0 @:0 W:?
8:17:52.164: N51 M107 ;start with the fan off
8:17:52.165: N52 G28 X0 Y0 ;move X/Y to min endstops
8:17:52.165: N53 G28 Z0 ;move Z to max endstops
8:17:54.161: T:48.7 /200.0 @:127 W:? (2)
8:17:55.162: T:48.8 /200.0 @:127 W:?
8:17:56.162: T:49.3 /200.0 @:127 W:?
8:17:57.163: T:50.2 /200.0 @:127 W:?
8:17:58.161: T:51.1 /200.0 @:127 W:?
8:17:59.163: T:52.4 /200.0 @:127 W:?
8:18:00.162: T:53.9 /200.0 @:127 W:? ...
Error other printing:
8:17:57.361: X:3.00 Y:0.00 Z:0.00 E:0.00 Count X: 300 Y:0 Z:0
8:17:57.361: ok
8:17:58.245: X:3.00 Y:98.00 Z:133.00 E:0.00 Count X: 300 Y:9800 Z:27400
8:17:58.245: ok
8:17:58.245: N47 M105
8:17:58.246: N48 M105
8:17:58.347: X:3.00 Y:98.00 Z:133.00 E:0.00 Count X: 300 Y:9800 Z:27400
8:17:58.350: ok (2)
8:17:58.351: echo: cold extrusion prevented
8:17:58.351: N49 M109 S200.000000
8:17:58.351: N50 G21 ;metric values
8:17:58.353: echo: cold extrusion prevented
8:17:58.357: ok (3)
8:17:58.358: ok T:117.9 /0.0 @:0
8:17:58.358: N51 G90 ;absolute positioning
8:17:58.358: N52 M82 ;set extruder to absolute mode
8:17:58.358: N53 M107 ;start with the fan off
8:17:58.358: N54 G28 X0 Y0 ;move X/Y to min endstops
8:17:58.359: N55 G28 Z0 ;move Z to max endstops
8:17:58.360: ok T:117.9 /0.0 @:0
8:17:58.362: T:117.9 /200.0 @:0 W:?
8:17:59.361: T:117.6 /200.0 @:127 W:?
8:18:00.361: T:117.3 /200.0 @:127 W:?
8:18:01.362: T:117.1 /200.0 @:127 W:?
8:18:02.360: Warning: Communication timeout - resetting communication buffer.
8:18:02.361: Connection status: Buffered:114, Manual Commands: 2, Job Commands: 5000
8:18:02.361: Buffer used:114 Enforced free byte:23 lines stored:8
8:18:02.361: M117 ETA 08:31:22 day 6
8:18:02.361: T:117.2 /200.0 @:127 W:?
8:18:02.362: N56 M105
8:18:02.362: N57 M105
8:18:02.362: N58 G1 Z115.0 F3600 ;move th e platform up 20mm
8:18:02.362: N59 G28 Z0 ;move Z to max endstop
8:18:02.362: N60 G1 Z15.0 F3600 ;move the platform down 15mm
8:18:02.363: N61 G92 E0 ;zero the extruded length
8:18:03.362: T:117.6 /200.0 @:127 W:?
8:18:04.363: T:118.3 /200.0 @:127 W:?
8:18:05.361: T:119.1 /200.0 @:127 W:?
8:18:06.363: T:120.2 /200.0 @:127 W:?
8:18:06.363: Warning: Communication timeout - resetting communication buffer.
8:18:06.363: Connection status: Buffered:123, Manual Commands: 1, Job Commands: 5000
8:18:06.364: Buffer used:123 Enforced free byte:18 lines stored:7
Comments
N49 M109 S200.000000
which is a slow command taking longer then timeout seconds. Server knows this and as long as it thinks it is not finished will not cause the timeout. It is not that visible now if the M109 got a matching ok and 5 more commands so run out of the test scope for slow commands, but somehow this is exactly what has happened.
What firmware exactly are you using? I have seen that marlin was working on a system of extra buffer so that is what could cause the "ok" to confuse server.
On the other side if you use such a new marlin version, it also has nice additions that help hosts to fix/detect problems much better and would have prevented this:
- Enable busy protocol or however they call it. This tells server when firmware is running a slow command so you can even reduce timeout to 3 seconds.
- Enable line numbers in ok. This allows detecting missed "ok" on the fly without needing to hit timeout. Also keeps performance up to a good level.
- Enable sending "wait" when idle. This informs server that all commands are processed.
I have no idea why they do not enable these by default. These are very big adds to stable communication.
I enabled sending "wait" when idle. I configured communication timeout seconds: 3 second.
There is an error during heating. When printing started , it resended:
when printing there isn't error.
What I see is you also enabled busy whcih is good. Just line numbers are still missing as last correction help.
T: is the current extruder temperature. Do I understand it correctly that prusa uses this for the active device waiting for target temperature or was this a extruder example as 50°C is normally a bed temperature? So how would one get the other temperatures if they are omited in that case? If I understand you correctly the inconsisty is that extruder gets that temperature also if it is not the extruder heating.
Could I use the W: to ignore the output to get more consistent and correct temperatures in server or is the W: always present? What is E: for, any idea.
If someone tells me about problems I will always try to solve them, but we only have limited number of printers so can not know all modifications for all firmwares around.