I think you know at least some or all of this, but hereâs what my understanding is.
active coordinate: -1: this returns gcode.active_coordinate_system and when -1 means that the workspace_offset is not enabled, and the machine is in native machine coordinate space. This is consistent with the default startup behavior in 3DP mode, using native space. The laser module starts up in workspace 1, G54. 3DP boots into G53. This comment is illuminating:
* System index -1 is used to specify machine-native.
coordinate 1 returns gcode.coordinate_system[0][X_AXIS], etc. for Y and Z. This is the what the workspace coordinate offset would be, as coordinate_system[] is an array that stores each XYZ offset for each workspace offset. In this case the offset is 0.
position_shift: this is returning position_shift[X_AXIS], etc. for Y and Z. position_shift is calculated as the difference between a new and old offset when changing coordinate systems. As native machine space has an offset of 0, and the stored workspace 1 offset in this case is also 0, the difference is 0.
home_offset returns home_offset[X_AXIS], etc., and is related to the M206 home offset. It is used when homing as the known native space coordinates when touching the homing limit switches.
workspace_offset returns workspace_offset[X_AXIS], etc. It is calculated as follows:
workspace_offset[axis] = home_offset[axis] + position_shift[axis]. It is referred to through a macro WORKSPACE_OFFSET(AXIS) which is solely used by NATIVE_TO_LOGICAL and LOGICAL_TO_NATIVE to add or subtract the total offset from the current position. The documentation indicates workspace_offset is precomputed to save on computes.
None of the above are the probe offset referenced in probe_pt when probing relative (the default, and only ever overridden for delta autocalibration). Relative probing subtracts X_PROBE_OFFSET_FROM_EXTRUDER and similar for Y. Those values are the ones defined in configuration.h as X13 Y19.15 Z1.
So far I think everything looks like it should be working as intended.
G42 has a P parameter as follows:
if (parser.boolval('P')) {
if (hasI) destination[X_AXIS] -= X_PROBE_OFFSET_FROM_EXTRUDER;
if (hasJ) destination[Y_AXIS] -= Y_PROBE_OFFSET_FROM_EXTRUDER;
}
This does not show up in any documentation and could be an interesting troubleshooting tool.
This is true for a weird reason: see the following snippet from G30.
const float xpos = parser.linearval('X', current_position[X_AXIS] + X_PROBE_OFFSET_FROM_EXTRUDER),
ypos = parser.linearval('Y', current_position[Y_AXIS] + Y_PROBE_OFFSET_FROM_EXTRUDER);
parser.linearval returns either the parameter value specified (âXâ for example) or the supplied default. So a G30 command with no âXâ parameter will return the current X position + the X probe offset.
The calculated or supplied X and Y position is passed to probe_pt, the same function discussed above. probe_pt, which is called with the relative flag in its default state, then subtracts off the X and Y probe offsets previously added in the G30 method.
Something about this behavior seems off to me, but it matches the current Marlin branchâs behavior so it likely is intended.
For more consistent behavior, itâs likely that G1029 should follow more closely the behavior in probe_pt. I somewhat have run out of time tracing the _GET_MESH_X macro, perhaps thereâs a quirk in there yet to be discovered.