Z Probe Offset

Garfield

Duet 3, RRF 3 RC2, Core XY.

My Z probe is offset from the nozzle tip X21 Y0 (the probe is to the left of the nozzle when viewed from the front).

When commanding the system to probe the bed G28 or G32 the X axis does not move to a position where the probe is going to function - if allowed to continue a probe operation it would crash the nozzle for sure as there is nothing under the probe that it can sense.

In order for the probe to detect the bed the X axis MUST move a minimum of +21mm before attempting to probe. I thought the offset was supposed to take care of this ?

This is my G31

G31 P1 X21 Y0 Z0.725 C0.0002 S25 H2

Any ideas ?

Phaedrux

@Garfield said in Z Probe Offset:

My Z probe is offset from the nozzle tip X21 Y0 (the probe is to the left of the nozzle when viewed from the front).

If it's to the left, then the X offset is -21. And if left is +X for you, then you have a problem with your coordinate system.

In G28 homeall.g you need to specify the location you want to probe at by physically moving the probe to that position.

Garfield

The issue that has bitten me here is how the offset is utilised vs probing requests. I based all my co-ordinates off the nozzle tip and assumed that the offset would take care of placing the probe appropriately - it doesn't seem to.

My absolute axis limits are

; Axis Limits
M208 X-157:157 Y-157:148 Z0:311				; set axis Min / Max
M671 X-188.7:10:199 Y-127:199:-127 S10		; Set Bed Pivot Locations

If I set this up in the bed file which are the 'printable' maximums (I have 0,0 at the centre of the build plate)

G30 P0 X-157 Y-127 Z-99999 	; probe near a leadscrew
G30 P1 X30 Y149  Z-99999	; probe near a leadscrew
G30 P2 X157 Y-127 Z-99999 S3 	; probe near a leadscrew and calibrate 3 motors

The offset seems to do odd things - I'd expect the probe to occur at the co-ordinates above less the offset - but that doesn't occur.

On P0 it tries to probe exactly where it is (because it always homes), it does not attempt to move the probe to position -157 ( the probe is actually above X-178) and on P2 it tries to drive to X177.

To make this work I need to define the probing like this (even with the offset in G31 set to -21 - I have played with both + and -ve values)

G30 P0 X-138 Y-127 Z-99999 	; probe near a leadscrew
G30 P1 X0 Y149  Z-99999	; probe near a leadscrew
G30 P2 X135 Y-127 Z-99999 S3 	; probe near a leadscrew  and calibrate 3 motors

G30 appears to use explicit co-ordinates, those co-ordinates are those of the probe not the nozzle, it is working as is but isn't what I expected so I'll play again later, I've already had one bed crash that I'm none too chuffed about.

Phaedrux

@Garfield said in Z Probe Offset:

it doesn't seem to.

That's right. You must place the probe where you want before the G30, meaning you must place the nozzle such that the probe is where you want it to be. Same for in Bed.g. The points are where the nozzle would be, such that the probe is where you want it.

@Garfield said in Z Probe Offset:

(even with the offset in G31 set to -21 - I have played with both + and -ve values)

-21 is to the left. -X should move to the left, X+ to the right. -Y to the front, and Y+ to the back. Right hand coordinate system. The offset is important because it's used by the heightmap etc to know where the nozzle in in relation to the probe. During a G29 it won't probe locations that it can't physically reach for instance.

Garfield

Then what purpose does defining the offset in G31 serve ?

Danal

@dc42 will need to comment, because the code in Zprobe looks to me like it checks reachability based on the grid with no offset, and then uses the offset for the actual move. Of course, I only looked at this for a minute, it could be absolutely correct... it just looks a little strange at first glance:

if (move.IsAccessibleProbePoint(x, y))
{
SetMoveBufferDefaults();
moveBuffer.coords[X_AXIS] = x - platform.GetCurrentZProbeParameters().xOffset;

	case GCodeState::gridProbing1:		// ready to move to next grid probe point
		{
			// Move to the current probe point
			Move& move = reprap.GetMove();
			const GridDefinition& grid = move.AccessHeightMap().GetGrid();
			const float x = grid.GetXCoordinate(gridXindex);
			const float y = grid.GetYCoordinate(gridYindex);
			if (grid.IsInRadius(x, y))
			{
				if (move.IsAccessibleProbePoint(x, y))
				{
					SetMoveBufferDefaults();
					moveBuffer.coords[X_AXIS] = x - platform.GetCurrentZProbeParameters().xOffset;
					moveBuffer.coords[Y_AXIS] = y - platform.GetCurrentZProbeParameters().yOffset;
					moveBuffer.coords[Z_AXIS] = platform.GetZProbeStartingHeight();
					moveBuffer.feedRate = platform.GetZProbeTravelSpeed();
					NewMoveAvailable(1);

					tapsDone = 0;
					g30zHeightErrorSum = 0.0;
					g30zHeightErrorLowestDiff = 1000.0;

					gb.AdvanceState();
				}
				else
				{
					platform.MessageF(WarningMessage, "Skipping grid point (%.1f, %.1f) because Z probe cannot reach it\n", (double)x, (double)y);
					gb.SetState(GCodeState::gridProbing6);
				}

Garfield

For me as a newcomer to Reprap 'in the raw' I'm struggling with what appear to be inconsistencies in how things are actioned in different commands.

Nowhere in the documentation have I found this to be adequately explained in my opionion as a newcomer i.e. what is based on nozzle co-ordinates and what is based on probe co-ordinates.

If I tell the system to probe X-157 Y-127 I don't expect to need to calculate the offsets and enter those instead since I've already told the printer (or machine) where the probe is in space relative to the nozzle.

I do realise that there are times where probing outside the 'print area' is required but this should be a deliberate selection regardless of the probing / levelling command - i.e if an option is missing the system won't violate print boundaries. I firmly believe that ALL actions should be based on nozzle co-ordinates for consistency, some commands being able to violate print boundaries and others not able to, there should be a hard boundary that no command can violate.

This issue has cost me in excess of $150 to replace damaged print surface components so I'm not terribly happy right now ....