unknown command and communication timeout

RAyWB

Hi,i use radds/due and Repetier Server 90.4 on raspi3.Firmware is Repetier 1.0.2Raspi is connected via 20cm Usb cable to due and via lan to Network.i tried to print one model several times , but unfortunately i get lot of Messages with unknown command .some communication timeouts also happen , which cause a big blob in print.Asi cannot find anything Special in gcode file I´m not shure how to fight against this.tried to increase buffers in Firmware from 30 to 50 , then to 100 same result.tried to increase baud rate from 76800 to 250000 , no Change.tried to update Server from 90.4 to 90.6 , no Changealso tried direct print via USB, no Changethe Special on the model is just that is has extreme high quantity on small segments.
Log Shows only the Messages with unknown commands and communiation timeouts.print Speed is 120mm/s , travel Speed is 800mm/sadditional info : slower print (at 70mm/s travel Speed 800mm/s) succeded(may be there is enough time for Software to fix communication timeouts)as i cannot find anything Special in gcode (only G1 moves in the file) the question:are lines starting with ; in gcode interpreted as unknown commands?and : can a couple of unknown commands cause a comunication timeout?what can i do to solve this Problem?

Repetier

Comments with ; are stripped server side and not send at all. That would only delay real commands.

High speeds and small segments in deed push a lot of stress to communication. On a pi you can send around 300-350 commands per second. Try M111 S24 to test pure communication capability. If the short segments need higher communication speed you will get slow downs or very short pauses. If commands get interpreted the load in firmware increases and might cause communication errors. AT least I sometimes have the feeling that errors get more if we are near the limits.

What is the exact error message. Firmware always prints the gcode as it thinks it received it.

RAyWB

i had same effect printing via USB from Win7 Computer, so i guess it might be caused by Firmware.i can give a print from SD Card a try.will take a look on exact error message in log file this evening

RAyWB

Thats what is in Log :

> 23:12:26.922: ok 3459
< 23:12:26.922: N3461 G1 X129.777 Y167.223 Z0.180 E3.7712 F2888
> 23:12:27.046: T:233.13 /234 B:59.94 /60 B@:114 @:180 T0:233.13 /234 @0:180 T1:20.62 /0 @1:0
> 23:12:27.047: ok 3460
> 23:12:27.047: ok 3461
> 23:12:27.047: Unknown command:
> 23:12:27.047: Unknown command:
< 23:12:27.047: N3462 G1 X129.472 Y167.224 Z0.180 E3.7798 F2888
> 23:12:27.047: Unknown command:
< 23:12:27.047: N3463 G1 X127.663 Y167.115 Z0.180 E3.8311 F2888
> 23:12:27.049: Unknown command:
> 23:12:27.049: Unknown command:
> 23:12:27.049: Unknown command:
> 23:12:27.053: ok 3462
> 23:12:27.053: ok 3463
> 23:12:27.053: Unknown command:
< 23:12:27.053: N3464 G1 X126.878 Y167.086 Z0.180 E3.8534 F2888
< 23:12:27.053: N3465 G1 X126.034 Y167.020 Z0.180 E3.8774 F2888
> 23:12:27.057: ok 3464
> 23:12:27.057: ok 3465

then :

> 0:27:28.486: T:245.77 /245 B:55.17 /55 B@:64 @:60 T0:245.77 /245 @0:60 T1:20.31 /0 @1:0
> 0:27:29.493: T:245.77 /245 B:55.17 /55 B@:47 @:60 T0:245.77 /245 @0:60 T1:20.31 /0 @1:0
> 0:27:30.099: Warning: Communication timeout - resetting communication buffer.
> 0:27:30.099: Connection status: Buffered:54, Manual Commands: 0, Job Commands: 5000
> 0:27:30.099: Buffer used:54 Enforced free byte:27 lines stored:2
< 0:27:30.099: N237316 G1 X142.385 Y118.497 Z11.880 E5.3495 F4290
< 0:27:30.099: N237317 G1 X142.297 Y118.249 Z11.880 E5.3636 F4290
> 0:27:30.476: ok 40706
< 0:27:30.476: N237318 G1 X142.207 Y118.044 Z11.880 E5.3757 F4290
> 0:27:30.

and that´s one causing big blob :

< 0:42:11.250: N303999 G1 X123.571 Y100.920 Z14.280 E5.8444 F5775
< 0:42:11.250: N304000 G1 X123.979 Y100.897 Z14.280 E5.8554 F5775
> 0:42:11.253: Unknown command:
> 0:42:11.254: Unknown command:
> 0:42:11.254: Unknown command:
> 0:42:11.254: ok 41855
< 0:42:11.254: N304001 G1 X124.788 Y100.770 Z14.280 E5.8775 F5775
> 0:42:11.259: ok 41856
> 0:42:11.259: ok 41857
< 0:42:11.259: N304002 G1 X126.394 Y100.636 Z14.280 E5.9210 F5775
< 0:42:11.259: N304003 G1 X127.047 Y100.624 Z14.280 E5.9386 F5775
> 0:42:11.263: Unknown command:
> 0:42:11.263: Unknown command:
> 0:42:11.263: Unknown command:
> 0:42:11.263: Unknown command:
> 0:42:11.266: ok 41858
> 0:42:11.266: Unknown command:
< 0:42:11.266: N304004 G1 X127.613 Y100.653 Z14.280 E5.9539 F5775
> 0:42:11.270: Error:Checksum required when switching back to ASCII protocol.
> 0:42:11.284: Resend:41859
> 0:42:11.296: ok
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.296: Unknown command:
> 0:42:11.297: Unknown command:
> 0:42:11.297: Unknown command:
> 0:42:11.297: Unknown command:
> 0:42:11.297: Unknown command:
< 0:42:11.297: Resend: N304003 G1 X127.047 Y100.624 Z14.280 E5.9386 F5775
< 0:42:11.297: Resend: N304004 G1 X127.613 Y100.653 Z14.280 E5.9539 F5775
> 0:42:11.299: Unknown command:
> 0:42:11.299: Unknown command:
> 0:42:11.299: Unknown command:
> 0:42:11.299: Unknown command:
> 0:42:11.303: Unknown command:
> 0:42:11.303: Error:Wrong checksum
> 0:42:11.315: Resend:41859
> 0:42:11.323: ok
> 0:42:11.323: Unknown command:
> 0:42:11.323: Unknown command:
> 0:42:11.323: Unknown command:
< 0:42:11.324: N304005 G1 X128.539 Y100.656 Z14.280 E5.9788 F5775
< 0:42:11.324: N304006 G1 X129.024 Y100.704 Z14.280 E5.9920 F5775
> 0:42:11.430: Unknown command:
> 0:42:11.450: Unknown command:
> 0:42:11.454: Unknown command:
> 0:42:11.495: Unknown command:
> 0:42:11.499: Unknown command:
> 0:42:11.626: Unknown command:
> 0:42:11.642: Unknown command:
> 0:42:11.642: Unknown command:
> 0:42:11.647: Unknown command:
> 0:42:11.648: Unknown command:
> 0:42:11.648: Unknown command:
> 0:42:11.648: Unknown command:
> 0:42:11.648: Unknown command:
> 0:42:11.648: Unknown command:
> 0:42:11.650: Unknown command:
> 0:42:11.650: Unknown command:
> 0:42:11.654: Unknown command:
> 0:42:11.654: Unknown command:
> 0:42:11.658: Unknown command:
> 0:42:11.658: Unknown command:
> 0:42:11.662: Unknown command:
> 0:42:11.662: Unknown command:
> 0:42:11.667: Unknown command:
> 0:42:11.668: Unknown command:
> 0:42:11.671: Unknown command:
> 0:42:11.672: Unknown command:
> 0:42:11.675: Unknown command:
> 0:42:11.676: Unknown command:
> 0:42:11.679: Unknown command:
> 0:42:11.680: Unknown command:
> 0:42:11.683: Unknown command:
> 0:42:11.684: Unknown command:
> 0:42:11.688: Unknown command:
> 0:42:11.688: Unknown command:
> 0:42:11.692: Unknown command:
> 0:42:11.692: Unknown command:
> 0:42:11.728: Unknown command:
> 0:42:11.774: Unknown command:
> 0:42:11.774: Unknown command:
> 0:42:11.778: Unknown command:
> 0:42:12.074: T:246.15 /245 B:55.17 /55 B@:47 @:50 T0:246.15 /245 @0:50 T1:20.31 /0 @1:0
> 0:42:13.082: T:245.00 /245 B:55.17 /55 B@:64 @:220 T0:245.00 /245 @0:220 T1:20.31 /0 @1:0
> 0:42:14.089: T:244.62 /245 B:55.17 /55 B@:47 @:220 T0:244.62 /245 @0:220 T1:20.31 /0 @1:0
> 0:42:15.097: T:244.62 /245 B:55.17 /55 B@:47 @:220 T0:244.62 /245 @0:220 T1:20.31 /0 @1:0
> 0:42:15.329: Warning: Communication timeout - resetting communication buffer.
> 0:42:15.329: Connection status: Buffered:54, Manual Commands: 1, Job Commands: 5000
> 0:42:15.329: Buffer used:54 Enforced free byte:27 lines stored:2
< 0:42:15.329: N304007 M117 ETA 05:35:11 day 3
< 0:42:15.329: N304008 G1 X129.672 Y100.694 Z14.280 E6.0095 F5775
> 0:42:15.538: Resend:41859
> 0:42:15.545: Resend after 4253ms
> 0:42:15.555: ok
< 0:42:15.555: Resend: N304003 G1 X127.047 Y100.624 Z14.280 E5.9386 F5775
< 0:42:15.555: Resend: N304004 G1 X127.613 Y100.653 Z14.280 E5.9539 F5775
> 0:42:15.563: ok 41859
> 0:42:15.563: ok 41860
< 0:42:15.563

Repetier

Seems you have set input buffer in server to 63 byte. I'm quite sure 127 is also ok.

Commands seem empty so not having any content after parsing. But that is the first time I've seen so much of them. Since you said it only happens at high speed my guess is that the stepper interrupt is eating too much cpu time so serial interrupt does miss some chars causing this unexpected behaviour. If you reduce max. feedrate would that problem go away?

What even wonders me more is that some of them do not cause a problem with the commands. I would expect an checksum error or missed line for every unknown command.

RAyWB

Server Input buffer is set to 127.

M111 S24 showed lots of errors, changed to dues native usb now, looks much better(only 55 errors on more than 2 million lines)

started print now and will inform you tomorrow

RAyWB

Well, communication Errors on native Port are much better, not a single unknown command , but print also failed on a couple of timeouts and missing lines detected.
Quote:"Since you said it only happens at high speed my guess is that the stepper interrupt is eating too much cpu time so serial interrupt does miss some chars causing this unexpected behaviour"-Might be you´re right as i use "slow" DRV8825 Drivers , Need Stepper High Delay 1 and double step delay 2 to loose no stepswill try to reduce max feedrate from actually 900 down to 600 for test.
but i think there may be several issues in sum , Needs more examination from my side

RAyWB

Communication works fine on native port , last print was 8 errors on 2.2Million lines

also found stopping sequence caused by s3d..... wrong feedrate generated on retract/wipe

Any Idea whats wrong on Programming port causing that huge amount of errors?

Repetier

Did you test after M111 S24 so only communication is tested.

Plan is that the serial interrupt has a higher priority then stepper interrupt or other interrupts on due so it never looses a byte. Problem is you need to poll bytes before next byte appears or you will loose it. At least on AVR this was the case. On due we use the arduino provided solution so it might differ from what I expect here. Need to investigate this further. I'm currently a bit confused about this and still working on the laser modification for V2 from weekend. Is more complicated then I thought to get a good solution here.

RAyWB

The M111 S24 also showed a lot of communication Errors on Programming Port , that´s why i swapped over to native Port.I´ll continue the search on Due... might be the USBSerialFirmware of the 16u2.As i have a China clone may be that´s an issue. I´ll Try to update the 16U2 this evening, will inform you the results.

Repetier

That might in deed be cause if that is not using the original sources.

RAyWB

Communication problems seem solved after updating the 16u2. (still running but the last 1000000 lines with not asingle error)

Repetier

Great, so no firmware error just bad driver drivers on the board:-)