GC Calibration bug?

Newly set up machine, running through calibration steps–when I get to the test Pattern cuts for fine tuning and go to enter the mm values in the measurement fields I get “The machine was not able to be calibrated. Please ensure the owrk area dimensions are correct and try again”

My input data values were all in the format to include out to thousanths, as in 1111.111
GC would not allow sucessful saving of values (Enter Values) until I removed all decimals and used whole numbers only, as in 1111

Windows 10, GC version and firmware are latest. Am I missing something here? Is this a bug or does someone know of a workaround (like direct edit of .ini file) Image attached

1 Like

Hmm that is interesting. I don’t think I’ve encountered that before, although I’m using v1.25. Can you check under Settings>Maslow Settings and verify you have 4’x8’ for work area in millimeters, like this:

Edit: and to be clear, for the calibration measurements, you tried entering “1900.2”, “1906.5” and “192.0” and it didn’t work either?

1 Like

@CAJones, please upload, or copy/paste the contents of, your ini file here. Perhaps there is something odd, like what you read in the other recent post “GC Calibration bug?” post.

@WoodCutter4 Was there a similar report recently stating that in mm nothing behind the decimal point should be added?
@CAJones No idea, but worth a try i guess.

Kind regards, Gero

I don’t recall but that doesn’t mean there wasn’t. They sort of blend together sometimes :wink:
Edit: after a few short minutes looking at the forum for “decimal” and “mm”, “millimeter”, I only found the issues related to makercam 16 decimal places being output in g-code.

So I retried the page today and it took the calibrations out to the 3rd decimal, so it may have been a runtime issue that was cleared out on the next reboot and fresh launch of application. I need to do some additional calibration passes to be sure but I’ll definitely see if I can recreate the problem and if so capture the .ini at the time. Thanks all that replied


Another case of “the insane arduino”.