How accurate is the GF suppose to be?


I am making some test cuts for kerf in 6mm hardboard on the GF basic, (140 speed at full power) and I am finding that my 20mm squares and circles are consistently .06 mm wider on the x axis. That is .0023 inches for those who prefer visualizing in imperial. So does this just fall within normal tolerance or is there something I can do to calibrate?
I have the same issue with proofgrade btw, it is the consistency of the error that makes me think something could be off.

Thanks in advance for all your great answers!


Mine is off by a similar amount, I think. (I can’t remember the exact amount; it’s been four or five months since I measured.)


I found the same issue.

There are currently no user adjustments in the factory software that allow for the adjustment of the unit’s calibration.

There is a comprehensive calibration process done at the factory, and that data is stored on GF servers. The idea is that any corrections for variations between units is handled by the cloud software.

I don’t believe, however, that this is actually a calibration issue…

Since this seems to be a common observation, it leads me to think there may be an issue in the cloud processing, and not the individual units.


Looking at a puls file squares look square to me, so my guess would be the Y axis having more backlash than X.

A good test is to engrave this shape and measure the inside lengths. They are independent of backlash and kerf and should be 100mm.



Squashed that theory… :slight_smile:

Are they the exact same number of steps in both axes?


Well on my array of 36 squares the first one has equal sides but the second one has an out by one error in X so it doesn’t get back to where it started. I.e. the top side is the correct length but the bottom side is one step shorter so meets first corner one step in.

I had noticed before the array was skewed. That is probably the reason. One step is only 0.01875mm though.

I need to write a program to find all the vertices to see all the errors as it is a bit tedious looking by hand.


Can you post your SVG?


Nothing fancy, just a some quick shape so I can measure kerf.


It would be very interesting if @Dan would provide information concerning the calibration process at the factory and how that calibration can be controlled by software in the Cloud to address this issue.


  1. Does each machine have an individual calibration profile?
  2. Can each machine be controlled by “Command Central” to correct a specific user’s machine accuracy?

In most CNC software, you can calibrate each axis to compensate for small manufacturing variations that affect accuracy. Attached is a photo of a calibration screen in Mach3, a commonly used CNC control software, as an example.

Of course, one of the reasons we purchased a GlowForge is ease of use. Having to learn and spend a lot of time calibrating, or making measurements to feed back to “Command Central” is probably not what most GF users want to spend their time doing.

The question about expected accuracy is an important one though.


The only differences between machines that would affect dimensions would be the belt pitch accuracy when tensioned correctly. However the motor torque seems pretty low, so I wouldn’t be surprised to see backlash on the Y axis.


I was more interested in the decimal places of the file.


As long as my .06mm isn’t cumulative, or an error introduced on import, I could just scale up the Y in the file to compensate. I will have to test on a larger shape. I know its splitting hairs when the kerf is wider on one side anyway, but I want to make some tiny spur gears and have them efficient as possible.


A very creative solution!


Ah, makes sense. I set it to 3, would 4 help?


Don’t forget pulley size variation too!


Only one way to tell? :slight_smile:

Maybe? Positioning precision to 0.001” (0.025mm) is what’s listed on the tech specs page.

Interestingly, if I save out your file to 5 decimal points, it shows that it’s actually not square. It shows an X-Y of 56.69301 / 56.69299 (no, we aren’t talking about a bunch AT ALL, but you guys do love your accuracy, right?) :slight_smile:


No that doesn’t make a difference with toothed pulleys. It has to be about right or the belt wont run properly but after one rotation 30 teeth of the belt have passed so 30 times the belt pitch moved.


This is what I found when I told it to score 36 unit squares on a regular grid each a different colour and focus height. These are the coordinates in motor steps of the top left corner of each square and the side lengths. The number in the middle is the order they were done. I.e. down the columns.

This isn’t to scale but it has some very odd distortions. Most sides are 641 steps but the bottom of 7 squares are 640 so they don’t meet at the first corner and everything following that is one step to the left.

Each column starts 4 steps higher than the last. The pitch between columns is 1280 but the pitch between rows is 1281.

This is the original svg file and you can see it is perfectly regular

<?xml version="1.0" ?>
<svg baseProfile="full" height="600px" version="1.1" viewBox="-1.1055 -1.1055 13.211 13.211" width="600px" xmlns="" xmlns:ev="" xmlns:xlink="">
        <path d="M 0.0,0.0 L 1.0,0.0 L 1.0,1.0 L 0.0,1.0 L 0.0,0.0" fill="none" stroke="rgb(100, 100, 0)" stroke-width="0.011"/>
        <path d="M 0.0,2.0 L 1.0,2.0 L 1.0,3.0 L 0.0,3.0 L 0.0,2.0" fill="none" stroke="rgb(100, 101, 0)" stroke-width="0.011"/>
        <path d="M 0.0,4.0 L 1.0,4.0 L 1.0,5.0 L 0.0,5.0 L 0.0,4.0" fill="none" stroke="rgb(100, 102, 0)" stroke-width="0.011"/>
        <path d="M 0.0,6.0 L 1.0,6.0 L 1.0,7.0 L 0.0,7.0 L 0.0,6.0" fill="none" stroke="rgb(100, 103, 0)" stroke-width="0.011"/>
        <path d="M 0.0,8.0 L 1.0,8.0 L 1.0,9.0 L 0.0,9.0 L 0.0,8.0" fill="none" stroke="rgb(100, 104, 0)" stroke-width="0.011"/>
        <path d="M 0.0,10.0 L 1.0,10.0 L 1.0,11.0 L 0.0,11.0 L 0.0,10.0" fill="none" stroke="rgb(100, 105, 0)" stroke-width="0.011"/>
        <path d="M 2.0,0.0 L 3.0,0.0 L 3.0,1.0 L 2.0,1.0 L 2.0,0.0" fill="none" stroke="rgb(101, 100, 0)" stroke-width="0.011"/>
        <path d="M 2.0,2.0 L 3.0,2.0 L 3.0,3.0 L 2.0,3.0 L 2.0,2.0" fill="none" stroke="rgb(101, 101, 0)" stroke-width="0.011"/>
        <path d="M 2.0,4.0 L 3.0,4.0 L 3.0,5.0 L 2.0,5.0 L 2.0,4.0" fill="none" stroke="rgb(101, 102, 0)" stroke-width="0.011"/>
        <path d="M 2.0,6.0 L 3.0,6.0 L 3.0,7.0 L 2.0,7.0 L 2.0,6.0" fill="none" stroke="rgb(101, 103, 0)" stroke-width="0.011"/>
        <path d="M 2.0,8.0 L 3.0,8.0 L 3.0,9.0 L 2.0,9.0 L 2.0,8.0" fill="none" stroke="rgb(101, 104, 0)" stroke-width="0.011"/>
        <path d="M 2.0,10.0 L 3.0,10.0 L 3.0,11.0 L 2.0,11.0 L 2.0,10.0" fill="none" stroke="rgb(101, 105, 0)" stroke-width="0.011"/>
        <path d="M 4.0,0.0 L 5.0,0.0 L 5.0,1.0 L 4.0,1.0 L 4.0,0.0" fill="none" stroke="rgb(102, 100, 0)" stroke-width="0.011"/>
        <path d="M 4.0,2.0 L 5.0,2.0 L 5.0,3.0 L 4.0,3.0 L 4.0,2.0" fill="none" stroke="rgb(102, 101, 0)" stroke-width="0.011"/>
        <path d="M 4.0,4.0 L 5.0,4.0 L 5.0,5.0 L 4.0,5.0 L 4.0,4.0" fill="none" stroke="rgb(102, 102, 0)" stroke-width="0.011"/>
        <path d="M 4.0,6.0 L 5.0,6.0 L 5.0,7.0 L 4.0,7.0 L 4.0,6.0" fill="none" stroke="rgb(102, 103, 0)" stroke-width="0.011"/>
        <path d="M 4.0,8.0 L 5.0,8.0 L 5.0,9.0 L 4.0,9.0 L 4.0,8.0" fill="none" stroke="rgb(102, 104, 0)" stroke-width="0.011"/>
        <path d="M 4.0,10.0 L 5.0,10.0 L 5.0,11.0 L 4.0,11.0 L 4.0,10.0" fill="none" stroke="rgb(102, 105, 0)" stroke-width="0.011"/>
        <path d="M 6.0,0.0 L 7.0,0.0 L 7.0,1.0 L 6.0,1.0 L 6.0,0.0" fill="none" stroke="rgb(103, 100, 0)" stroke-width="0.011"/>
        <path d="M 6.0,2.0 L 7.0,2.0 L 7.0,3.0 L 6.0,3.0 L 6.0,2.0" fill="none" stroke="rgb(103, 101, 0)" stroke-width="0.011"/>
        <path d="M 6.0,4.0 L 7.0,4.0 L 7.0,5.0 L 6.0,5.0 L 6.0,4.0" fill="none" stroke="rgb(103, 102, 0)" stroke-width="0.011"/>
        <path d="M 6.0,6.0 L 7.0,6.0 L 7.0,7.0 L 6.0,7.0 L 6.0,6.0" fill="none" stroke="rgb(103, 103, 0)" stroke-width="0.011"/>
        <path d="M 6.0,8.0 L 7.0,8.0 L 7.0,9.0 L 6.0,9.0 L 6.0,8.0" fill="none" stroke="rgb(103, 104, 0)" stroke-width="0.011"/>
        <path d="M 6.0,10.0 L 7.0,10.0 L 7.0,11.0 L 6.0,11.0 L 6.0,10.0" fill="none" stroke="rgb(103, 105, 0)" stroke-width="0.011"/>
        <path d="M 8.0,0.0 L 9.0,0.0 L 9.0,1.0 L 8.0,1.0 L 8.0,0.0" fill="none" stroke="rgb(104, 100, 0)" stroke-width="0.011"/>
        <path d="M 8.0,2.0 L 9.0,2.0 L 9.0,3.0 L 8.0,3.0 L 8.0,2.0" fill="none" stroke="rgb(104, 101, 0)" stroke-width="0.011"/>
        <path d="M 8.0,4.0 L 9.0,4.0 L 9.0,5.0 L 8.0,5.0 L 8.0,4.0" fill="none" stroke="rgb(104, 102, 0)" stroke-width="0.011"/>
        <path d="M 8.0,6.0 L 9.0,6.0 L 9.0,7.0 L 8.0,7.0 L 8.0,6.0" fill="none" stroke="rgb(104, 103, 0)" stroke-width="0.011"/>
        <path d="M 8.0,8.0 L 9.0,8.0 L 9.0,9.0 L 8.0,9.0 L 8.0,8.0" fill="none" stroke="rgb(104, 104, 0)" stroke-width="0.011"/>
        <path d="M 8.0,10.0 L 9.0,10.0 L 9.0,11.0 L 8.0,11.0 L 8.0,10.0" fill="none" stroke="rgb(104, 105, 0)" stroke-width="0.011"/>
        <path d="M 10.0,0.0 L 11.0,0.0 L 11.0,1.0 L 10.0,1.0 L 10.0,0.0" fill="none" stroke="rgb(105, 100, 0)" stroke-width="0.011"/>
        <path d="M 10.0,2.0 L 11.0,2.0 L 11.0,3.0 L 10.0,3.0 L 10.0,2.0" fill="none" stroke="rgb(105, 101, 0)" stroke-width="0.011"/>
        <path d="M 10.0,4.0 L 11.0,4.0 L 11.0,5.0 L 10.0,5.0 L 10.0,4.0" fill="none" stroke="rgb(105, 102, 0)" stroke-width="0.011"/>
        <path d="M 10.0,6.0 L 11.0,6.0 L 11.0,7.0 L 10.0,7.0 L 10.0,6.0" fill="none" stroke="rgb(105, 103, 0)" stroke-width="0.011"/>
        <path d="M 10.0,8.0 L 11.0,8.0 L 11.0,9.0 L 10.0,9.0 L 10.0,8.0" fill="none" stroke="rgb(105, 104, 0)" stroke-width="0.011"/>
        <path d="M 10.0,10.0 L 11.0,10.0 L 11.0,11.0 L 10.0,11.0 L 10.0,10.0" fill="none" stroke="rgb(105, 105, 0)" stroke-width="0.011"/>

I have no idea how or why it would produce skewed results like this. Yes conversion to motor steps could produce off by one errors but the last coordinate of each path is the same as the first so should always convert to the same motor position.

If Y was skewed, say to compensate for a skewed gantry then the squares should be rhombuses. Having them still squares on a skewed grid makes no sense to me.


Are you seeing the same pattern if you recreate it and run it multiple times?


I only tried it once back in December. I was mainly investigating the focus range, which is only 0.4". I made a mental note at the time that the coordinates looked odd but only analysed them fully today.

I am less interested now as I am designing my own machine and it certainly won’t do anything like this. The CNC software I have written has deterministic coordinate mapping and preserves geometry to the nearest motor step even when rotating to cope with bed levelling.