The File-to-Factory Paradigm

In the last lesson we drew the file-to-factory chain as five links. Now we open each one. It begins in CAD, where you build the geometry - a solid, a surface, or a 2D profile - carrying design intent: dimensions, relationships, sometimes a full edit history. That model is handed to CAM (computer-aided manufacturing), which is where making decisions enter: you choose a tool, a strategy (pocket, contour, drill), a feed rate and a spindle speed, and CAM computes the toolpath - the exact route the cutting tip or nozzle will travel.

CAM does not yet speak the machine's dialect. A post-processor translates the generic toolpath into the specific flavour of G-code your controller understands - a Haas mill, a GRBL laser and a Prusa printer all read subtly different G-code. That text file of moves goes to the machine controller, the small computer that turns lines like G1 X40 Y20 F800 into coordinated motor pulses. The motors drive the axes, the tool meets the material, and out comes the physical part. Five stages, five programs or files, each a genuine translation. Read any fabrication job as this pipeline and you always know which stage to interrogate when something goes wrong - a bad surface is usually CAM, a machine that refuses the file is usually the post-processor, and a part that is the wrong size is almost always units or origin.

Between the stages sit files, and the format of each file decides what can pass through. The richest are native and neutral solid formats. A native file (.3dm for Rhino, .skp for SketchUp, a parametric part file) keeps everything - solids, surfaces, units, often the construction history. STEP (.step, .stp) is the neutral exchange standard for solids: it hands a watertight solid model between programs without the edit history but with true faces, edges and units intact. This is what you send when the geometry must stay exact and editable downstream.

Below that live the dumb-geometry formats. STL describes a 3D shape as nothing but a mesh of triangles - no curves, no faces, no units guaranteed - which is why it is the workhorse of 3D printing but useless if you later need to edit the design. DXF carries 2D curves and lines, the standard input for laser cutters and 2D CNC, but it is only outlines - it knows nothing of thickness or material. At the very bottom is G-code itself: no geometry remains at all, only a list of coordinated moves for one particular machine. The rule to internalise: information only ever leaves as you move down the pipeline. Choose the highest-fidelity format each stage can accept, and export to the dumb formats as late as possible.

Every hand-off is lossy in a predictable way, and knowing the failure modes lets you catch them before they cost material. The most famous loss happens at STL export: a smooth curve has no triangles, so the exporter approximates it with flat facets. The chord tolerance (sometimes called deviation) sets how far a facet may stray from the true surface - set it too coarse and a printed cylinder comes out visibly faceted; set it too fine and the file balloons to hundreds of megabytes. A typical setting is a deviation of around 0.01-0.05 mm for detailed prints, but the point is that resolution becomes a choice you make, not a property of the geometry.

Other losses are quieter. Exporting to DXF can drop layer names, arc definitions (splitting a smooth arc into many short segments), or the sense of which loops are holes. Moving between programs can silently change units - a model built in millimetres reopened as inches is now 25.4 times too big. Native construction history - the parametric relationships that let you change a dimension and have everything update - is gone the moment you export to any exchange format. None of this is a flaw to be angry about; it is the physics of translation. The maker's job is to know which stage owns which risk and to verify at each boundary rather than trust blindly all the way to a ruined workpiece.

The two least-understood stages are the post-processor and the controller, and both live very close to the metal. A post-processor is a small program, specific to your machine, that converts CAM's neutral toolpath into the exact G-code dialect the controller expects. Dialects really do differ: the code to turn a spindle on, to select a tool, to set an offset, or to dwell varies between a Fanuc controller, a Haas, a GRBL board and a Marlin 3D-printer firmware. Use the wrong post and the machine may ignore a command, crash into a clamp, or simply refuse to run. This is why fablabs are strict about which post you use for which machine - it is not bureaucracy, it is collision avoidance.

The controller is the real-time brain. It reads G-code line by line, plans acceleration so the axes do not lurch, and issues step pulses to the motors, all while watching limit switches and, on a printer, temperatures. G-code is deliberately simple: G0 is a rapid non-cutting move, G1 is a controlled feed move, M3 starts the spindle, M104 sets a hotend temperature. You almost never write it by hand, but reading a few lines demystifies the machine completely - you can see the origin it assumes, the units mode (G20 inch, G21 millimetre), and the feed rate it will hold. When a job behaves strangely, opening the G-code in a viewer is often faster than re-running CAM.

One subtlety worth naming: the controller also holds settings the file does not - the machine's calibration, its work-offset table, backlash compensation and maximum feeds. So the same G-code can behave differently on two machines of the same model if their offsets differ. This is why an experienced maker treats the post-processor and controller as a matched pair, tied to one physical machine, and re-verifies the origin on the bed before every run rather than assuming the last job left it correct.

None of this pipeline detail is trivia - it is why digital fabrication changed how designers think. When the model directly drives the machine, the loop between drawing and holding the real thing shrinks from weeks to hours. You can print a joint, feel that it is too tight, edit one parameter, and re-cut before lunch. That tight feedback loop turns design into an experimental craft again, where you learn from material rather than only from screens.

It also relocates authority. In the old chain, a contractor or craftsperson interpreted your drawings and absorbed the ambiguity; in the file-to-factory chain, whatever is in the file is what gets made, exactly, including your mistakes. That is a gift and a discipline - the designer's control now reaches the finished surface, but so does the designer's responsibility for tolerances, units and clearances. Finally, because the pipeline is data end to end, it composes with computation: a parametric definition can generate a thousand unique files and feed them straight to the machine, which is the technical basis of mass customization. The lesson to carry forward is that the pipeline is the product. Master the hand-offs and you can make almost anything the machines allow; ignore them and the most beautiful model in the world dies quietly at an export dialog.