Format Error, Wrong Checksum, Missing Linenumber

Hello everyone, I am having communication problem between Server ( Raspberry Pi) and my printer (Kossel Mini). 
This is what I have tried to troubleshoot:
-Run direct from Usb to PC = No error
-Debug with M111 s24       = No error

 Anyone can help ?

Here is what happened on the log , long pause made stepper disabled and result layer shift or hitting print...

16:19:57.418 : Printing layer 1 of 140
16:20:08.333 : Error:Missing linenumber
16:20:08.333 : Resend:156
16:20:19.798 : Error:Format error
16:20:19.798 : Resend:209
16:24:41.888 : Error:Format error
16:24:41.888 : Resend:2352
16:24:45.084 : Error:Format error
16:24:45.084 : Resend:2356
16:24:57.172 : Error:Format error
16:24:57.172 : Resend:2377
16:25:14.649 : Error:Wrong checksum
16:25:14.649 : Resend:2420
16:26:02.680 : Resend:2552
16:26:03.831 : Error:Format error
16:26:03.831 : Resend:2557
16:28:56.279 : Zd  @3:0
16:29:09.424 : Resend:3564
16:29:14.887 : /M37 /0 @3:0
16:29:41.647 : Error:Format error
16:29:41.647 : Resend:3664
16:29:53.110 : Error:Format error
16:29:53.110 : Resend:3687
16:32:07.393 : Printing layer 2 of 140
16:32:30.906 : Error:Format error
16:32:30.906 : Resend:5011
16:35:14.106 : Error:Wrong checksum
16:35:14.106 : Resend:6693
16:36:41.461 : Error:Wrong checksum
16:36:41.461 : Resend:7003
16:37:39.380 : Error:Wrong checksum
16:37:39.380 : Resend:7113
16:38:42.665 : Successfully send push message.
16:38:48.189 : Warning: Communication timeout - resetting communication buffer.
16:38:48.189 : Connection status: Buffered:19, Manual Commands: 3, Job Commands: 0
16:38:48.189 : Buffer used:19 Enforced free byte:0 lines stored:1
16:38:48.190 : Info:Autoleveling disabled


  • I have tried m111 s14 and it reproduce the error.
  • So as soon as you enable steppers you get communication errors printing from pi but printing same prom a pc would work? If you have try putting a active(powered) hub between printer and pi. Then the hub reduces power load on the pi and also filters usb signals. Alternatively a lower baud rate like 115200 could work.

  • Yes exactly printing from pc using same usb cable give no communication error. I have tried other baudrate with pc but with the PI it keep connect/disconnect and I am not able to use the printer with rate lower than 250000. The Pi is powered by a 5A 12v to 5v regulator connected on the GPIO. I will install a voltmeter on the output of the regulator to record a voltage drop.

    I have read things about buffer size who can give error on Arduino Due. Can you give me help about that ?

    I will try with a usb hub when as soon as I receive a male to male usb. 

    Thanks a lot for your support .
  • If you compiled with recent Arduino IDE buffer size is 127 byte. Older had 63 bytes. In general same buffer size as in host should work, but you are right. This kind of problems can happen also with wrong buffer size.

    Regarding power connector make sure usb cable is also with good wires so pi gets >5V at the receiving side.

    Aren't all usb hubs male to male?
  • I have done a couple of test and here is what I have found. By accident one time I have disconnected the PI from the supply on the GPIO but the PI was still connected to usb and didnt turned OFF. But if a do this now the PI will not stay ON. Maybe the converter who supply voltage to the usb on the Arduino is dead ? I have tried to put an active usb hub but it didnt solve the error.

    Next, I have 4 extruders and I have found if I only keep one mapped without any hardware change the problem disapear...

  • Only one mapped means configured firmware for 1 extruder?

    Having all 4 and only ever activating same extruder should behave the same. Switching active extruder might then activate the problem. If that is the case check where the motor/heater wires go. But on the other side printing in dry run does not use any extruder and you said that failed as well right?

  • By only one mapped I mean 4 in firmware but only one in Host.

    I am a hundred percent sure the problem is software now. Value in the eeprom were set at -1 and this is what seems to produce the error. I have added extruder one by one and each time after adding one I have run a 6 hour print in dry mode. I think the error are generated by a conflict between different value from Host ,Eeprom and Server. 

  • Host doe snot really matter as it just sends gcode and the error is communication. Only baudrate influences communication on host side. But you also mention server so same rules here. eeprom contains baud rate and some parts influencing how hardware is controlled. So that would be part of firmware configuration.

    I think it depends on which extruders get power, so if you are using extruder 1, 2, 3 or 4 or even heat several at once. That would be a slicer setting if they got used. More active extruders make more problems with power unit as all extruders are turned on the same time, so the current rise per pulse increases. That could mean more induction or a bigger voltage drop.
  • Maybe I am on a wrong track but error appears with only one extruder powered. To my eyes it look like when I have 4 extruders configured communication are more loaded. When the extruder are off , firmware continue to monitor the temperature. I have tried to keep all the hardware unchanged and only keep one extruder in the firmware with no errors. 

    Since my last post I have buy an other usb cable and I have added a 5A usb supply to the PI and I am still having communication issuse.

    19:53:56.692 : Warning: Communication timeout - resetting communication buffer.
    19:53:56.692 : Connection status: Buffered:19, Manual Commands: 2, Job Commands: 5000
    19:53:56.692 : Buffer used:19 Enforced free byte:0 lines stored:1

  • Yes with 4 extruders we get data for all 4 extruders and that increases likelyhood of errors. On the other side you said with a pc it was error free under same conditions. So why is the pi communicating so badly then? Honestly I can not say, only that I know it can also do without errors. If heaters are of and you print in dry run it still communicates the same amount of data minus a few byes since 0 is shorter then 200, also right? So if that also works the real enabling of heaters starts creating the problem.
  • If I run print same print in dry mode I get errors. I have a multimeter who can record voltage drop. I have run the print in dry mode and look at what the meter have logged and there is no significant voltage drop. 

    I have a lcd screen connected on the radds and you can see the buffer usage. It is always between 15 and 19 but when communication drop it came empty. 

    Do you suggest me to remplace the PI ?
  • You could also try the other usb port of the due, not sure which you are now using. Just remember to change configuration accordingly or configure it to use both ports so you can switch any time.

    Strange thing is that it works on pc, so that makes you of course think pi could be the reason. But since it works for a while I do not think it would solve the problem. With an active usb in front you have already replaced the communicating part and decoupled printer from pi. Or didn't you do that test?
  • Sorry for the delay. Job take all my time.

    I have tried the solution with the active USB hub with no success. The first one I have tried was cheap so I have to tried a better one before saying it was not working for me. I am still getting the same error I was having with the Arduino plugged directly in the PI. 

    I will try with the second usb port on the Arduino this week. Thanks
  • Today I have uploaded firmware V1.0 and I have run a 3 hours print with not a single communication error. I will try a 7 hours print with bigger layer to see what happen.
  • 5 print done with V1.0 and still not a single error.
  • So what was the trick? Using the other usb port on due? If so which one is now in use?
  • This is the weird thing I haven't made change in the hardware. I simply upload the new firmware. After running a couple successful print I have remove the usb hub and not a single error.  
Sign In or Register to comment.