UGS's Autoleveller fails to recognise successful probe contacts.

[Xaracen]

Version

2.1.7

Hardware / Firmware

GRBL 1.1

What happened

I'm running a modified Shapeoko 1 with GRBL 1.1h on an Arduino Uno rev 3, and I have a probe which uses the tool-bit itself. The spindle is belt-driven, and is fully electrically isolated from the rest of the mill. The top of the spindle is connected to the Arduino's probe pin, A5, and probing can be done even while the spindle is running.

The probe pin is held high at +4.91v, and the surface of any piece I am probing is either conductive itself, or has a coating of conductive paint or aluminium foil and is connected to the Arduino's ground. Sometimes I use a grounded contact plate.

GRBL's $6 = 0. Typing a suitable G38.2 command into the console works well, and reliably, and has done for years now. For a while I was probing the centres of each character from F-engrave during the engraving runs by simply applying search and replace to the F-engrave's gcode output. We are only talking of around six to ten characters for the most part, and UGS lets me identify their approximate centres' coords that I can place into the gcode for probing.

I updated my UGS to the latest release a few days ago specifically to try the autoleveller. Firstly, I tested its Probe Module, and it works fine. Then I set up a surface scan in the autoleveller to cover the area of a series of F-engravings I am undertaking.

On starting the autoleveller, after a few vertical moves the spindle moves to the first scan position and a probe down begins.

This is the console's output from the session;

*** Connecting to jserialcomm://COM5:115200
Grbl 1.1h ['$'
Grbl 1.1h ['$' for help]
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
*** Fetching device status

?
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
ok
$I
[VER:1.1h.20190825:]
[OPT:V,15,128] (No idea what this means)
ok
$$
$0 = 10 (Step pulse time, microseconds)
$1 = 25 (Step idle delay, milliseconds)
$2 = 0 (Step pulse invert, mask)
$3 = 7 (Step direction invert, mask)
$4 = 0 (Invert step enable pin, boolean)
$5 = 0 (Invert limit pins, boolean)
$6 = 0 (Invert probe pin, boolean)
$10 = 1 (Status report options, mask)
$11 = 0.010 (Junction deviation, millimeters)
$12 = 0.002 (Arc tolerance, millimeters)
$13 = 0 (Report in inches, boolean)
$20 = 0 (Soft limits enable, boolean)
$21 = 0 (Hard limits enable, boolean)
$22 = 0 (Homing cycle enable, boolean)
$23 = 0 (Homing direction invert, mask)
$24 = 25.000 (Homing locate feed rate, mm/min)
$25 = 500.000 (Homing search seek rate, mm/min)
$26 = 250 (Homing switch debounce delay, milliseconds)
$27 = 1.000 (Homing switch pull-off distance, millimeters)
$30 = 1000 (Maximum spindle speed, RPM)
$31 = 0 (Minimum spindle speed, RPM)
$32 = 0 (Laser-mode enable, boolean)
$100 = 43.745 (X-axis travel resolution, step/mm)
$101 = 43.745 (Y-axis travel resolution, step/mm)
$102 = 320.000 (Z-axis travel resolution, step/mm)
$110 = 5000.000 (X-axis maximum rate, mm/min)
$111 = 5000.000 (Y-axis maximum rate, mm/min)
$112 = 2000.000 (Z-axis maximum rate, mm/min)
$120 = 50.000 (X-axis acceleration, mm/sec^2)
$121 = 50.000 (Y-axis acceleration, mm/sec^2)
$122 = 20.000 (Z-axis acceleration, mm/sec^2)
$130 = 171.000 (X-axis maximum travel, millimeters)
$131 = 292.000 (Y-axis maximum travel, millimeters)
$132 = 93.000 (Z-axis maximum travel, millimeters)
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
ok
*** Connected to GRBL 1.1h

(Used the probe to set Z0 on the tile surface.)
(The centre of the slate tile is the milling coordinate origin)

G38.2 Z-5.00 F2.5 (Typed into the console)
[PRB:0.000,0.000,-0.634:1] (This is a 'successful probe' response.)
ok
G92 Z0 (Typed into the console)
ok

(Starting the surface scan)

$J=G21G91Z1F400
ok
G21G90G0Z6F400
G91 G21
G21G90G0X-20.056Y-8.126F400 (move to the first scan point, bottom left of the engraving)
G91 G21
G21G90G0Z1F400
G91 G21
ok
ok
G21G90G0X-20.056Y-8.126F400
G91 G21
G21 G91 G49
G38.2 Z-4 F10 (probing down)
ok
G91 G21
ok
ok
ok
ok
ok
ok
[PRB:-20.048,-8.115,-0.903:1] (A 'successful probe' response!)
ok
ok

But as soon as the probe touched the surface a Probe Fail window immediately appeared in red, and the scan stopped!

That is clearly a successful probe contact. But the autoleveller failed to recognise it, and immediately errored out as a Probe Fail, abandoning the scan. What was it looking for, that it didn't get?

Having read some other users issues with autoleveller, I rewired my probe and contact plate to use $6=1, in case that was the problem, and probing still works happily with a G38.2 probe command typed into the console, and with UGS's Probe Module, but again the autoleveller failed to recognise a successful probe contact.

Started the Scan surface

$J=G21G91Z1F400
ok
G21G90G0Z6F400
G91 G21
G21G90G0X-20.056Y-8.126F400
G91 G21
G21G90G0Z1F400
G91 G21
ok
ok
G21G90G0X-20.056Y-8.126F400
G91 G21
ok
ok
G21 G91 G49
G38.2 Z-4 F10
G91 G21
ok
ok
ok
ok
ok
[PRB:-20.048,-8.115,0.459:1] (A 'successful probe' response!)

Immediate Probe Fail again, and the scan stopped, with the probe still touching the test surface. I turned everything off, waited a while, then used a multimeter to check the probe pin's continuity with the test surface, then turned the Z-axis lead screw manually to lift it up, and that continuity vanished. That probe report really is of a successful contact!

I really want autoleveller to work.

How to reproduce

No response

Operating System

Windows 11 Pro version 23H2

Anything else

It happens every time I've tried to use autoleveller. My probes do not fail if initiated by other methods as explained in my 'What happened'.

[Xaracen]

How to reproduce the issue? I just need to use the autoleveller while the probe isn't touching the contact plate or the stock's surface. It always fails as soon as contact is actually made. Probing works reliably as long as I don't let autoleveller initiate it.

[breiler]

I just ran a test on my machine and it is working fine:

untitled.mp4

Can you upload your log file (go to the menu Tools -> Open log directory).

[Xaracen]

Thanks, will do.
messages.log
messages1.log
messages2.log

[breiler]

Can you give me the output for $# to get all work coordinate offsets.

The problem is that it moves to a XY probe location (G21G90G0X-20.056Y-8.126F400) and initiates the probe. But the probe reports with a coordinate PRB:-20.048,-8.115,0.459:1.

Both the X and Y coordinates returned from the probe are off by X - 0.008mm and Y - 0.011mm.

[Xaracen]

*** Connected to GRBL 1.1h

$#
[G54:0.000,0.000,-1.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok

[Xaracen]

"Both the X and Y coordinates returned from the probe are off by X - 0.008mm and Y - 0.011mm."

The mill is a belt-driven shapeoko v1, and the belts weren't that tightly tensioned for actual milling, since, today, I was only checking for the probe's functionality. The target surface is only a dummy, a piece of stiff foam wrapped in foil in a small vice with the contact plate attached to it.

[breiler]

I don't think that this is not a mechanical issue.

A command is placing the machine a specific XY-position, then initiates a Z probe. However the probed XY-position is different which it shouldn't.

I just want to confirm, are you using a non altered version of the original GRBL from https://github.com/gnea/grbl?

[Xaracen]

Yes, that's the site Chamnit links to from the older grbl site.

[Xaracen]

And I haven't altered it in any way. I also had the same problem with 1.1f, which I'd had for years up until a few days ago, when I d'loaded and sent over that 1.1h one. I then wrote it into a different Arduino Uno after I the problems arose as the old one was easily 11 years old, on the possibility that it was past its best, but the newer one behaved in exactly the same way.

[breiler]

I understand.

This could be some sort of rounding error happening on the controller. I have never run a machine with this many decimals in the steps/mm setting:

$100 = 43.745 (X-axis travel resolution, step/mm)
$101 = 43.745 (Y-axis travel resolution, step/mm)

I don't have time to tinker with this at the moment.

[Xaracen]

If you need to leave this for a while, I can get on with other things in the meantime. As for the slight differences in x and y coords, non-autoleveller probes don't fail, so I don't see that being a GRBL issue.

Thank you for your efforts.

[breiler]

When using the Z-probe we ignore the values for XY returned from GRBL.

We could maybe ignore the XY values during autolevel as well. But I won't remove this check before I am able to reproduce the issue and make sure this change won't make things worse.

[breiler]

Ok, I was able to reproduce the problem now.

My machine is configured with 800 steps/mm. Turning this down to your settings of 43.745 steps/mm I loose a lot of precision reported from the controller.

UGS is expecting a probe position of x=10.0,y=0.0 but instead got x=9.989,y=0.0

I am going to try to decrease the required precision to 0.1.

[Xaracen]

Thank you!

[breiler]

The changes are available in the latest nightly build here:
https://github.com/winder/Universal-G-Code-Sender/releases/tag/nightly

[Xaracen]

Thank you for this, I've d/loaded it and will install it and try it out tomorrow., and let you know how I get on.

Best regards!

[Xaracen]

Ah ha! Scanning is underway as I'm typing this! Thank you very much, Joacim! I'll leave the actual engraving till tomorrow.

[Xaracen]

Scan complete, and the autolevelled gcode is safely saved. Engraving can get a bit loud so I'll need to leave it till tomorrow.

[Xaracen]

4.5cm x 2cm F-engraving on slate tile of the autolevelled gcode.

[breiler]

Cool, looks like a success. There is a chip in the materials top left corner, right?

[Xaracen]

Yes, slate can be a bit fragile, that bit broke off afterwards. I think I've enough room to bring the borders in from the edges for the other ones. I didn't want to mill the top flat because I'd lose the texturing.

I've several more to do, and they will each be mounted on a small slate base, and used as placecards for the guests at the top table at my daughter's upcoming wedding.

Your help is highly appreciated, Joacim, Thank you very much.

Might it be worth having a user setting for that precision parameter at some point in the future?

[Xaracen]

I'm a bit puzzled about that variation of x and y values; If the probe is only probing the z axis, then the other axes aren't being moved, and as GRBL doesn't have any positioning sensors other than homing and limit switches, it can only use dead-reckoning based on what stepping motions it has sent to the relevant axis steppers to keep track of current positions and the steps per mm values in its configuration settings. It would be GRBL itself that 'edited' those x and y values on the hoof, so if I had manually moved the spindle 10mm to the left, GRBL would be unaware of that movement, and it would have no reason to change the current x values.

[breiler]

This is my take on it.

If you say to GRBL to move X from 0mm to 2mm with the 43.745 steps/mm setting. It would require 87.49 steps. It is not possible to move half steps so GRBL will need to round this to be 87 steps. The actual distance moved would then be 1.989 mm which would now be the current position of GRBL.

If we initiate a Z probe it will report the the Z height and also this X position.

[Xaracen]

Yes, but having reported or stored that x-position at the top, nothing it would have seen would require it to update it to something else when it bottomed out at the end of the probe, successful or otherwise.

[breiler]

I really don't know what the best way forward is.

Right now UGS creates a grid with all the XY points it should scan. Then probes each one and updates the Z value only. As a safety measure, there is a check that the XY in the probed point is within a (my newly updated) 0.1mm margin to the grid XY point. It was this check that caused your problems.

We could remove the check or leave it as it, accepting any resolution errors on the machine.

Or like you are suggesting, we could update the grid XY values as well. This may be more correct, but I know we have some logic for storing/loading point mesh data that could be effected by this.

It requires some investigation...

[Xaracen]

"It requires some investigation..."
Agreed. But it needn't be a high priority, at least as far as I'm concerned since even when the probe was failing, the actual 'errors' in x/y positioning were only around 1/100th of a millimetre. For any milling task I can do on my shapeoko, I'd never see the difference anyway.

Thanks again!