›

Warning: Communication timeout - resetting communication buffer.

ozgursimsekozgursimsek
in Repetier-Server
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;
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

  • RepetierRepetier
    The problem here is caused by
    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.
  • ozgursimsekozgursimsek
    edited June 2017
    I am using Marlin Firmware. 

    I enabled sending "wait" when idle. I configured communication timeout seconds: 3 second. 

    There is an error during heating. When printing started , it resended:

    7:29:47.456: X:3.00 Y:98.00 Z:133.00 E:0.00 Count X: 300 Y:9800 Z:27400 (3)
    7:29:47.456: ok
    7:29:47.456: N1860 M105
    7:29:47.458: ok T:201.5 /200.0 @:29
    7:29:47.462: Error:checksum mismatch, Last Line: 1773
    7:29:47.466: Resend: 1774
    7:29:47.477: ok
    7:29:47.478: ok T:201.5 /200.0 @:29
    7:29:47.478: ok
    7:29:47.478: Resend: N1774 G1 Z15.0 F3600 ;move the platform down 15mm
    7:29:47.478: Resend: N1775 G92 E0 ;zero the extruded length
    7:29:47.479: Resend: M117 ETA 07:35:28 day 12
    7:29:47.479: Resend: N1776 M105
    7:29:47.479: Resend: N1777 M105
    7:29:47.479: Resend: N1778 G1 F200 E3 ;extrude 3mm of feed stock
    7:29:51.470: echo:busy: processing (2)
    7:29:52.098: X:3.00 Y:98.00 Z:133.00 E:0.00 Count X: 300 Y:9800 Z:27400 (3)
    7:29:52.098: ok
    7:29:52.098: Resend: N1779 G92 E0 ;zero the extruded length again
    7:29:52.098: Resend: N1780 G1 F3600
    7:29:52.103: ok (3)
    7:29:52.103: ok T:200.3 /200.0 @:49
    7:29:52.104: Resend: N1781 M105
    7:29:52.104: Resend: N1782 M105
    7:29:52.104: Resend: N1783 M301 H1 P26.38 I2.57 D67.78
    7:29:52.107: ok T:200.3 /200.0 @:49
    7:29:52.107: Resend: M117 Printing...

    when printing there isn't error.
  • RepetierRepetier
    You need to show a log where the error starts to say what goes wrong. Here you are already 100 lines after the initial error. (N1860 M105 is alread send while 1773 is last processed line according to firmware)

    What I see is you also enabled busy whcih is good. Just line numbers are still missing as last correction help.
  • BigAlBigAl
    edited July 2018
    Hi,
    the communication to the Prusa's printer is imho a little bit laggy in some cases. This is not the fault of the Repetier Server but the inconsistency of the Prusa firmware. It is very easy to set the printer in "wait forever" states. E. g. when the printer waits to reach a target temperature and heating is off...

    Anyway: Repetier Server should respect the different temperature messages that will be received as an answer to  M105. If the printer is waiting to reach a tempereature (e.g. nozzle temperature to 190°C => M109 S190) the M105 response is T:43.6 E:0 W:? and shortly before the temperate is reached the W:? counts down. Like this:

    ...
    20:25:56.500: T:48.0 E:0 W:?
    20:25:57.503: T:48.6 E:0 W:?
    20:25:58.503: T:49.5 E:0 W:2
    20:25:59.506: T:50.2 E:0 W:1
    20:26:00.509: T:50.7 E:0 W:0
    20:26:00.964: ok

    In thsi case the target was set to 50°C. If the heatbed is heating up and wait for the temperature the response to M105 is:

    ...
    20:28:11.492: T:49.98 E:0 B:29.8
    20:28:12.496: T:50.02 E:0 B:29.8
    20:28:12.796: ok

    As I wrote above it's very inconsistency (or as we say in Germany "totaler Mist")...

    But: The Prusa MK2 / MK2.5 and MK3 is one of the most common 3D printers and it should be fully supported by Repetier Server. The support should be at least as good as in Octoprint...

    Alex
  • RepetierRepetier
    Not having a prusa printer makes it hard to optimize single printer solutions.

    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.
Sign In or Register to comment.