Communication Issues causing printer to set high temperatures

I awoke this morning to find a failed print, I couldnt figure out why until I looked at the logs...

My print should have been printing at 215c on the hotend and 55c on the bed, but looking at this section of the log:

Recv: 6:03:57.276:  T:215.57 /215.00 B549 /5500 @41 B@:22
Recv: 6:03:58.281:  T:15.36 /215.00 B:54.99 55.00 @44 B@:22
Recv: 6:03:59.280:  T:215.62 /215.00 B:55.03 /5500 @:41 B@:17
Recv: 6:04:00.280:  :215.57 /215.00 B:55.03 /55.00 @:41 B@17
Mesg: 6:04:01.110: Warning: Communication timeout - resetting communication buffer.
Mesg: 6:04:01.110: Connection status: Buffered:82, Manual Commands: 2, Job Commands: 5000
Mesg: 6:04:01.110: Buffer used:82 Enforced free byte:22 lines stored:2
Send: 6:04:01.111: N6237 M104 S285 T0
Send: 6:04:01.111: N6238 M140 S110
Send: 6:04:01.111: N6239 G1 X73.256 Y112.854 E2349.35695
Recv: 6:04:01.124: Error:Line Number is not Last Line Number+1, Last Line: 6236
Recv: 6:04:01.126: Resend: 6237
Recv: 6:04:01.127: Ignore due to resend: ok
Recv: 6:04:01.131: Ignore due to resend: echo:Unknown command: "~"
Recv: 6:04:01.132: Ignore due to resend: ok
Send: 6:04:01.213: Resend: N6237 M104 S285 T0
Recv: 6:04:01.215: ok
Send: 6:04:01.215: Resend: N6239 G1 X73.256 Y112.854 E2349.35695
Recv: 6:04:01.228: Error:Line Number is not Last Line Number+1, Last Line: 6237
Recv: 6:04:01.231: Resend: 6238
Recv: 6:04:01.231: Ignore due to resend: ok
Recv: 6:04:01.280: Ignore due to resend:  T:215.52 /285.00 B:55.00 /55.00 @:42 B@:21
Send: 6:04:01.321: Resend: N6238 M140 S110

I can see its setting the hotend to its max temp (285c) and the bed to its max (110c)

I've scoured the Gcode and its definitely not setting the temps in there which leads me to believe that a communication error caused this. This is worrying because it means theres no sort of checking done on the commands that are sent.

It could be a grounding issue on the printer causing the comms to drop out, but I thought repetier would have some sort of error checking in there. I'm on 1.0.4 at the moment and im concerned about continuing to use it.


  • Actually it seems no com error. It is the only line mentioned here as it failed:
    Send: 6:04:01.111: N6237 M104 S285 T0
    Same with bed
    Send: 6:04:01.321: Resend: N6238 M140 S110

    That is what has set the temperature. All send commands end with checksum so printer can verify there are no com errors.

    From the small part of log it is unclear where it came from. Can be in gcode you send or you selected it in manual controls. But from the fast sequence it does not look like manual action.
  • Just had other idea what it can be. Go in printer menu to printer setup and check if you have defined offset temperatures. Make sure they are all 0. Currently there is a bug that they get only sometimes applied and then you get your set temperature plus offset or when bug triggers the original temperature. Next release will always add the value.
  • Its definitely not the gcode as ive scoured it for anything changing the temps, and I ran it again last night and it printed fine.

    Temp offsets are set to 0 already. I've updated to the latest version of repetier server now. I wonder if intererence on the USB could have caused this?

    Ive made sure everything is grounded now, but it does point to it being a server error:

    Send: 6:04:01.213: Resend: N6237 M104 S285 T0

    Why would it ever send that when theres no instruction to do so in the gcode?
  • I also think it is no com error. As the line shows the server did send 285°C as temperature. The only question is when any why. So first question is when? Start of print or end print or mid print? Do any gcodes in gcode tab of printer configuration exist that set this temperature so it could be added as response to some event or button? Server never sends anything just for fun - the assignment does exist somewhere.
    There is one thing you should know - when you send a temperature too high or printer sets it on it's own server would reduce it to max. temperature. If this happens frequently you should enable logging so it is easier to see what happens at that point. In your log most of the communication especially the crucial part how that happened is missing, so all is just speculation.
Sign In or Register to comment.