The Othermill Guide to Units of Measurement

Posted by Ezra Spier on Jun 15, 2016 1:42:37 PM
Find me on:

Screen_Shot_2016-06-15_at_1.32.01_PM.pngInches, millimeters, mils — what’s the difference? One of our customers asked for advice on which units to use when designing for the Othermill, so we put together this handy guide to units.

In general, millimeters are the preferred unit for the Othermill. Whichever file format or process is used, we convert non-millimeter units to millimeters as soon as feasibly possible. We do so because tracking which units are used at a given time is much more complicated and error-prone than standardizing to one unit throughout. The precision lost by unit conversion is substantially less than the real mechanical tolerances of the Othermill, so it shouldn't result in increased tool wear or loss of milling precision.

There are a number of subsystems involved in every Othermill job, and each system handles units slightly differently. Working from the Othermill backwards, here’s what happens in each step.

Othermill (TinyG)

The Othermill uses an open-source motion-control board, the TinyG, to convert G-code instructions into motor motion. TinyG's firmware uses millimeters to compute its motion plans. Ultimately, the units are converted into electrical impulses that are converted to motor microsteps. If G20 is present in the G-code file, TinyG will convert the units into millimeters before processing. Although this conversion is reliable, it's an extra step, and we prefer to use G-code in millimeters if possible. We recommend using no more than three decimal places in mm (e.g., 0.001 mm) in the G-code sent to the Othermill.



Otherplan (CAM and G-code Sending)

Otherplan itself has a number of subsystems that come into play depending on what type of file you're using. If you're using a G-code file (say, exported from Fusion 360), Otherplan simply streams the file itself to the Othermill — there's no special pre-processing or error correction beforehand (though we hope to add error simulation in the future). If the G-code file has a G20, then the file will be sent in inches without any conversion.

If you import a .brd, set of Gerbers, or .svg file, Otherplan's CAM module will convert the geometry into G-code that the Othermill can run. Because the G-code created is destined for the Othermill, the CAM module uses metric units no matter the units in the original file.

The CAM module also uses the geometry of the file and the geometry of the selected tool to create the final toolpath. Otherplan's tool library contains imperial units for the tools because these are common for the bulk of our U.S.-based customers. However, the internal tool definitions are stored in metric units. We do plan to offer support for custom tools (metric and imperial) in Otherplan, so stay tuned.

File Imports

File types differ on how they handle units. Here's a brief summary of each:

  • G-code: Can be in inches or millimeters. A G20 must be present if the file is in inches. Inches will be converted to millimeters on the TinyG.
  • BRD files: Generally use millimeters internally.
  • Gerber files: Can be in inches or millimeters. Otherplan will convert to millimeters in the CAM stage.
  • SVG files: Do not have a consistent standard for units. Inkscape exports SVGs with 90 pixels per inch, and Illustrator exports SVGs with 72 pixels per inch. Otherplan assumes 72 ppi, but if it sees Inkscape tags in the SVG, it uses 90 ppi when importing. All units are converted to millimeters for CAM purposes.

We hope this guide was helpful in shedding light on how units of measurement come into play with the Othermill. If you have any questions, please don't hesitate to contact us at We're always happy to help! 

Topics: Design, Tips & Tricks, Support