[FIXED] 64MB Gcode Bug

[ich777]

Hello,

i've discovered if i open a big stl model in S3D4 and save the Gcode that the file is 64MB big.
I've also got no problem to print it but when it finishes the print the printer is stuck and doesn't execute the ending script, in my oppinion thats a big problem becase the hotend and the bed stays at the printing temperature and also doesn't turn off the fans.
The big Gcode files also crash my OctoPrint Server (it's running on an Intel i3 and not on an RaspberryPi, anyway same behaviour an the Pi).

Is it a bug or a Feature?

Hope someone can help me out.

I'm Printing with the Creality CR-10 and OctoPrint (latest version).
Example STL is: https://www.thingiverse.com/thing:2014307 (the body File).


Regard, Christoph

[Jacotheron]

I have just ran into this same issue, but have also troubleshooted it a bit. What I can confirm is that it is a bug, no way it can be a feature.

This issue appears when the resulting gcode is more than 30MB in size (my tests are not precise on where it happens, just that it happens after reaching the 30MB limit).

It seems as though all the gcode is in the file, including, at least in the ones I opened, the ending gcode. After the Ending gcode, there are a lot of NULL-byte data in the file (visible with the file open in Notepad++), which is what makes up the remainder of the file. Since Null-byte data is outside of general text, it can crash applications expecting text, or be shown as a whitespace character (like plain old Notepad does, or some software like Notepad++ which actually displays it as being a Null-byte).

When the printer tries to parse this, I believe that it will not know how to handle it, since it is invalid gcode, and can crash prematurely (remember that most firmware process each line and then queues it, so that it can print without delays). If it crash as soon as it reaches these null-bytes, it can miss the ending gcode easily.

How I recovered a file that had these null-bytes appended, was to simply open it in Notepad (or plain text editor of your choice: the more basic, the better) go to the end of the gcode (simply search for something that only exists in your ending gcode), and delete everything that follows (it was displayed as white space, and there were a lot of them) and save the file. Use a basic text editor since the file will use a lot of memory to open, and nice features in the text editor software might slow it down a lot.

While I have not tested the recovered file, I expect it to work (and it is now only half the size in MB).

[paboman]

Same things here, my machine is freezing after long prints onlly when I use Simplify 3D, the gcode has a lot of NUL in the last line. WTF ?!?
Does the last version solve this ?

[wirlybird]

I don't know if this is related or not but when I open any file created by Flashprint in Notepad++ it has a line of "null" as the first line and I never looked at the end.
These may well be valid characters but notepad++ just doesn't know how to display them

My assumption is the nulls are machine level characters that notepad++ doesn't understand.

Do a google search on "notepad++ shows null characters".

[paboman]

in the GCODE file should be ONLY Gcode commands and comments with "; " nothing more otherwise the control board of the machine cant understand it.
This for sure a BUG as all other slicer manage this well, in S3D this bug occur only ehwn the file exceed 32Mb.

deleting the NULL part by hand and re-saving makes the gcode a lot smaller.

[dkightley]

If you guys are adamant that this is a bug, rather than sitting there, thumping the desk and shouting "Its a bug!"....metaphorically, of course .....why don't you bundle up a factory file and the resultant gcode file for a model that is exhibiting this issue and email it to S3D support.

Not only will an example make it easier for them to recreate the problem, it might even persuade them to look at the issue and release a mini-update containing a fix sooner rather than later.

[paboman]

If you guys are adamant that this is a bug, rather than sitting there, thumping the desk and shouting "Its a bug!"....metaphorically, of course .....why don't you bundle up a factory file and the resultant gcode file for a model that is exhibiting this issue and email it to S3D support.

Not only will an example make it easier for them to recreate the problem, it might even persuade them to look at the issue and release a mini-update containing a fix sooner rather than later.

Already done this bro

I saw this is a quite old bug...hope they will work it out.
unfortunately they are slow to fix bugs compared to competitors, we will see....

[paboman]

reply for the support team:

Thanks for your email and the screenshots. We have seen this issue happen only with a few larger file sizes like you mentioned. This issue seems to occur only with 4.0. IF you have an earlier version of the software still installed, you can try to check if this happens with that oen as well. But we are actively working on a fix for this and we hope to have an update soon

[S3D-Jason]

I am happy to say that this issue has now been fixed with Version 4.0.1. I tested the large STL file mentioned at the top of this thread and it now slices and exports correctly. I was able to save several large 100MB+ gcode files without any issues.

Thank you for reporting the issue and for bringing it to our attention!

You can download the new version by logging into your account on the Simplify3D website and going to the Downloads page.