Duet3 Mini 5+ Eth + 1HCL Drifting position during probing

[ironhydroxide]

Continuing with my project to control a tubing cutter with the Duet I have come across an interesting issue.

The issue is, over multiple probes the Z position seems to drift upwards (positive Z) in opposition to the raw encoder values in the 1HCL.

My blade is on an electrically isolated spindle, I have a simple probe setup between the blade and the tube. (essentially a microswitch probe)
My Z axis is run by a 1HCL board, with a quadrature encoder on the z axis, and a magnetic encoder on the motor.
The probe is on the Mini 5+ mainboard.

Quadrature encoder ticks per motor revolution is 189,
1 motor revolution is 0.318 mm

Operation is, probe to tubing, calculate depth required, feed z to depth required, then back out of the cut and feed/rotate the tubing to the next planned cut.

for testing I have a probing macro I call before each cut.
The script calls G30 S-1 Then calls M122 B50.0 immediately, then passes back to the previous script to calculate the cut depth.

I have parsed the M122 results with the "Stopped at height" results from the G30 and graphed them.
note: Quadrature encoder ticks per motor revolution is 189, 1 motor revolution is 0.318 mm
2nd Note: Encoder ticks should trend upwards slightly, as blade wear causes more movement before tube contact
In Closed Loop Mode

Note in purple the encoder ticks are very consistent only varying by ~43 individual ticks over the range, Logically the Z value should only vary by 0.072mm as opposed to it's ~0.35mm variation

Note in red, the ticks seem more noisy, it's due to my ineptitude in excel and setting ranges on the graph. Overall min/max is only 50 ticks, meaning 0.084mm variance as opposed to the shown 0.18mm variance.

The skew is worrying to me, but what is more concerning is the difference in closed vs open loop operation while probing.
Why would open loop be 2x more skew to the Z value compared to closed loop?

I'm very new to the Duet, so if anyone has any suggestions on what may be happening, or have easier ways to do the probing/evaluation than the parsing, I'm all ears.

[droftarts]

@ironhydroxide Please can you post your full config.g, the response to M122, and the probing macro you're using for testing.

A couple of observations/suggestions:

• have you tuned the closed loop motor?
• in the macro, when it "calculate depth required", is Z0 reset? Maybe there is a rounding in this calculation that causes drift.
• @dc42 has said before (https://forum.duet3d.com/post/353805) it's best to home an axis in open loop mode. I don't know if this applies to probing as well, but may also explain the difference between the two.

Ian

[ironhydroxide]

@droftarts
I have tuned the Closed Loop parameters, though my system has backlash that requires me to have a lower Proportional value than most say is ideal for closed loop tuning setup (belt reduction to screw movement to linear movement, inherently there will be some backlash)

I do not reset the Z when probing, thus the s-1 on the G30, just report value.
I do however reset the Z at the start of the run from the average of 4 points on my tube (probe, save value, spin 90, probe, save value, spin 90, probe, save value, spin 90, probe, average values, set Z 0=average of values)
I was wondering if having the probe on the mainboard, not the 1HCL may be causing some of this, as inherently the motor controller will have to wait for the can message to stop movement, as opposed to potentially having an interrupt stopping movement immediately if it were on the 1HCL (i don't actually know how the 1HCL is coded with probing etc).
I did try the probe on the 1HCL at a previous time, but this tended in a "sticky" probe, where the probe would lock to 1000 or 0 and not change until I rebooted the board. This was on a previous firmware (3.6.0 beta2, vs 3.6.0-rc2+4), so may have been that causing the sticky probe, IDK.

I home in Open loop before moving to closed loop.

Another thought I had was maybe I'm so far into the decimals here that floating point math is causing issues. as my system only has 3mm overall Z travel maybe it'd be better to configure it as mm=um to cheat that up by a few orders of magnitude.

Config.g here.
config(3).g

I call this at the start of the Run to set Z 0
setZeroDepth.g

then this is called at each start of a cut
findContact.g

here's some raw logs I have parsed to get graphs from
eventlog4-24ClosedLoop.txt eventlog4-24OpenLoop.txt

[ironhydroxide]

Also, searching around the forum, it seems like this post might be the same issue, just with a delta printer instead of a simple z axis.

https://forum.duet3d.com/topic/36572/v2-0-consistently-increasing-probe-heights

[dc42]

@ironhydroxide have you tried writing a macro to repeatedly probe using G30 S-1 and move back to 50mm, to see whether you still get this trend of increasing reported stop heights?

One possible cause of this type of error in open loop mode is that if the probing speed is too high, when contact is made and the motor is stopped abruptly it may skip 4 full steps, or possibly a multiple of 4. So the tool is higher than RRF thinks it is; and when you probe again, it has to move a greater distance to trigger the probe.

[ironhydroxide]

@dc42 My system doesn't have 50mm to move. Max Z travel I have is 3mm.

that said, what I'm doing is essentially that.
Probe to depth, calculate cut depth from probe point, cut, back out of cut the calculated amount plus 0.0254mm, move the tube to the next cut position, and do it all again.

I am probing at a speed of 2.425mm/min (secondary speed 0.0363255), which on my system equates to ~1522.9 full steps/min (and 22.812 full steps/min) I would assume this is plenty slow to not overshoot by 4 full steps?

Due to the nature of the blade being the contact, if I were to probe the same part of the tube too many times, I'd cut through it eventually.

I saw you posted the rc2+5 to potentially fix the 1HCL probe sticking problem, I have loaded that and relocated my probe to the 1HCL, then ran the same test. Here are the results from that.
Starting at encoder ticks of 2250 and a Z0,
Ending with encoder ticks of 2276 and Z0.047.
Difference of 26 ticks which calculates to 0.0437.

eventlog.txt
It seems the rc2+5 fixed not only the sticky probe problem, but also the skew I was seeing.

Edit:
After reevaluation, I realize that I am seeing a skew here. as the ticks go up, the actual travel should be in the negative Z direction.
I'm not sure how I would be seeing an inverted skew though, interesting implications.

[ironhydroxide]

Well, Spoke too soon on the Sticky Probe issue.
Happened again on the run after the one above,
Though I believe the skew to be gone.

eventlog(10).txt

Edit: see above, I don't think the skew I'm seeing is completely gone.
Testing again with probe on mainboard instead of 1HCL and slowed down probing speed. (can't seem to get 1HCL to complete a run without sticky probe after the very first run of rc2+5)