search

Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.1k stars 2.06k forks source link

Invalid character (null byte) within the GCode #5450

Closed ForsakenNGS closed 5 years ago

ForsakenNGS commented 5 years ago

Application Version Cura 3.6.0

Platform Latest Arch-Linux (Linux forsaken-linux 5.0.0-arch1-1-ARCH #1 SMP PREEMPT)

Printer Slightly modified Creality Ender-3 (Running the latest Marlin 2.x Firmware + Filament Runout detection on PIN 29, everything else is Stock)

Steps to Reproduce What I did:

I could unfortunally not reproduce the issue by slicing the model again via remote session to my pc (with possibly slightly different settings regarding supports). I will try to slice it again using the exact same Settings in a few hours and append the results to the issue.

Thingyverse Model used: https://www.thingiverse.com/thing:1693359/files (File "DiabloLegs.stl")

Actual Results Invalid GCode which contains a null byte ("\x00") where a space should be.

Expected results Valid GCode with a space where the null byte ("\x00") is.

Relevant files/uploads curaLog01.zip gcode01.zip

Additional Information The attached GCode (gcode01.zip) was downloaded from OctoPrint after using the "Send to OctoPrint" Feature. The attached Log (curaLog01.zip) is from that slicing/sending. The error message from the Marlin firmware that pointed me to this issue was:

Send: N397969 G1 X143.457 Y81.538\x00E3219.50385*124 Recv: Error:No Checksum with line number, Last Line: 397968

The GCode containing the issue was sent directly to an OctoPrint instance from Cura, which may be part of the issue.

In a few hours I will add further Information by investigating the issue for the exact project/settings that resulted in this issue. I still should have cura running with everything on my PC, which I can't access right now. Any tips on how to best approach that reproduction without "accidentially fixing" the issue by reslicing the model are welcome!

If there is anything else missing, I will provide it as fast as possible when requested.

ForsakenNGS commented 5 years ago

PS: Even the issue originated from Cura, I will most likely create/update issues on both OctoPrint and Marlin to prevent the aftermath of this. In my case this resulted in my printer heating the extruder for hours without extruding any filament (overnight print), because it neither was able to continue the print nor aborted it.

rburema commented 5 years ago

I couldn't reproduce this on either master or 3.6, but I have a very different system (Win).

Looking at the file, I'll say that it's a really weird place for a NULL byte, the (Engine) code litterally prints a space there: https://github.com/Ultimaker/CuraEngine/blob/34b89fe5451fe3365879b8505686de10b21c8c73/src/gcodeExport.cpp#L793 (note that the code is the same for Griffin and Marlin flavours here).

I know I should be very careful with such questions/'aquisitions', but could it be a hardware failure? (The disk for instance.)

ForsakenNGS commented 5 years ago

I know I should be very careful with such questions/'aquisitions', but could it be a hardware failure? (The disk for instance.)

Since it was positioned exactly at the position a space was supposed to be, it seemed quite unlikely to me. But looking at the source it really doesn't look like there's much room for error.

So in my opinion the problem was introduced either when transfering the gcode to the OctoPrint server (could be both on sending side/Cura or the receiving side/OctoPrint) or really a hardware issue when storing/reading it on/from the sdcard.

I will investigate it further in about 1-2 hours and report back what I have found out.

ForsakenNGS commented 5 years ago

So, I just sent the same printjob to OctoPrint in my still opened Cura (without slicing the model again) and after downloading there does not seem to be an issue. I assume it really just was an issue with the sdcard (despite I didnt found any warnings or other signs of failure in the systemlog of my OctoPrint server). Since a space (ascii 32) and an null byte (ascii 0) is only one bit difference, I guess that one bit flipped on my sdcard which produced the problem.

Like mentioned before I will investigate if there's an easy way to reduce the risk that comes with such an error (most likely improving marlins behavior when encountering invalid gcode would be the best and easiest approach).

Since that has nothing to do with Cura this issue is resolved. Thanks for the assistance!

rburema commented 5 years ago

Maybe we could put a comment in with a checksum for the rest of the file. That would be a new feature though, so I've no idea if it gets accepted if i propose it or even if so how long it'll take to get through the pipeline :-)

Ghostkeeper commented 5 years ago

Yeah and then the firmware would have to check that checksum too...

ForsakenNGS commented 5 years ago

Small update, the issue still presists after a complete swap of the Hardware (including the sdcard) so it its highly unlikely this is the cause. Since this time it happened with Slic3r PE it also definitly is not an issue with Cura. I have made an issue within the octorprint project since this seems to be the point of failure: https://github.com/foosel/OctoPrint/issues/3099

Ghostkeeper commented 5 years ago

Could be a fault on the computer's side though, unless you included that in your complete swap. Or even in the keyboard-chair interface, if you know what I mean.