Complex part, G-code memory limit?

Hello! I'm thinking of building a rep-rap and I have the following doubt:
If I have a large and complex part, would it be possible to generate such a long G-code that it wouldn't fit on rep-rap's electronics memory?

Thanks for reading. Best regards.

It's theoretically possible. If you're printing from an SD card, you're obviously limited by the size of the memory card. If you print from a PC (like most of us still do) you have all the memory resources of the PC. Then you're only limited by the PC's ability to handle a large text file (how G codes are stored).

I think you will be constrained more by the time spent processing such a large file more so than running out of memory.

What have you got? People have printed alligator skulls, which I imagine require a lot of code. Are you playing with fractals?

As the Gcode is sent to the reprap as it prints its the sending devices limit. Processing might take a long time though.

I doubt if you would be able to use up the memory of a PC with anything practical to print. Or even the memory of an SD card.

But if you can I would be interested to see a picture of it.

---

Make your Mendel twice as accurate.
[www.thingiverse.com]

The largest gcode job I ever created was around 400mb, for a large 13 inch by 18 inch sign on a cnc milling machine. It involved 2 passes one ruffing and one detailed with mostly rastering and a few parallel cuts. It took 12hrs to create the gcode and that was not for a 3d printer but a cnc mill/router. For 3d the gcode is quite intense because you are building the part from nothing.


There are a few limits to think about. If fat16 the largest space normally available is 2 GB, if using fat32 the largest per file size is 4 GB.

We may have some detailed jobs in a few years that may approach the size limits, but we will need better tools that we currently have.

The controller in the reprap/CNC machine doesn't care how big the file is, just what the next move is; they generally have a very small buffer, which is filled serially by the controlling computer. It is possible for the controlling computer to run out of space for a particularly complex gcode, but the current OSs have much greater file size limits than fat32 mentioned by james above. You are more likely going to be limited by processing power/time to create the gcode, but even then it'll be when 3D printer platforms are much larger in size, and software that uses good parallelism (like Skeinforge doesn't at the moment!) to take advantage of multiple processors will surmount most processing problems related to time taken to render. Even then, with massive gcode files, gcode is a text format, and so very compressible. I suspect by that point gcode will have been supplanted by a more convenient format, or dedicated hardware controllers that you just upload your STL/CAD file to.

Thinking about what might come, is gcode still practical?

As far I know it was created as direct user language for the terminals of a dedicated cnc machine, not as intermittent data format as we are using it now.
Especially using a (!) string representation of floating point numbers is particularity ineffective.

Even more so g-code isn't exactly portable the way we are using it, we are using various tweaks specifically for our machines which makes it not feasible to use it as a exchange format.

I'm totally new and haven't built anything yet, so please correct me if I am wrong...

Is the reprap not capable of drip feeding code?

Drip feeding is generally done with a DNC (digital numerical control) and makes it possible to run extremely large files on a CNC machine. I've used a DNC at work to drip huge programs into a machine that only accepts a 5.25" floppy. Given the upgraded modem on that machine runs 4400 baud, it still ran more than fast enough, as another poster said, it is only a text file.

EDIT: you can also use N codes in your files, and in cases I am familiar with continue the code, or simply break it apart into multiple texts.

Edited 1 time(s). Last edit at 07/16/2011 05:28PM by Sluark.

I don't know how Skeinforge handles the file while slicing (in-memory, or to temp file), but I'm pretty sure that RepSnapper holds the G-Code in memory, so the limiting factor is the total amount of memory available to the application during printing.

If Skeinforge is building the file in-memory, and only writing to disk when the file is converted, then there will be a similar limitation there (I believe this is the case).

The tradeoff in both cases is speed. Skeinforge builds the G-Code file by first creating a sparse framework representing the shape, and then adds details through repetitive parsing and modification, until the tool path is completed. RepSnapper needs the lines of G-Code to be ready to send to the RepRap electronics without pause, and so the file needs to be pre-loaded. At least enough of the upcoming lines so that the transfer never outruns the load from disk.