gcode file being corrupted when sending to Octoprint

[kanawati975]

I posted this in Cura as a bug and I was told to post it here... While using the plugin and sending the gcode file to Octoprint, the gcode file is being corrupted, which makes the printer hangs and report an error.

This happend 2 out of 5 attemps.

[fieldOfView]

Please attach or link to your Cura.log and OctoPrint logs so I can check if there's something strange going on.

All I can think of is that the filesystem or the SD-card may be corrupt, because I don't see how the Cura OctoPrint Connection plugin could mangle the file like this.

[kanawati975]

cura.log octoprint.log

[kanawati975]

Please attach or link to your Cura.log and OctoPrint logs so I can check if there's something strange going on.

All I can think of is that the filesystem or the SD-card may be corrupt, because I don't see how the Cura OctoPrint Connection plugin could mangle the file like this.

The transfer is via LAN connection, so no SD Cards were involved,

[fieldOfView]

There's an SD card in your Raspberry Pi.

Do you often just cut the power to the Raspberry Pi without shutting down? The OctoPrint log shows you did that at least once (out of 2 times starting OctoPrint).

[kanawati975]

> There's an SD card in your Raspberry Pi.

Of course there is... I was referring to transferring the gcode file between Cura and the printer.

> Do you often just cut the power to the Raspberry Pi without shutting down? The OctoPrint log shows you did that at least once (out of 2 times starting OctoPrint).

No. Only if there's an emergency

[Edit] In my DIY Printer everything is tucked underneath the printer (like the Voron) including power Relays. So in case of an Emgergency I can't power off the printer quickly. The only quick way is to pull the plug on the whole system (that includes the Pi)

[fieldOfView]

Powering off the Pi is known to corrupt the filesystem on the sd card of the pi. Try not to do that.

You say this happens about 2 out of 5 times. When it happens, do you immediately remove the file? Does the issue also happen 2 out of 5 times if you leave the damaged file in place? The fs might be using the same (damaged) part of the sd card if you remove the file, thus potentially corrupting the next upload (via Cura) too. I'm just grasping at straws here, because I cannot think of a way this happens during the transfer from Cura to OctoPrint over http.

[fieldOfView]

off-topic:

in case of an Emgergency I can't power off the printer quickly.

Sounds like you need a physical emergency shutdown button that shuts down power to the printer, but keeps the Pi running.

on-topic:

I have looked over your logs, but neither of the logs has any evidence of something being uploaded with Cura. Could you reproduce the issue, and then upload new logs?

[kanawati975]

Powering off the Pi is known to corrupt the filesystem on the sd card of the pi. Try not to do that.

You say this happens about 2 out of 5 times. When it happens, do you immediately remove the file? Does the issue also happen 2 out of 5 times if you leave the damaged file in place? The fs might be using the same (damaged) part of the sd card if you remove the file, thus potentially corrupting the next upload (via Cura) too. I'm just grasping at straws here, because I cannot think of a way this happens during the transfer from Cura to OctoPrint over http.

AAH Okay... Now I'm starting to understand what you're thinking. Would it help if I run some sort of "Disk Scanner"? Or simply format it and write another OS on it?

Well... at the beginning it didn't occur to me that the gcode file is corrupted so I thought it might be a power issue or maybe a Cura Bug since I'm running the Beta Version. Repeating (rather Re-Printing) the same file will cause the same error, in the same place. 3 out of 5 time deleting the file and pressing "Send to Octoprint" again on cura solves the issue. 2 out of 5 times the Error happen again but I didn't pay attention if it's happening in the exact same place (at a certain number) or after a specific period of time.

Thank you for taking the time to investigate

[kanawati975]

> Sounds like you need a physical emergency shutdown button that shuts down power to the printer, but keeps the Pi running.

Yes sir I planned to install a big E-Stop button... Then it dawned on me that pressing reset of the LCD will do the trick without powering anything off. I don't know why I didn't think of it before.

> I have looked over your logs, but neither of the logs has any evidence of something being uploaded with Cura. Could you reproduce the issue, and then upload new logs?

Of course! Please accept my apologies in advance because this requires some time.

[fieldOfView]

Would it help if I run some sort of "Disk Scanner"? Or simply format it and write another OS on it?

If you have one, it would be great if you could test with a new installation of OctoPrint on another SD card. If it reproduces on another SD card, we can be sure it is not the filesystem on the original SD card, and that the SD card is not broken. A power-related issue on the SD card may actually affect an SD-card beyond the filesystem (ie: some parts of the original SD card could - theoretically - be broken permanently).

Of course! Please accept my apologies in advance

No worries. In a case like this it always seems as if I do everything in my might to place the blame elsewhere. Thanks for being open to the possibility that it might not be Cura or my plugin (and - by extension - I don't think OctoPrint is to blame either).

The type of corruption looks like a single bit gets flipped, or goes missing or something like that. This is extremely unlikely to happen in Cura (unless your system is having very specific RAM issues). During transfer, there are checksums in the HTTP protocol (way above the level of involvement of my code), which would certainly catch such an error. And OctoPrint just hands what it received over to the filesystem. Out of these things, only the raspberry pi sd card filesystem has a known and none-too-rarely-occurring mechanism of failure that is known to cause corruption like this.

But I might still be wrong, and perhaps the plugin is somehow to blame. I am open to that as well, but my bet is on the filesystem and/or sd-card. So if at all possible, test with a fresh filesystem, or better yet a fresh sd-card.

[kanawati975]

Currently I'm printing multiple parts for an upgrade, so it will be a good chance to test. I'm far from being expert, but my gut is telling me that the file was generated with those errors, and the file was transferred and executed as it supposed to be. xz_blocks.txt Here is the gcode file, just in case you want to see the contents. Now I do remember that this file took a bit more time to be transferred but back then I blamed my PC (old crappy one)

[fieldOfView]

That file has multiple places where the corruption starts and recovers again after a bit. I say your filesystem is messed up.

[kanawati975]

Just a quick update: I had a Verbatim 32GB MicroSD Card laying around... Formatted it and burned OctoPrint on it using Etcher. Also added an endoscopic USB Camera, and everything works flawlessly in the past 3-4 days.

However it worth mentioning that I had access to an Ultimaker S5 and when I sliced some files and transferred them to the S5 using a USB Disk, the problem happened there again. At this point I'm very tempted to format my PC and install everything again.

[fieldOfView]

I'm chalking this up to a messed up filesystem.