winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.86k stars 757 forks source link

Probe and autolevel fail to change Z zero #2419

Open Acliad opened 6 months ago

Acliad commented 6 months ago

Version

2.1.3

Hardware / Firmware

TinyG

What happened

When running the Z probe module, my CNC appears to correctly interpret the G38.2 Z-20 F100 command and lowers Z until the touch plate is hit, at which point it stops. However, UGS does nothing more after that. The DRO reads the Z position of the touch plate and does not zero out the axis. In auto leveling mode, the same thing happens and the routine does nothing more after the first probe (i.e., autoleveling fails).

I'm on the latest TinyG Firmware (0.97, 440.20).

How to reproduce

Run "Probe and zero Z".

I'm not sure if this is a TinyG specific issue, as that's the only controller I have.

Operating System

Raspbian GNU/Linux 11 (bullseye)

Anything else

This is the output of the console from hitting "Probe and zero Z" to it stopping:

>>> G10 L20 P1 Z0
>>> G90 G21
{"r":{},"f":[1,0,14,73]}
>>> G21 G91 G49
{"r":{},"f":[1,0,8,4401]}
>>> G38.2 Z-20 F100
{"r":{},"f":[1,0,12,71]}
{"sr":{"dist":1}}
>>> G90 G21
{"r":{},"f":[1,0,16,75]}
{"sr":{"posy":0.000,"stat":7,"dist":0,"coor":0}}
{"sr":{"posz":-0.290,"mpoz":-0.298,"vel":100.00}}
{"sr":{"posz":-0.615,"mpoz":-0.615}}
{"sr":{"posz":-0.940,"mpoz":-0.940}}
{"sr":{"posz":-1.265,"mpoz":-1.265}}
{"sr":{"posz":-1.590,"mpoz":-1.590}}
{"sr":{"posz":-1.863,"mpoz":-1.863,"vel":0.22}}
{"r":{"prb":{"e":1,"x":0.000,"y":0.000,"z":-1.863,"a":0.000,"b":0.000,"c":0.000}},"f":[1,0,0,847]}
{"sr":{"posy":-200.000,"vel":0.00,"stat":3,"dist":1,"coor":1}}
{"r":{},"f":[1,0,8,4401]}
{"sr":{"dist":0}}

Probe settings: probe_settings

State after the probe touches: DRO_Console

messages.log

wbrogdo1 commented 6 months ago

Mine doesn’t work that way either. However, after running the z probe plug-in, z axis is zeroed as long as I don’t click the zero button in the controller state window

Acliad commented 6 months ago

I'm not quite sure what you mean. When you run the z probe plug-in, it does zero out Z for you? Does it respect the "Touch plate thickness" setting? Does the AutoLeveler plug-in work for you?

wbrogdo1 commented 6 months ago

when I position my x & y axis, I click the zero button in the controller state window. the window updates to show zero.(just like your picture) when I run the z probe module, it zero's it's position but doesn't reflect a zero in the controller state window. The z axis is in fact zeroed as long as I don't click the zero button in the controller state window that's directly below the idle or run wording.

After clicking probe and zero z, just click return to zero in your toolbox and see if your z axis is actually zeroed.

Acliad commented 6 months ago

Oh, I think I see. If I run the Z Probe and then hit return to zero (Or type G0 Z0), mine returns to the previous zero position, it doesn't go to the zero position of the touch plate. The routine is definitely failing too, as I believe it's supposed to raise a little after touching the plate, and the auto leveler only does a single probe.

kbrown73 commented 5 months ago

I'm experiencing the same. Probe goes down and on contact it just stops and doesn't appear to do anything else. I'm running latest stable g2core on Arduino Due + g2core shield

Here's the console output:

>>> G10 L20 P1 Z0
>>> G91 G21
{"r":{},"f":[1,0,14]}
>>> G21 G91 G49
{"r":{},"f":[1,0,8]}
>>> G38.2 Z-10 F50
{"r":{},"f":[1,0,12]}
>>> G91 G21
{"r":{},"f":[1,0,15]}
{"sr":{"posz":-14.807,"mpoz":-14.808,"vel":50,"stat":7,"dist":0}}
{"sr":{"posz":-14.975,"mpoz":-14.975}}
{"sr":{"posz":-15.142,"mpoz":-15.142}}
{"sr":{"posz":-15.309,"mpoz":-15.309}}
{"sr":{"posz":-15.477,"mpoz":-15.477}}
{"sr":{"posz":-15.644,"mpoz":-15.644}}
{"sr":{"posz":-15.812,"mpoz":-15.812}}
{"sr":{"posz":-15.979,"mpoz":-15.979}}
{"sr":{"posz":-16.147,"mpoz":-16.147}}
{"sr":{"posz":-16.314,"mpoz":-16.314}}
{"sr":{"posz":-16.482,"mpoz":-16.482}}
{"sr":{"posz":-16.649,"mpoz":-16.649}}
{"sr":{"posz":-16.817,"mpoz":-16.817}}
{"sr":{"posz":-16.984,"mpoz":-16.984}}
{"sr":{"posz":-17.152,"mpoz":-17.152}}
{"sr":{"posz":-17.319,"mpoz":-17.319}}
{"sr":{"posz":-17.487,"mpoz":-17.487}}
{"sr":{"posz":-17.654,"mpoz":-17.654}}
{"sr":{"posz":-17.822,"mpoz":-17.822}}
{"sr":{"posz":-17.989,"mpoz":-17.989}}
{"sr":{"posz":-18.157,"mpoz":-18.157}}
{"sr":{"posz":-18.324,"mpoz":-18.324}}
{"sr":{"posz":-18.492,"mpoz":-18.492}}
{"sr":{"posz":-18.659,"mpoz":-18.659}}
{"sr":{"posz":-18.827,"mpoz":-18.827}}
{"sr":{"posz":-18.994,"mpoz":-18.994}}
{"sr":{"posz":-19.162,"mpoz":-19.162}}
{"sr":{"posz":-19.329,"mpoz":-19.329}}
{"sr":{"posz":-19.497,"mpoz":-19.497}}
{"sr":{"posz":-19.664,"mpoz":-19.664}}
{"sr":{"posz":-19.832,"mpoz":-19.832}}
{"sr":{"posz":-19.999,"mpoz":-19.999}}
{"sr":{"posz":-20.167,"mpoz":-20.167}}
{"sr":{"posz":-20.334,"mpoz":-20.334}}
{"sr":{"posz":-20.502,"mpoz":-20.502}}
{"sr":{"posz":-20.669,"mpoz":-20.669}}
[unhandled message] {"prb":{"e":1, "z":-20.700}}
{"r":{},"f":[1,0,8]}
{"sr":{"posz":-6.001,"mpoz":-20.7,"vel":0,"stat":3,"dist":1}}

Wonder if that [unhandled message] has something to do with it...

Acliad commented 5 months ago

Ahh, interesting. I actually didn't expect this to happen on GRBL. I don't get the unhandled message with tinyg. What OS are you running? I've also tried this on Debian with an Intel machine and have the same issue as the Pi.

kbrown73 commented 5 months ago

I messed about with it a bit more and it turns out that unhandled message was linked to a setting I had compiled g2core with:

#ifndef PROBE_REPORT_ENABLE
#define PROBE_REPORT_ENABLE         true    // {prbr:
#endif

I tried with it set to false and it indeed got rid of that unhandled message line, but it did not solve the original issue though. It still just stopped on probe contact.

EDIT: Just to be clear I'm not using Grbl. I'm using g2core which is based on TinyG.