Communication Issue

What is the problem?
Printer stops with error "Error:Line Number is not Last Line Number+1"

What did you already try to solve it?
Changed baud rate.
Changed USB cable.
Tried alternate communication using a small section of USB cable in a direct connection from Raspberri Pi GPIO pins to the mainboard's WiFi connector port (UART 3) less than 1 foot long with ferrite bead on one end. Data wires only connected.

Logs (syslog, dmesg, ... no logs, no support)
Sorry I don't have complete logs at the moment. This is just a snippet copied from the terminal. I am running a print in safe mode right now and will post logs if it fails.

Send: N113249 G1 X151.831 Y97.946 Z52.292 E4.689659
Recv: ok N113249 P1 B3
Send: N113250 G1 X152.453 Y99.235 Z52.292 E4.7165
61
Recv: Not SD printing
Recv: T:221.00 /220.0000 (240.0000) B:60.00 /60.0000 (3428.0000) @:70 B@:45
Recv: Not SD printing
Recv: Not SD printing
Recv: T:220.25 /220.0000 (243.0000) B:60.00 /60.0000 (3428.0000) @:127 B@:0
Recv: Not SD printing
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N113251 M10518
Recv: echo:Unknown command: "113250 G1 X152.N113251 M105"
Recv: ok P15 B3
Send: N113252 G1 X153.005 Y100.542 Z52.293 E4.7432
9
Recv: Error:Line Number is not Last Line Number+1, Last Line: 113249
Recv: T:220.25 /220.0000 (243.0000) B:60.00 /60.0000 (3428.0000) @:120 B@:25
Recv: Not SD printing
Recv: Not SD printing
Recv: T:220.25 /220.0000 (243.0000) B:60.00 /60.0000 (3428.0000) @:73 B@:14
Recv: Not SD printing
Recv: T:220.00 /220.0000 (244.0000) B:60.00 /60.0000 (3428.0000) @:100 B@:11
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N113253 M105*16
Recv: Not SD printing
Recv: Error:Line Number is not Last Line Number+1, Last Line: 113249
Recv: Not SD printing

Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)

My printer is a heavily modified Ender 5 Pro. It has an SKR 1.4 Turbo installed running stable Marlin 2.0.7.2 and a Raspberry Pi 4 running the current version of OctoPrint both in a custom enclosure. Probably too many plugins. TFT35 E3 touch screen which will probably go away for a touch screen connected to the Pi. Dual extruders into a single nozzle.

I've read through many of the posts on the forum that reported a similar Error:Line Number is not Last Line Number+1. It led me to the point where I'm at now with a cut off USB cable connected to the Pi's TX/RX pins to the SKR's TX/RX pins plus grounding the shield wire in the unused Wi-Fi connector configured as UART 3. Used the one ferrite bead I have on the cable. I thought that I had solved the problem but 7 hours into a print it reoccurred and failed the print.

So I'm wondering if anyone who knows more about electronics and communications would have any suggestions. I know enough to be dangerous but not proficient. I've seen several suggestions, most of which I've tried over the past couple of weeks when the issue started. I'm almost certain that communication dropped out based upon the line from the log above "Recv: echo:Unknown command: "113250 G1 X152.N113251 M105". Looks like it missed the g-code in the first part of the line. Could it possibly be a noisy power supply? Maybe the TFT35 E3 doing something that interrupted communications?

Would I need to enable something in OctoPrint to get a good set of logs for uploading here if necessary? I'm not very fluent in Linux based systems.

Edit: Checked the output of the power supply. 24.2 VDC. It has .34 V AC ripple on the DC output.

Many thanks in advance.

You need 3 wires connected for serial communications to work (reliably) TX, RX, and ground. I don't believe grounding the shield is the same as connecting the actual ground wire. The shield's purpose is to mitigate external interference.

1 Like

Thanks for the reply. I had to walk away from it for a couple of days because I was getting frustrated. Seemed I had the issue resolved and the printer finished an 18 hour print successfully but the next print crashed 4 hours in. I'm going to modify the connection to use an internal wire as the ground though I still will ground the shield on one end. That is a common thing to do in aviation wiring and probably what I should have done originally. But in the mean time, I changed the firmware back to use the regular USB port, disabled a bunch of useful but not necessary plugins, and I installed the DryRun plugin so that I can run a few simulated prints so as not to waste more plastic & heating energy while I continue to troubleshoot. As an aircraft technician, I truly hate rare intermittent faults. Makes troubleshooting such a pain in the ass.