Trying to understand slightly off work position

X-Carve Troubleshooting
1

I’m trying to understand work and machine position and why I see small reported offsets from directed position.
I followed the following sequence which raised some questions.

  1. home machine
  2. Power off
  3. Home machine
  4. Work position now (0,0,0), machine position (-788.988, -788.988, -1)
  5. Move +600,+600
  6. Work position now reported as (599.995, 599.995, 0)
  7. Move -600,-600
  8. Work position now reported as (0,0,0)

In step 4 I was surprised that the machine position wasn’t (0,0,0) since the machine powered on in that same spot and was homed. What resets the machine position? Does it have anything to do with me setting soft limits on?

In step 6 I told the machine to move +600X and +600Y and then the resulting position was reported back as 599.995 on each. I’m guessing that this has something to do with my steps/mm and the stepper motor resolution that exactly 600mm was impossible. If so is this little bit of error retained, or is it taken into account for the next move operation? I would imagine if this is not compensated for it would accumulate enough to notice during a long carve. Anyone know for sure?

2

What Gcode sender are you using? UGS? Which “Work Coordinate System” are you in (Workspace)? G54 is where mine defaults to on startup. My limit switch homing (Machine Zero) is not the same as my Work position Zero.

3

Will have to check the settings on my X-Controller tomorrow (but the only ones I’ve changed from default are steps/mm and enable soft limits), but I just found this on the grbl wiki for the changes in 0.9:

Updated Homing Routine: Sets workspace volume in all
negative space regardless of limit switch position. Common on pro CNCs.
But, the behavior may be changed by a compile-time option though. Now
tied directly into the main planner and stepper modules to reduce flash
space and allow maximum speeds during seeking.

So this sounds like when the homing cycle is run the machine coordinates are set to the negative of the max travel settings which would solve this part of my question.

I’m still interested in the reason for the work position being reported off by 0.005 in the example I gave and whether I was correct or not.

4

The compile time option is set correctly in the Inventables fork of grbl, so you don’t have negative Machine Space co-ordinates after running the homing cycle (version 0.9j).

I think the X-controller is running the edge fork (maybe 1.0?) and I don’t know if Inventables has a fork off that work space.

Don’t know what you are trying to do here. Once you power off you have lost position. When you power on and do the homing cycle you should regain hardware/software sync of the home position and that should be Machine Zero 0,0,0. At this point your Work Zero is undefined. If you push the Reset Zero button in UGCS, or enter the G-code command G10 L20 P1 X0 Y0 Z0 then you will have established Work Zero as the same position as Machine Zero.

If you want Work Zero to be 600,600,0 then enter G10 L20 P1 X600 Y600 Z0

Or in UGCS you can jog to X600, Y600, Z0 and press the Reset Zero button.

5

I was just eliminating all possibility that any maintained state was affecting my results. I homed once to move the head to 0,0 then powered off so that there was no knowledge of any movement so that when I did the second home nothing would happen.

What I’m really trying to understand is why when I start from a position of (0,0) and tell the machine to move exactly +x 600mm it reports its position as (599.995,0) not (600,0) and whether this error will grow over a carve job. Note that this is not a physical position error, it’s what the controller reports logically. My guess is that it’s related to rounding issues with steps/mm, but I’m trying to get solid confirmation of this and that it’s compensated for.

6

I’ll see if I can take a look at this. Maybe this coming weekend.

7

Don’t know what values were compiled in yet, but here’s my config:
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=1 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$30=0. (rpm max)
$31=0. (rpm min)
$100=39.867 (x, step/mm)
$101=39.867 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

8

From the Inventables fork of the grbl source code for version 0.9:

// After homing, Grbl will set by default the entire machine space into negative space, as is typical
// for professional CNC machines, regardless of where the limit switches are located. Uncomment this
// define to force Grbl to always set the machine origin at the homed location despite switch orientation.
// #define HOMING_FORCE_SET_ORIGIN // Uncomment to enable.

So from my reading of this ALL users of X-Carve with or without the X-Controller would be seeing the negative machine coordinates IF they have homing enabled. The only people who would not see this behavior have firmware older than 0.9 or don’t have homing enabled, or changed config.h and compiled from source.

9

Got around to doing some math.

600mm * 39.867 steps/mm = 23920.2 steps
But, if we take the integer of the steps (assume no micro-stepping), then
23920 / 39.867 = 599.99498…
This supports my unconfirmed theory that grbl knows when it can’t exactly match a move command and reports the actual position (see my original post that the X position after the move was reported to be 599.995 when I expected 600). So the question remains whether grbl needs to take this into account for future moves.

Anyone know?

10

Actually, no. I downloaded the source back in July and the #define was enabled in that version (0.9j).

If you just downloaded the source and it is commented out, then somebody has been in there mucking around.

The #define should be uncommented to use the feature.

11

@SungeunJeon

Can you comment on this? Would save us some time.

Thanks…
Larry

12

Sure thing. So the handling of integer-float and float-integer conversions can be tricky. You have to ensure that when a conversion occurs, it will be guaranteed not to round-off and numerically drift.

When Grbl receives a motion command (floating point), it will then directly convert that value in millimeters (inches also to mm) to a number of steps integer value. All motions, position tracking, and internal planning is done based on these steps. When a planner calculation requires floating point, it’ll convert the steps distance to millimeters to maintain true physical location, rather than programmed.

So, when you see Grbl’s machine position as not exact, it’s because of the step integer and position floating point values difference. And don’t worry. Grbl tracks all positions accurately to within +/- half a step in any direction.

1 Like