I just ran the Circle Diamond Square Test linked and the Z was either cutting too deep or too shallow.

I've run all sorts of tests using Makercam and Inkscape, running the code through OpenScam (and UGS's visualizer), and everything looks good. So I still assume the issue is how GRBL is interpreting the commands.
here are my current GRBL setting:
**** Connected to COM3 @ 115200 baud ****
Grbl 0.9b (20131210) ['$' for help]
>>> $$
$0=53.000 (x, step/mm)
$1=53.000 (y, step/mm)
$2=675.000 (z, step/mm)
$3=500.000 (x max rate, mm/min)
$4=500.000 (y max rate, mm/min)
$5=200.000 (z max rate, mm/min)
$6=50.000 (x accel, mm/sec^2)
$7=50.000 (y accel, mm/sec^2)
$8=50.000 (z accel, mm/sec^2)
$9=225.000 (x max travel, mm)
$10=125.000 (y max travel, mm)
$11=170.000 (z max travel, mm)
$12=10 (step pulse, usec)
$13=500.000 (default feed, mm/min)
$14=192 (step port invert mask, int:11000000)
$15=25 (step idle delay, msec)
$16=0.020 (junction deviation, mm)
$17=0.005 (arc tolerance, mm)
$18=3 (n-decimals, int)
$19=0 (report inches, bool)
$20=1 (auto start, bool)
$21=0 (invert step enable, bool)
$22=0 (soft limits, bool)
$23=0 (hard limits, bool)
$24=0 (homing cycle, bool)
$25=0 (homing dir invert mask, int:00000000)
$26=50.000 (homing feed, mm/min)
$27=500.000 (homing seek, mm/min)
$28=250 (homing debounce, msec)
$29=1.000 (homing pull-off, mm)
Any ideas?