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:
- 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)
- Search for a unique command that exists only in your ending script (for example I searched for M84, which shuts down the motors)
- Go to the start of the first blank line you can find, place your cursor there (on the line after Material Cost)
- 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)
- 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.
- 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.
