Auto Tool Height Measurement

Terry

With both G1 H3 and G1 H4, the machine and user positions are overwritten as soon as the switch is triggered. In absolute mode, the axis value is set equal to the destination value that was commanded in the move. In relative mode, the axis position value is set to 1.

So, for example, starting at machine coordinate V=50 and commanding G1 H4 V2, the axis will move towards V=2 but if the switch is pressed before it gets there, motion will stop and the current position of V will be declared to be V=2, changing the calibration.

Terry

@fcwilt G60 wouldn't work because calibration is lost.

Terry

@fcwilt Triggers can't stop motion in a controlled manner, so at best you can call an emergency stop and lose system calibration. This is why endstop circuitry needs to exist inside the motion control loop - the endstop triggers need to be interrupts that can cancel motion at very low latency without losing position.

fcwilt

@Terry said in Auto Tool Height Measurement:

@fcwilt G60 wouldn't work because calibration is lost.

How so?

If you save the current position and then return to it how does that affect calibration?

Frederick

Terry

G60 would store a position relative to the calibration referenced against the fixed endstop. Any move detecting the mobile endstop will cause the axis to re-reference against that position. Any subsequent G2 R would return to a saved position relative to the new calibration, so not the original absolute position in the machine framework.

fcwilt

@Terry said in Auto Tool Height Measurement:

G60 would store a position relative to the calibration referenced against the fixed endstop. Any move detecting the mobile endstop will cause the axis to re-reference against that position. Any subsequent G2 R would return to a saved position relative to the new calibration, so not the original absolute position in the machine framework.

Under firmware 3.2.2 I did a H3 move.

When the end stop was triggered the movement stopped and the M208 setting for Z min was updated using the Z position at the moment the end stop was triggered.

How does that cause the reference for the axis to change?

Frederick

Terry

But did your machine and user position for that axis also change?

Terry

This will only be visible if you are testing against an endstop that is different to the one you referenced from in your homing move...

Terry

For clarity, I home in the positive direction (but physically downwards) for my axis and reference this as the highest axis distance. I then swap out the high end endstop for the low end endstop and probe in the negative direction (physically upwards) until the switch hits the tool.

This recalibrates the axis position to the target value that was in the move command, losing the information about how far I have actually moved in the original coordinate system.

Terry

Ideally, what is needed is a generic probing command that supports motion on any axis. This would be necessary for a 3 degrees of freedom probe mounted in a spindle if you wanted to touch off on a workpiece in X, Y and Z, in any case.

fcwilt

@Terry said in Auto Tool Height Measurement:

This will only be visible if you are testing against an endstop that is different to the one you referenced from in your homing move...

Different in what way?

I don't think it is possible to have more than one end stop configured at the same time for a given axis - aside from the situation where you have multiple Z steppers with an end stop for each.

I did this:

I moved Z down to 100 and issued G91 G1 H3 Z-150.

I waited a bit and triggered the end stop - it was around 47.

M208 now reported min of 47. I reset Z min with M208 Z0:240 which is correct for my printer.

Moving to 0 and the end stop was just triggered as it should be.

This I did this:

I moved Z down to 100 and issued G91 G1 H4 Z-150.

I waited a bit and triggered the end stop - it was around 53.

Moving to 0 and the end stop was just triggered as it should be.

Nothing else appears to have changed.

Frederick

Terry

Just found G38.2, which appears to be more suitable.

After testing with

M558 K1 P8 C"!1.io2.in" F1000
G38.2 V1 P1

I get the same problem! There appears to be a bug where the machine and user positions are always updated to be equal to the requested destination move, even though the move was interrupted by an endstop or probe trigger.

fcwilt

@Terry said in Auto Tool Height Measurement:

Just found G38.2, which appears to be more suitable.

After testing with
M558 K1 P8 C"!1.io2.in" F1000
G38.2 V1 P1
I get the same problem! There appears to be a bug where the machine and user positions are always updated to be equal to the requested destination move, even though the move was interrupted by an endstop or probe trigger.

Perhaps so - because it did not happen in my testing - and the "home" position (which for my testing was 0) remained unchanged.

I know that 3.2.0 had a bug which prevented my 3 Z stepper printer (each stepper had its own end stop) from homing.

Frederick

Terry

Same bug is present on 3.2.2

fcwilt

@Terry said in Auto Tool Height Measurement:

Same bug is present on 3.2.2

I wonder why you are seeing that and I'm not.

What do your end stop configuration look like for the normal axis end stop and this switch end stop.

Thanks.

Frederick

Terry

Axis setup is:

M569 P1.1 S0
M584 V1.1
M208 V0:100
M92 V400
M350 V16 I1	
M566 V400
M203 V10000
M201 V6000
M906 V1500
M574 V2 S1 P"1.io1.in"

Test macro is:

M558 K1 P8 C"!1.io2.in" F1000
G38.2 V1 P1

M117 {move.axes[4].userPosition}

fcwilt

@Terry said in Auto Tool Height Measurement:

Axis setup is:

M569 P1.1 S0
M584 V1.1
M208 V0:100
M92 V400
M350 V16 I1	
M566 V400
M203 V10000
M201 V6000
M906 V1500
M574 V2 S1 P"1.io1.in"

Test macro is:

M558 K1 P8 C"!1.io2.in" F1000
G38.2 V1 P1

M117 {move.axes[4].userPosition}

I will have to test using a probe.

Why are you echoing the userPosition instead of the machinePosition?

Frederick

Terry

Just as a legacy of testing that machinePosition and userPosition were the same, which they are in this instance.

fcwilt

To test G1 H4 I created the following macros:

Macro to configure for normal Z end stop:

M574 Z1 S1 P"nil"
M574 Z1 S1 P"io3.in"

Macro to configure for temporary Z end stop:

M574 Z1 S1 P"nil"
M574 Z1 S1 P"^!io4.in"

Macro to test G1 H4

G90
G1 Z100 F600
echo "POST G90 G1 Z100 F600: machinePosition = " ^ move.axes[2].machinePosition ^ " === userPosition = " ^ move.axes[2].userPosition 
G60 S0
G91
G1 H4 Z50 F300
echo "POST G91 G1 H4 Z50 F300: machinePosition = " ^ move.axes[2].machinePosition ^ " === userPosition = " ^ move.axes[2].userPosition 
G90
G1 R0 Z0
echo "POST G90 G1 R0 Z0: machinePosition = " ^ move.axes[2].machinePosition ^ " === userPosition = " ^ move.axes[2].userPosition

I ran the macro to configure for the temporary Z end stop
I ran the macro to test G1 H4
I waited a bit and triggered the temporary Z end stop
I ran the macro to configure for the normal Z end stop

Here are the echo outputs:

POST G90 G1 Z100 F600: machinePosition = 100.000 === userPosition = 100.000

POST G91 G1 H4 Z50 F300: machinePosition = 129.786 === userPosition = 129.786

POST G90 G1 R0 Z0: machinePosition = 129.786 === userPosition = 100.000

The homed status of Z was not changed.

Frederick

Terry

Good, that seems to confirm that it's an issue with the 3HC firmware.