Simplify3D User Forum

I just oberseved a bug when using very big STL-Files and then close S3D and reopen it. I'm using the 64 bit Version under Windows 10.
The restored/saved factory file (e.g. https://www.thingiverse.com/thing:2045849)
After closing and opening S3D the Model is broken and the processes are gone: Seems like there is a bug saving the "savedState.factory" when closing, so the max file Size is 65.537 KB Tested it with different STLs > 70 MB
Offset where the file is zero-padded starts at approx 0x02300000-0x02600000

Interestingly when I do the same with S3D 3.11 the savedState.factory seems to be much smaller, but openened the model okay However great update so far


EDIT:
Oh... it seems like this problem goes much further... if I save the factory file (File => Save Factory File as) I get the same problem...

Same issue here. S3D V4 on Win10. Load a model, close S3D, reopen S3D and model is cut. This is not a gfx bug as the sheered model is the same in print preview mode.

Just wanted to chime in here. S3D4 is shredding the STLs on save. The OBJs come in fine and when I save the factory file the thing is toast. So this is a major bug that is rendering S3D4 unusable. All those new features too. Just in case a mod or S3D4 staff is reading the Mesh comes in with missing faces. I'm not sure if this is because of ZBrush's decimation algorithm but it wasn't happening in S3D3 so something got broken. It may have something to do with the new mesh fixing features, but hey I didn't write the software so I don't know. s3D some help would be awesome.

Here's the pics.
https://drive.google.com/open?id=0B75LK ... VB5UG4xUlU
https://drive.google.com/open?id=0B75LK ... XJXOTBRS1E
https://drive.google.com/open?id=0B75LK ... 19SVWZFQXM
https://drive.google.com/open?id=0B75LK ... Gdaem9BUjg


I too searched and just found teamcarlisle's thread. If maybe a mod could merge these threads that might help everyone. I'm sure that the S3D crew will work on this problem quickly. Until then I found that if one wants to use the new features in ver 4 just create the processes carefully and then export to SD card. That isn't too bad of a workaround.

yeah i'm having exactly the same problem, hopefully it'll be fixed soon

Hello everybody,
there seems to be a general 64MB problem.
Because synonymous G-Code Files are cut off at 64MB.

Best regards
Uli

I just printed the Groot Body.
Interestingly the Gcode-File is exactly 65536 KB. But... If I open the File with an Hex Editor it is really only ~48 MB. So it is not really cutted of but file size information and real file size seems to differ. If I make a groot with 0.1mm layer the file size is about 95MB,so it seems to be possible to go above 64 MB.
But Octoprint thinks it is 64 MB. So after 48 MB the print was done but Octoprint crashed. The file Bodyhighdetail2.gcode is the same model but 120% scaled. Makes no sense the gcode file is exactly the same size...
And if you look in the file you see that the last address is 0x2E15510 => 48321808 Bytes => 48 MB
But explorer say 64 MB... huge, huge Bug in my opinion

In my tests, I have found that if the Gcode file goes above around 30mb, S3D v4.0.0 append null-byte characters to it and pad it all the way to 64mb. While null-bytes should be ignored in most firmware, the volume of them, and the fact that they are all in a single line (most firmware read a single line at a time) can crash the Arduino (compatible Atmel) processors in the printers due to insufficient memory. Since a lot of firmware use a buffer, the printer may not have executed the ending gcode at the time the firmware tries to read this null-byte filled line, and thus when it crash the hot-end may be on the part, melting it at that location.

I upload a print screen of a test file which is 38mb in size after the padding was removed. This print screen is of it open in Notepad++, which is able to display characters with a unicode of less than 32. These are control characters, and the null-byte is the first of them (displayed as NULL on a black background to visually separate it from a possible string "NULL" that may be found in a text file). As can be seen, there is a very large portion of the file containing these null-bytes (it goes to the end of the file).

As I mentioned earlier, I have had success when removing the padding, and this is done by:

1. Open the gcode file in a text editor, like Notepad (the more basic, the better -> Notepad++ may struggle due to the size of the file)
2. Search for a unique command that exists only in your ending script (for example I searched for M84, which shuts down the motors)
3. Go to the start of the first blank line you can find, place your cursor there (on the line after Material Cost)
4. Now, without moving your cursor, move the scrollbar to the end of the file (scrolling so far, even with the Page Down keys, will take a longtime)
5. Shift + Click at the end of the file, to select everything from where you placed the cursor, and Backspace or Delete everything selected. Your file should now end right after the Material Cost.
6. Save the file.

I have successfully printed such a cleaned file, and it leaves no additional artifacts or unwanted behavior.

While it is possible to write a script that will open the file and strip these null-bytes from it, and then save it again, ultimately this is a bug (unintentional behavior) that should be fixed soon. In the mean time, the above workaround should allow you to print files larger than whatever that limit may be (all I know is somewhere above 30mb always gives this issue).

I have not attempted to clean anything where the gcode was larger than 64mb (I have not had to slice something like that), but open it in a Notepad and see if there are issues.

I did a quick test myself now, and chose a model that would generate a very large g-code file.

The g-code file ended up at 163 MB, but as Jacotheron says, it is padded with a lot of null bytes. In fact, after removing those, the file is reduced to 133 MB, so there was around 30 MB of junk null bytes added.

Fixing this should really be a priority (and probably also an easy fix for the developers), even though it is possible to clean up the files manually. However, I'd recommend using a hex editor, not a text editor.

I am happy to say that this issue has now been resolved in Version 4.0.1. Loading large STL files or opening large factory files no longer shows the issue in the screenshots above.

You can see other changes in this version at the link below:
https://www.simplify3d.com/software/release-notes/

To download the new version, just login to your account on the Simplify3D website and proceed to the Downloads page.

Thank you to everyone who reported the issue!