Format Error, Wrong Checksum, Missing Linenumber

Alpine_Weiss

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

Alpine_Weiss

I have tried m111 s14 and it reproduce the error.

Repetier

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.

Alpine_Weiss

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 .

Repetier

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?

Alpine_Weiss

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...

Repetier

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?

Alpine_Weiss

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.

Repetier

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.

Alpine_Weiss

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

Repetier

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.

Alpine_Weiss

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 ?

Repetier

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?

Alpine_Weiss

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

Alpine_Weiss

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.

Alpine_Weiss

5 print done with V1.0 and still not a single error.

Repetier

So what was the trick? Using the other usb port on due? If so which one is now in use?

Alpine_Weiss

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.