[FluidNC Issue#1506] Macro variable for probe trigger point

未分类 bolang 4个月前 (10-14) 47次浏览

Issue #1506 | 状态: 已关闭 | 作者: massiveradiation | 创建时间: 2025-05-27

标签: enhancement


Machine Context

Hi FluidNC team,

Please consider adding a macro-accessible variable that holds the true probe trigger position (Z at probe contact), similar to how Grbl firmware exposes #5063 or #<probez>. This would enable reliable double-probing and improved toolsetting accuracy, as industry-standard macros depend on capturing the true probe trigger position, not just the post-deceleration Z position.

Currently, FluidNC macros can only see the position after deceleration, which limits precision and makes robust probing routines impossible.

Thank you for your hard work and for considering this enhancement!

Tyler

Feature Description

Expose the true probe trigger position (the machine coordinate at the instant of probe contact, before deceleration and overshoot) as a macro-accessible variable. This would allow macros to reference the exact point where the probe input is triggered during a G38.x move, not the post-deceleration position (the axis position after the machine has stopped moving, which may be slightly past the trigger due to inertia).

Example macro logic (pseudocode):

gcode
G38.2 Z-5 F100 ; probe toward part
(setvar, probedz, #<currentpositionz>) ; currently gives post-deceleration Z
G0 Z#<probez> ; with the new variable, would move to true trigger position
With current FluidNC behavior, macros only have access to the post-deceleration position, not the actual trigger point. This results in probing routines with lower accuracy or false repeatability failures.

Pertinent terminal/log output:

Code
error: Macro attempted to use variable before probe event (Z not at trigger)
Warning: Repeatability test failed. Position mismatch detected.

Grbl firmware provides #5063 for the true trigger position. A similar variable in FluidNC would enable robust, precise, and industry-standard probing and toolsetting macros.

Other Approaches

Currently, one could try to infer the trigger point by tracking machine state or using external scripts, but these are unreliable and add complexity. Direct support in FluidNC macros would be cleaner, safer, and enables industry-standard probing routines out of the box.

How I Can Help

I’m able to test and validate this feature on hardware, provide macro examples, and help document its usage for the community.


评论 (13)

#1 – MitchBradley 于 2025-05-27

> Currently, FluidNC macros can only see the position after deceleration,

Are you sure about that?


#2 – massiveradiation 于 2025-05-27

Hey Mitch,
I’ll send you some concrete info on it tomorrow.
Cheers,
Tyler

On Tue, May 27, 2025 at 12:00 AM Mitch Bradley @.*>
wrote:

> MitchBradley left a comment (bdring/FluidNC#1506)
> <https://github.com/bdring/FluidNC/issues/1506#issuecomment-2911027472>
>
> Currently, FluidNC macros can only see the position after deceleration,
>
> Are you sure about that?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bdring/FluidNC/issues/1506#issuecomment-2911027472>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AGUKYUVPK5FOXZJA4SOT4233APPOFAVCNFSM6AAAAAB56ZO2MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJRGAZDONBXGI>
> .
> You are receiving this because you authored the thread.Message ID:
> @.*>
>


#3 – bdring 于 2025-05-27

Is it different than the [PRB: …] value?

Note: FluidNC also has a hard stop option for probes


#4 – massiveradiation 于 2025-05-27

Hey Bart,
I was trying to create a safety measure for my TLO macro: probe once at
faster rate, record that value, then reprobe much slower, record that value
and then compare the two. Set a tolerance and if out of that tolerance
range, then alarm out.

The terminal print outs of probez1 and probez2, would always be about
0.01mm or so difference, my toolsetter is decent. But, when comparing the
values later in the tolerance check code (see below), the value was
consistently about -0.48mm, which is not correct. Maybe I’m missing
something.

Of course, if I set to something higher than 0.48mm, it works.
Thoughts?

I also got a response from Mitch, asking, “are your sure?” Ha! I’m not
100%, but I don’t know what other explanation for this might be. I even
created little delays before the prints and tried that to see if there was
some kind of data buffering. Should I also send this reply to Mitch or does
it automatically update on github. This is my first feature request so I’m
trying to do things right. Thx

The tlo code:

#probez> = 300 ; Probe feedrate for first (coarse) probe (mm/min)
#finez> = 50 ; Probe feedrate for second (fine) probe (mm/min)
# = 0.05 ; Max allowed diff between probes (mm, positive)

; ==================== PROBE TOOLSETTER ===================

(print,Probing toolsetter…)
G53 G0 X#x> Y#y> F#
G53 G0 Z#rapidz> F#rapidz>

; —– First probe (coarse, fast, downward) —–
G38.2 Z[#depth>] F#probe_z>
G90
#z1> = #<absz>
(print,probez1: #z1>)

; —– Retract upward from setter (relative move) —–
G91
G0 Z#retract> F#rapid_z>
G90

; —– Second probe (fine, downward from above setter) —–
G38.2 Z[#depth>] F#fine_z>
G90
#z2> = #<absz>
(print,probez2: #z2>)

; —– (Tolerance check is disabled – FluidNC cannot access true probe hit values) —–
; #diff> = [#z1> – #z_2>]
; (print,Probe diff: #diff> Tolerance: #tol>)
; o301 if [[#diff> GT #tol>] OR [# LT [0 –
#]]]
; (print,ERROR: Double-probe difference # exceeds tolerance
# mm! Aborting.)
; $Alarm/Send=10
; M0
; o301 endif

; —– Use second (fine) probe as TLO —–
#tlo> = #z_2>
(print,Probing OK. TLO = Z#)

; —– Sanity check: TLO must be within +/- tlo_range (no abs(), check
both + and -) —–
#delta> = [#tlo> – #]
o102 if [[#delta> GT #range>] OR [#delta> LT [0 – #range>]]]
(print,ERROR: Tool offset out of range! Delta = # mm)
$Alarm/Send=10
M0
o102 endif

On Tue, May 27, 2025 at 7:21 AM bdring @.*> wrote:

> bdring left a comment (bdring/FluidNC#1506)
> <https://github.com/bdring/FluidNC/issues/1506#issuecomment-2912148259>
>
> Is it different than the [PRB: …] value?
>
> Note: FluidNC also has a hard stop option for probes
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bdring/FluidNC/issues/1506#issuecomment-2912148259>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AGUKYUSO52OCLYAT6ZA5ZML3ARDDZAVCNFSM6AAAAAB56ZO2MGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJSGE2DQMRVHE>
> .
> You are receiving this because you authored the thread.Message ID:
> @.*>
>


#5 – massiveradiation 于 2025-05-27

I should add that the toolsetter is NC and setup as toolsetter_pin: gpio.36 under the probe: section in yaml.
I just saw hard_stop: false setting on wiki. I can try that althought this spindle is big and heavy. If I do an initial rapid approach on the toolsetter, I don’t want that run to be a hard stop. This setting is either on/off. If I run all toolsetting G38 slow, the shorter tools will take forever to touch. Thoughts?
Or perhaps this is an <absz> vs #5063 issue? But, it says #5063 is WCS, not MCS.


#6 – massiveradiation 于 2025-05-27

I’ll try the following updated code today and report back:

#probez> = 300 ; Probe feedrate for first (coarse) probe (mm/min)
#finez> = 50 ; Probe feedrate for second (fine) probe (mm/min)
# = 0.05 ; Max allowed diff between probes (mm, positive)

; ==================== PROBE TOOLSETTER ===================
(print,Probing toolsetter…)
; —– First probe (coarse, fast, downward) —–
G38.2 Z[#depth>] F#probe_z>
G90
#z1> = #5063 ; True probe trigger point
(print,probez1 (trigger): #z1>)

; —– Retract upward from setter (relative move) —–
G91
G0 Z#retract> F#rapid_z>
G90

; —– Second probe (fine, downward from above setter) —–
G38.2 Z[#depth>] F#fine_z>
G90
#z2> = #5063 ; True probe trigger point (second/fine probe)
(print,probez2 (trigger): #z2>)

; —– Tolerance check using true probe trigger points —–
#diff> = [#z1> – #z_2>]
(print,Probe diff: #diff> Tolerance: #tol>)
o301 if [[#diff> GT #tol>] OR [#diff> LT [0 – #tol>]]]
(print,ERROR: Double-probe difference #diff> exceeds tolerance #tol> mm! Aborting.)
$Alarm/Send=10
M0
o301 endif


#7 – MitchBradley 于 2025-05-27

FluidNC is supposed to record the probe coordinates at the instant of the touch, not post-deceleration. I looked at the code and did not see any obvious errors. Setting up a convincing test is going to take some effort.


#8 – MitchBradley 于 2025-05-27

Since FluidNC is supposed to work the way that you suggest, this should probably be recast as an issue, with all of the system information that the issue template requests. That will help us evaluate what could be going wrong.


#9 – massiveradiation 于 2025-05-27

Thanks Mitch, I’ll see what my prints say and if the new code using #5603 works.

Just for clarification, #5603 stores “machine” Z coordinate at time of probe trigger, yes?

On the fluidnc probe wiki I found this line of code: #ztouch>=#5063 ; save the z touch WCO location

Which is a bit misleading because what’s actually being stored is the Z machine coordinate upon a G38, yes?


#10 – MitchBradley 于 2025-05-27

    // last probe
    axis = id - 5061;
    if (is_axis(axis)) {
        float probeposition[MAXN_AXIS];
        motorstepstompos(probeposition, probe_steps);
        result = toinches(axis, probeposition[axis]);
        return true;
    }

Looks like mpos to me.


#11 – massiveradiation 于 2025-05-27

Maybe an update on the wiki for clarity…

Instead of this: #ztouch>=#5063 ; save the z touch WCO location

Maybe this: #ztouch>=#5063 ; save the z touch mpos (machine position)

What does WCO even stand for? Work Coordinate “”?

Thanks


#12 – bdring 于 2025-05-27

Yes, Work Coordinate Offset.

I’ll check the wiki


#13 – massiveradiation 于 2025-05-27

OK Gents,
The problem seems to have been me using #<probez> instead of #5063! After a lot of testing with #5063, the difference between my toolsetter probes, the first one at F200 and the 2nd at F50, is never more than 0.01mm and is often almost 0! So, please close this feature request and thanks for walking me through it.
Cheers,
Tyler


原始Issue: https://github.com/bdring/FluidNC/issues/1506

喜欢 (0)