UGS's Autoleveller fails to recognise successful probe contacts. about universal-g-code-sender HOT 26 OPEN

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.

from universal-g-code-sender.

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

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

from universal-g-code-sender.

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

from universal-g-code-sender.

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.

from universal-g-code-sender.

*** 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

from universal-g-code-sender.

"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.

from universal-g-code-sender.

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?

from universal-g-code-sender.

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

from universal-g-code-sender.

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.

from universal-g-code-sender.

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.

from universal-g-code-sender.

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.

from universal-g-code-sender.

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.

from universal-g-code-sender.

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.

from universal-g-code-sender.

Thank you!

from universal-g-code-sender.

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

from universal-g-code-sender.

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!

from universal-g-code-sender.

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

from universal-g-code-sender.

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

from universal-g-code-sender.

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

from universal-g-code-sender.

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

from universal-g-code-sender.

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?

from universal-g-code-sender.

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.

from universal-g-code-sender.

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.

from universal-g-code-sender.

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.

from universal-g-code-sender.

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...

from universal-g-code-sender.

"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!

from universal-g-code-sender.