My printer is anycubic delta kossel with marlin 1.1.9
What is the problem?
The printer halts midprint, upon checking the terminal I see it filled with this:
Send: N111069 G1 X-23.952 Y-13.75 E255\x00\x00\x005266*120
Recv: Error:No Checksum with line number, Last Line: 111068
Recv: Resend: 111069
Recv: ok
Send: N111070 G1 X-24.004 Y-13.947 E2588.55701*111
Recv: Error:Line Number is not Last Line Number+1, Last Line: 111068
Recv: Resend: 111069
Recv: ok
Send: N111069 G1 X-23.952 Y-13.75 E255\x00\x00\x005266*120
Recv: Error:No Checksum with line number, Last Line: 111068
Recv: Resend: 111069
Recv: ok
Send: N111070 G1 X-24.004 Y-13.947 E2588.55701*111
Recv: Error:Line Number is not Last Line Number+1, Last Line: 111068
Recv: Resend: 111069
Its worth noting that minutes before starting this print I finished printing successfully a 2.5hs print. so it doesn't fail often, but It became far more frequent recently.
What did you already try to solve it?
To be sure it wasn't something with octoprint install, I downloaded and configured a fresh copy, updated to octoprint latest and as posted above, one print finished OK
Here is octoprint.log until this error which fills it to the end:
Thanks for the reply, same links appeared as suggestions when I posted, first one is buggy firmware that send two lines as one, not my case.
Second one seems to be a buffer overflow.
In my case there is a ping-pong loop asking and resending one line ad eternum, communication is never lost or buffer overrun happening, they are like a facebook discusion, each side keeps saying the same and there is no moving forward LOL
Today I will try to print the same file from the SD card to see if it prints ok.
It's imperative to disable DisplayLayerProgress to verify that it's not adjusting the gcode stream sent to the printer. It registers to the gcode sending hook so it could potentially get in the way of OctoPrint.
found the error and it wasn't the plugin, it was an error generated during the gcode upload, the print failed at the same spot, so I downloaded the gcode from octoprint and using notepad++ I see three NUL characters, upon checking the local version of the same file its flawless.
So the new question is, why these characters are there and what could be the problem, it was uploaded via octoprint web client wirelessly to the raspberry as I usually do.
Is there a checksum or something done upon finishing the upload to check integrity?
@foosel would probably be the best one to answer this but I'm guessing she's on vacation for a bit.
If you're handy with the scp command you could just upload them to the Raspberry's watch folder and it would work the same way, perhaps more reliably.
From my own MacBook that might be something like:
cd ~/Desktop
# You should do an "ls -l ~/.octoprint" to confirm the location of the "watch" or "watched" folder.
scp MyFile.gcode pi@octopi.local:~/.octoprint/watch/.
Yes, I can upload via SCP when I'm local to the machine, but that is not always the case as I regularly start jobs from home so they are ready when I arrive at the office.
It would be great to be able to CRC uploaded files so one can be 100% sure they uploaded without a hitch.
The question is: What was the reason? And as you asked: How can that be prevented?
Did you upload via the OctoPrint web GUI or via API (like Cura/PrusaSlicer)?
So, you're at home... and you visited the web interface... at work... and uploaded from there (and then started it)? Sounds like you have either done port-forwarding or you have a VPN of some kind. I wonder if this has complicated the upload or the timing of the upload.
I was explaining scenarios where scp would't mork for me not that these were the case.
The "noise" in the gcode was generated via an upload via the webGUI while on the same subnet.
When I have some time will upload a bunch of gcodes via the GUI, then download them via SCP and diff with the originals to see if I can repeat the problem.
What log should I enable besides octoprint.log to try to isolate this issue?
Keep in mind that your browser is also a factor in all this. You haven't mentioned which one you're using. You might want to also compare your results with Safari or Chrome or something you're not using now.
I would guess that octoprint.log is the one to watch on this.
