So I have a model that weighs in at about 412MB and the Controller is choking on it and rebooting. Would it work if I just chopped the g-code file into multiple pieces and printed them one after/on-top-of another?
Logically, there’s no reason why there should be a file size limit at all… when you’re executing g-code it doesn’t care what came before or what comes next, it just executes the command from wherever the print head happens to be. It should be possible to just stream the file directly into the controller a line at a time.
-Chris
That should work, though I would keep a close eye on it when doing the transition. I would also recommend starting the next file immediately so that the nozzle doesn’t cook the filament for too long. Also, if you do this separate the gcode itself, rather than slicing multiple times and do a test first to make sure you don’t have to add any temperature commands.
I would ask though why not print it in two parts and glue them together instead? Printing onto another print comes with an increased risk of failure, and with a large model like that printing then gluing might make more sense.
The reason there is the apparent size limit is that the touchscreen parses through the gcode file and stores it in temporary memory, then sends commands to the printer as necessary. The touchscreen has a limited about of space and processing power though, so it can fail with large file sizes.
1 Like
With regard to printing in two parts, do you know of an easy way to slice an STL file? I suppose I could just work my way through the g-code and pick a place to split and tack on the ending g-code and preface the remaining g-code with the startup stuff.
With regard to the size limit, it just seems to me that it wasn’t a good design decision. There’s no intrinsic reason why the touchscreen needs to hold all the data, if it needs to parse all the data to compute time estimates or validate the data that’s fine but it doesn’t need to hold onto all the data at once. It’s not like the lag-time from loading a line of g-code data from the system memory or USB stick to the touch screen is going to be significant relative to the amount of time it takes the printer to execute it. You could buffer up a bunch of lines and run that way if it’s any concern at all.
just a thought…
You can use a mesh editor like meshmixer to cut it. See below for an example video.
As for the design, I completely agree. Parsing can be useful for time estimation and being able to change things like printing temperatures without reslicing, but their implementation continues to cause problems. Another great example for this is how recent updates broke running a laser job over serial with them claiming it’s for “safety”.
1 Like
