Just in case, the only plugin I installed in octoprint besides the ones that came bundled is DisplayLayerProgress
[edit] If any additional log could help to solve this, please let me know and I will enable it/them and run the code again.
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.
Disabled it, restarted octoprint and its printing, 6+ hours to go, used the same file uploaded yesterday, lets hope for the best...!
@OllisGit Sounds like something's going on with DisplayLayerProgress.
It doesn't look like it's trying to change the gcode, for what it's worth.
Update: Nevermind then.
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?
What can I do now to trust uploaded files again?
Thanks
2 Likes
@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.
Thanks
I somehow assumed that that happened.
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)?
It was uploaded via Octoprint web GUI.
Now I uploaded the file again, but this time via SCP to see if it prints.
I assume it's an error with a MTBF of 1.000.000 years 
It would be great to know why the web GUI upload fails, now I suspect all my previous failed prints were due to this
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?
Thanks
Fair enough.
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.
I use Chrome/latest on win10/latest let me put the doubts somewhere else...
I am upping this topic because I have the same issue when I use octoprint. If I print through SD the issue does not happen. Have tried with all plugins disabled and deactivated the cheksum commands on octoprint. Issue is still the same.
I understand that his may be a Marlin issue. Nevertheless Ocoprint seems to amplify it as it keeps beeping printers sometimes haltings the prints altogether.
The solution I found for local uploads is to use SCP and transfer them to the watched folder, this way never had the problem again. From home I just use the octoprint web interface and no problems at all.
The problem manifests when I use the octoprint web interface in the local network where the printer is.
Ok, thanks for your reply. But the solution seems to be circumventing octoprint's interface which I can do already if I just print through the SD card. The issues seems to be with octoprint's interface.
No, a communication error reported from the printer's firmware is not "with OctoPrint's interface". You have noise on your serial line. That will negatively affect prints made via serial, and not at all influence SD card prints. You'll either have to figure out what's causing your noise issues and solve them:
or you won't be able to use anything that uses your printer's serial line to communicate with it, like OctoPrint or any other host for that matter.
Apart from that, this thread is 2y old, I'm closing this. Please create a new topic if you need further assistance, with all requested info included.