Beyond G-code??

I've just got a Diamond hotend, so I'm starting to think ahead to multi-colour printing. I think that 2- and 3-colour printing is pretty well figured out, but what I'm talking about is multi-colour printing... mixing Cyan, Magenta, Yellow in different ratios whilst printing, to produce continuous gradients of colour (e.g. the colour might fade from red to green across the face of an object). I don't think this is going to be feasible with G-code because you would need to specify each individual colour separately.

So I got to thinking a bit more, and it seems to me that any object is completely specified by the ordered sequence of steps of the X,Y,Z axes and the extruder motor(s). The actual speed of these steps is irrelevant to the object being created, but is dependent on the printer itself.... stepper power, carriage weight, etc.


For example, assuming 2 extruder steps for each X step, a single-colour line in the X axis would be formed by
(+ represents positive step, - represents negative step, . represents no step)

XYZE
...+
+..+
...+
+..+
...+

A line at 30 degrees to the X axis fading from Cyan to Magenta would be formed by

XYZCM
...+.
+..+.
.+..+
+..+.
....+
++..+

The above examples, repeated in a more compact notation (capital letters for positive steps, lowercase for negative)...

EXEEXEE

CXCYMXCMXYM

So what about sending a relatively simple code like this to a 3D printer? My grunty (4x3GHz multi-threaded CPUs) desktop PC would do the heavy lifting of calculating the step sequence. The printer itself would do very little calculation... just calculate accelerations for the axes and extruders, and then fire out pulses to the appropriate stepper(s) at the right times, and maintain temperatures of nozzle and bed. I accept that the file itself would be enormous... however, that could be mitigated by compression,

The printer would read the file and plan the times for each of these steps, such that no motor exceeds its maximum speed and no motor accelerates or decelerates too fast.

Any thoughts? Better ideas?

Frank

There is already a way of specifying colour mixing in gcode, which is implemented in RepRapFirmware. A command such as G1 X10 Y20 E1.2:3.4:5.6 means extrude 1.2mm through the first extruder of the currently selected tool, 3.4mm through the second extruder, and so on. But I don't know of any slicers that generate this format yet, or that implement any other form of colour mixing.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I didn't know that. But I think that the G-code gets in the way, rather than helping. For example, if you're wanting to continuously change the colour along an extrusion path, this would get really unwieldy... you would essentially reduce your extrusion path to a series of voxels, each a slightly different colour.

I think the file size would be a major problem. I thi k the file size wouod be a problem. Transferring gcode files from a PC doing the slicing to the printer already takes too long. If you move the step pulse generation to a PC, then you also need to move such things as delta motion computation and auto bed compensation. You are also restricted to Bresenham style irregular step pulse generation, rather than the smoother motion generated by modern 32 bit firmwares. Processor power is very cheap, so it is entirely possible to do quite complex things in the printer firmware.

I take your point about the current gcode not being able to do a linear fade. Perhaps a better way would be for E to specify the total filament extruded and to have other parameters to specify the mixing ratio at the start and/or end of the move.

Rather than switch from gcode to an even lower level representation as you suggest, I would prefer a type of gcode that is less dependent on the machine details

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for those comments.

Hmmm... I hadn't thought of auto bed-leveling. I guess that could still be done if the printer sent the measured height of the bed at the three points back to the calculating machine. The whole step sequence is in effect one huge delta motion.... maybe the concept would need to be extended to include some absolute commands like "Home", "Stop", etc.

I guess what I'm saying though that there will be several representations of an object between the design and the fabrication. Some of these (AMF, STL, GCode) are visible. The last representation prior to fabrication is as a series of stepper motor steps. Currently, this representation is generated on the fly from Gcode by the printer firmware, so only the part currently being executed actually exists at any one time. What I'm suggesting is that exposing this representation to other software would allow bypassing the Gcode step and the limitations inherent in it.

I haven't thought things entirely through, but I believe that the printer would be able to start printing before receiving the entire file, although perhaps slower than ideal. The more lookahead the printer has, the better it knows at what point any of the motors needs to be stopped, and therefore when it must start decelerating it, and therefore what it's speed can be at any point in time. Transmission of the file to the printer would be much faster than the printer could physically print. So I envisage that the file could be sent concurrent with printing, as a TCP stream or similar. OTOH, Shannon's theorem says (more or less) that the minimum compressed size of a file is proportional to its information content. So (in theory) compressing a Gcode file or a stepper-pulse file should result in a file about the same size, so you should be able to transmit it in the same amount of time. This compressed file could be decompressed on the fly by the printer as it prints.

I don't understand your comment about "restricted to Bresenham irregular step pulse generation...". Ultimately there will be an ideal sequence of steps (or microsteps) to produce a particular nozzle path... whether it is calculated inside the printer or outside doesn't matter. Assuming the external program has the same information as the printer firmware, it should be able to calculate exactly the same path. Or even a better path, since there's more clock cycles and bus width and memory available.

I do agree that CPU power is cheap... I have 4 64-bit 3GHz CPUs which sit idle almost all the time. However, its about using devices appropriately. There is a certain amount of computation required to to turn a .STL or .AMF file into a solid object, and I guess I'm suggesting moving more of that to the desktop. If it's sensible for the slicing to be done by these brutes rather than the printer CPU, it seems to me to be a good idea to use the desktop to generate the step sequence too, and pass a stream of data to a lightly loaded printer CPU.Each processor does what it's good at... desktop for heavy duty calculation, printer for managing the real-time aspects of printing. It's also much easier to add features to a desktop system than an embedded system.

I'm not excluding some kind of super-Gcode as a file format; just proposing a more direct path to the printer hardware from software on my desktop.

Frank

Edited 1 time(s). Last edit at 07/07/2015 09:22PM by frankvdh.

Lots of commercial CNC machines do this already simply using G code. You can also 'stream' programs, though it has drawbacks.

Off the top of my head, I think it was Okuma uses 10 line look ahead while machining 6-axis @ several hundred ipm with .0002" repeatability. A big part of that performance is firmware/machine params that limit how fast/which axis or drive can move/accelerate/deccelerate and will cap that motion if it is programmed poorly. So the tool arrives at 'exactly' the place it needs to be when it needs to be there before motion is completed/continued. Which is what reprap firmware can do or already does.

If anything I've noticed about improvements to interpolation but that's firmware its the current FFF style specifies lines
xy
xy
xy... etc -lumpy circles
where 'normal' G-code can specify other arguments for other functions as well as arcs and the firmware will interpolate to actually create that arc. I think it would also greatly reduce the file size since you are specifying an arc, instead of the many lines of x,y moves required to make a shape similar to an arc. though it may be as much of an issue as the initial file type being as crude as it is.