Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Probe and autolevel fail to change Z zero #2419

Open
Acliad opened this issue Jan 7, 2024 · 7 comments
Open

Probe and autolevel fail to change Z zero #2419

Acliad opened this issue Jan 7, 2024 · 7 comments

Comments

@Acliad
Copy link

Acliad commented Jan 7, 2024

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
Copy link

wbrogdo1 commented Jan 8, 2024

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
Copy link
Author

Acliad commented Jan 9, 2024

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
Copy link

wbrogdo1 commented Jan 9, 2024

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
Copy link
Author

Acliad commented Jan 9, 2024

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
Copy link

kbrown73 commented Feb 8, 2024

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
Copy link
Author

Acliad commented Feb 8, 2024

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
Copy link

kbrown73 commented Feb 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants