[3.6.0-rc.3] sticky probe with 1HCL board

[ironhydroxide]

Did multiple more tests, all of the combinations of:
OpenLoop:ClosedLoop
G30:G38.2
MainBoard:1HCL (probe connection)

MainBoard connected would get through my test without once sticking the probe.
1HCL connected always stuck the probe, but at random times. The most # of probes I was able to get through before the probe stuck was 781.

Also tried slowing down the probing speed, and playing with the pullback (M558 H###:####). none had noticeable affect in time before sticking, though it's so random it's hard to identify what makes a difference or what is just placebo.

[dc42]

@ironhydroxide what was the latest 3.6.x version you used that you think didn't have this issue?

[ironhydroxide]

@dc42 I don't think there was one, though I didn't exhaustively test.

I think I was on 3.6.0-beta3 when I first setup the system with initial tests. It happened on that version and I went searching and found mentioned it wasn't recommended to probe from a can Board. I swapped it to the mainboard and continued my testing, upping versions as I saw them released.

I revisited the probe on Can board when my testing showed a significant skew in where the machine thought was vs where it really should be (my post in the general discussion page) and when testing for that found that the 3.6.0-rc2+5 ran one complete cycle of my test without sticking, and the dissonance in real vs machine position was much improved. But since that Single cycle completed successfully I have not been able to manage another without sticky probe if the probe is on the 1HCL.

I can go through the versions I have saved (beta3, beta4, rc1, rc1+1-3, rc2, rc2+1-5, rc3) and test them progressively if that would help.

[ironhydroxide]

@dc42 Tested every firmware I had downloaded. Each and every one at one time stuck the probe when connected to the 1HCL board. eventlog for each is titled it's firmware name. Zip file has event logs, as well as the spreadsheets I used to evaluate the trends.

Doing all this testing has shown me that it'd be MUCH simpler to check the machine position skew vs the encoder if the encoder ticks were available in the object model, instead of having to run an M122, and after the fact run the log through a python script, pulling out the ticks. Is this something that's fairly easily doable? or a huge change to the firmware?

Test setup:
1HCL running Z axis in Open Loop
Probe on 1HCL input 1
Probe Macro using G30 with F0.363255:0.0363255 speeds
config.g config.g

setZeroDepth.g set zero macro.

findContact.g find contact macro.

no changes in macros or cycle between firmwares.

Results from testing:
3.6.0-beta3: one single probe successful, subsequent probes "probe already triggered at start of probing move" Probe stuck at 1000 until main board reboot.

3.6.0-beta4: set zero macro successful (probe at 4 points on tube, average position, set average as machine zero), 6 probes succeed, then probe stuck at 1000 till main board reboot. (total 11 probes before sticking)

3.6.0-rc1: 2498 probes successful before probe sticking. Probe positions trended up for 120 probes before inverting and trending down for the remainder, while the encoder values trend up fairly consistently (note, encoder tick values are inverse to position, as ticks go up, z goes negative. at a rate of 0.00168mm/tick, or 594.3ticks/mm)

3.6.0-rc1+1: full cycle successful without sticking (5696 probes), Probe positions trended up for ~200 probes before inverting and trending down for the remainder. curiously the downwards trend is in a repeating bumpy fashion with a period of ~300-400 probes. I notice now that the previous test (3.6.0-rc1) showed the same bumpy ~300-400 period drift. Difference in start vs end in machine position -0.237mm, difference start vs end in ticks 34. Meaning that the machine position should have drifted -0.05712mm if we trust the ticks on the encoder. this is about 1/4 the drift the machine position shows.

3.6.0-rc1+1 2: Ran the cycle again to see if it'd complete a second time. 954 probes successful before probe sticking (6650 probes total since powerup/cycle). Again noticed upwards trend till ~200 probes, then downwards at the same "bumpy" ~300-400 probe cycle until probe stick (can barely see 1.5 bumps before shutdown).

3.6.0-rc1+2: 225 probes before sticking. machine position trending up before probe stuck.

3.6.0-rc1+3: 1163 probes before my macro shut down the cycle due to too much variance in probe positions. Probe trend upwards till ~200, then bumpy downwards is still present.

3.6.0-rc1+3 2: 287 probes before sticking (1450 probes total since powerup/cycle). Probe trend upwards till ~150, then downwards before sticky probe.

3.6.0-rc2:1881 probes before sticking. Probe again trends upwards till ~200, then trends downwards on the ~300-400 probe bumpyness, though there are 2 points where the probe shifts significantly ~0.008mm between probes, when the encoder ticks differs by ~2.

3.6.0-rc2+1: 34 probes before sticking. Not much data to trend, but even still seem to be shifting upwards.

3.6.0-rc2+4: 403 probes before sticking. Again upwards trend till ~200, then downwards trend.

3.6.0-rc2+5: 475 probes before sticking. Upwards trend until ~160, then downwards trend leveling off ~340.

3.6.0-rc3: 1232 probes before sticking. Upwards trend till ~200, downwards bumpy trend at 300-400 cadence.

Here's the Zip of all the Logs and Excel files, download and change the extension to .zip instead of .txt
3.6.0Tests.txt

[dc42]

@ironhydroxide thanks for your comprehensive testing!

1. What type of probe is it: BLTouch, simple switch, or something else?

2. Please confirm that this a new system that you have only run 3.6 beta/RC versions on, and you haven't previously had it working using 3.5.x firmware.

[dc42]

@ironhydroxide further to my previous message, please execute the following commands both before the probe has stuck and after it has stuck, in each case with the probe not triggered and then with the probe triggered, and report the outputs:

M122 B50 P1007 A{0x40002800} R16
M122 B50 P1007 A{0x41008000} R16

[ironhydroxide]

@dc42 it's a "simple switch" In that it's a conductive blade on an electrically isolated spindle,
And yes, it's a new system I'm working through feasibility on using the Duet for our fleet of machines.

The tube is connected to the probe ground pin,
The spindle is connected to the input pin, inverted input, with pullup enabled.

When the two connect, the voltage drops and the probe is triggered.

I'll add those commands to my macro and test.

[ironhydroxide]

@dc42 I added:

M118 P0 S{"PreTrigger: "^sensors.probes[0].value[0]} L2
M122 B50 P1007 A{0x40002800} R16
M122 B50 P1007 A{0x41008000} R16 

just before calling G30 in my probe macro,
Then after probe position is "accepted" (probe should still be triggered as Z hasn't moved since G30)

M118 P0 S{"ProbeTriggered: "^sensors.probes[0].value[0]} L2
M122 B50 P1007 A{0x40002800} R16
M122 B50 P1007 A{0x41008000} R16

and then ran the test again.
I noticed the system shut down much more often due to my probe macro not accepting probe points close enough together, than previous tests. Not sure why a log and diagnostic output command could cause that, as I'd think it wouldn't affect anything in the movement or probe interrupt....
I also noticed while running, that the outputs when the probe shouldn't be triggered (pre trigger) often showed probe status of 1000, but didn't error on the G30 command that runs right after, but also often showed status of 0...
And as for the inverse, on the output that should be "triggered" the probe was often reported with status 0, and ONLY reported status 1000 once. though this one I can see that maybe the blade removed enough material to no longer be in contact with the tube in the time between the probe cycle finishing, and my log command running..... though I'd assume that to be microseconds, not milliseconds.

after 3 shutdowns due to my macro, the probe stuck on the 4th running.
I confirmed probe stuck, then ran in the console

M118 P0 S{"Probe Stuck, Probe definitely not triggered: "^sensors.probes[0].value[0]} L2
M122 B50 P1007 A{0x40002800} R16
M122 B50 P1007 A{0x41008000} R16

then lowered my z by 0.05 (definitely contacting my tubing, ie triggered) and ran

M118 P0 S{"Probe Stuck, Probe definitely triggered: "^sensors.probes[0].value[0]} L2
M122 B50 P1007 A{0x40002800} R16
M122 B50 P1007 A{0x41008000} R16

3.6.0-rc3-M122.txt

3.6.0-rc3-M122.xlsx

in the excel, the really low encoder tick points and low probe positions are where I restarted the macro, and it has to go through the findzero macro.

as for the outputs. Directly before probe stuck I got this, (pulled from the log file attached above)

2025-05-09 07:57:09 [info] ProbeTriggered: 0
2025-05-09 07:57:09 [debug] Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-09 07:57:09 [debug] Address 0x41008000: c8040422 c8040422 c8040422 c8040422 08142401 08142401 08142401 08142401 089d3701 00000000 00000000 00000000 01011100 00022022 88002022 07000066
2025-05-09 07:57:10 [info] PreTrigger: 0
2025-05-09 07:57:10 [debug] Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-09 07:57:10 [debug] Address 0x41008000: c8040422 c8040422 c8040422 c8040422 08142401 08142401 08142401 08142401 0a953f01 00000000 00000000 00000000 01011100 00022022 88002022 07000066
........
2025-05-09 07:57:43 [info] PreTrigger: 1000
2025-05-09 07:57:43 [debug] Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-09 07:57:43 [debug] Address 0x41008000: c8040422 c8040422 c8040422 c8040422 00142401 00142401 00142401 00142401 00953f01 00000000 00000000 00000000 01011100 00022022 88002022 07000066

And after stuck here's the outputs of the untriggered, and triggered (of course, in the file above as well)

2025-05-09 07:59:06 [info] Probe Stuck, Probe definitely not triggered 1000
2025-05-09 07:59:06 [debug] Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-09 07:59:06 [debug] Address 0x41008000: c8040422 c8040422 c8040422 c8040422 48142401 48142401 48142401 48142401 4a9d3f01 00000000 00000000 00000000 01011100 00022022 88002022 07000066
2025-05-09 08:00:02 [info] Probe Stuck, Probe definitely triggered 1000
2025-05-09 08:00:02 [debug] Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-09 08:00:02 [debug] Address 0x41008000: c8040422 c8040422 c8040422 c8040422 40142401 40142401 40142401 40142401 419d3f01 00000000 00000000 00000000 01011100 00022022 88002022 07000066

[dc42]

@ironhydroxide thank you for your reports.

I am having difficulty interpreting them. Your config.g file uses this M558 line:

M558 P8 C"!50.io1.in" H1:0.00254 F2.425:0.0363255 T100 K0 A10 S0.00127 B0 ; configure blade probe

which indicates that your probe is connected to pin io1.in on the EXP1HCL board at address 50. In the M122 responses that use address 0x41008000 the 9th word after the colon shows the input state of all pins of Port A. Pin io1.in is connected to Port A pin 13, so bit 13 of that word should show the state of the probe inputs. That's the bit worth 0x00002000. In your reports that word has values 089d3701, 0a953f01, 00953f01, 4a9d3f01 and 419d3f01. In all cases that bit is set, indicating that the input pin is high.

Is the probe still connected to pin io1.in of board 50?

[ironhydroxide]

@dc42 Yes, It is still connected to the board 50 io1.in pin. inverted with pullup.
If I understand correctly that would indicate that the probing setup is not actually dragging the input pin down below the trigger point (i'd guess 1.65v, due to the trigger being set at 500 of 1000) at the moment the request is sent.

Maybe I need to setup a scope on this probe input and confirm that it is in fact getting dragged down, and how that signal might look. If it's noisy when near the tube it might trigger before, or long after the initial touch on the tube.

I have been assuming that it has due to the blade being in contact with the tube, and the probe cycle completing,

[ironhydroxide]

@dc42 I left the machine in the stuck probe status, so I was able to retest, confirming with a multimeter that the probe was and was not triggered (3v and 0v)

5/9/2025, 9:58:11 AM: M118 P0 S{"Probe Stuck, Probe definitely not triggered "^sensors.probes[0].value[0]} L2 M122 B50 P1007 A{0x40002800} R16 M122 B50 P1007 A{0x41008000} R16: Probe Stuck, Probe definitely not triggered 1000

Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Address 0x41008000: c8040422 c8040422 c8040422 c8040422 00142401 00142401 00142401 00142401 00953701 00000000 00000000 00000000 01011100 00022022 88002022 07000066
5/9/2025, 9:59:03 AM: M118 P0 S{"Probe Stuck, Probe definitely Triggered"^sensors.probes[0].value[0]} L2 M122 B50 P1007 A{0x40002800} R16 M122 B50 P1007 A{0x41008000} R16: Probe Stuck, Probe definitely Triggered1000

Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Address 0x41008000: c8040422 c8040422 c8040422 c8040422 40142401 40142401 40142401 40142401 42951701 00000000 00000000 00000000 01011100 00022022 88002022 07000066

Then reset the sticky probe, and did the same. confirming the first time it's not triggered, and triggered the second, with a multimeter.

5/9/2025, 10:03:36 AM: M118 P0 S{"Probe Stuck, Probe definitely not Triggered"^sensors.probes[0].value[0]} L2 M122 B50 P1007 A{0x40002800} R16 M122 B50 P1007 A{0x41008000} R16: Probe Stuck, Probe definitely not Triggered0

Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Address 0x41008000: c8040422 c8040422 c8040422 c8040422 00142401 00142401 00142401 00142401 02953701 00000000 00000000 00000000 01011100 00022022 88002022 07000066
5/9/2025, 10:04:04 AM: M118 P0 S{"Probe Stuck, Probe definitely Triggered"^sensors.probes[0].value[0]} L2 M122 B50 P1007 A{0x40002800} R16 M122 B50 P1007 A{0x41008000} R16: Probe Stuck, Probe definitely Triggered1000

Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Address 0x41008000: c8040422 c8040422 c8040422 c8040422 00142401 00142401 00142401 00142401 009d1f01 00000000 00000000 00000000 01011100 00022022 88002022 07000066

[dc42]

@ironhydroxide said in [3.6.0-rc.3] sticky probe with 1HCL board:

Yes, It is still connected to the board 50 io1.in pin. inverted with pullup.

Don't enable the pullup in the M558 command. There is a permanent pullup resistor on that pin. It has quite a high value, so you may wish to add an external pullup to +3.3V or +5V. Enabling the internal pullup as well reduces the noise immunity because of the series resistor on the board.

The responses that you posted most recently look better, the 5th digit changes between 1 and 3 depending on whether the probe is triggered or not.

[ironhydroxide]

@dc42 said in [3.6.0-rc.3] sticky probe with 1HCL board:

Don't enable the pullup in the M558 command. There is a permanent pullup resistor on that pin.

AH, good to know.

In the full run I see that hex digit swap between 1 and 3, but it's more often 3 than 1 (should alternate if it is working 100% of the time correctly).
I'll drop the pullup and do some more tests.

[dc42]

@ironhydroxide please can you run one further test and post the responses:

1. Get the probe into the "stuck" state (make quite sure that it really is stuck)
2. Send m122 b50 p1007 a{0x40002800} R16 as before
3. Send m122 b50 p1007 a{0x4000280c} v{0x00002000}
4. Change the state of the input (it doesn't matter if you change it more than once)
5. Send m122 b50 p1007 a{0x40002800} R16 as before

[ironhydroxide]

@dc42 Here's the output of those.
Step2 didn't give me an output... is that what was intended?

from the console

5/12/2025, 8:04:01 AM: M118 P0 S{"Stuck Probe Confirmed"} L2: Stuck Probe Confirmed
5/12/2025, 8:04:08 AM: m122 b50 p1007 a{0x40002800} R16
5/12/2025, 8:04:09 AM: : Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5/12/2025, 8:04:30 AM: m122 b50 p1007 a{0x4000280c} v{0x00002000}
5/12/2025, 8:05:26 AM: M118 P0 S{"Before changing probe state"} L2 m122 b50 p1007 a{0x40002800} R16: Before changing probe state

Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5/12/2025, 8:06:14 AM: M118 P0 S{"After changing probe state"} L2 m122 b50 p1007 a{0x40002800} R16: After changing probe state

Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00002000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5/12/2025, 8:06:49 AM: M118 P0 S{"After changing probe 2nd time probe not triggered"} L2 m122 b50 p1007 a{0x40002800} R16: After changing probe 2nd time probe not triggered

Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00002000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5/12/2025, 8:07:18 AM: M118 P0 S{"After changing probe 3rd time probe triggered"} L2 m122 b50 p1007 a{0x40002800} R16: After changing probe 3rd time probe triggered

Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00002000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

end of the eventlog

2025-05-12 08:04:00 [info] Stuck Probe Confirmed
2025-05-12 08:04:07 [debug] Address 0x40002800: 00000002 00000000 00000000 00002008 00002008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-12 08:05:25 [info] Before changing probe state
2025-05-12 08:05:25 [debug] Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00000000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-12 08:06:14 [info] After changing probe state
2025-05-12 08:06:14 [debug] Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00002000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-12 08:06:48 [info] After changing probe 2nd time probe not triggered
2025-05-12 08:06:48 [debug] Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00002000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
2025-05-12 08:07:17 [info] After changing probe 3rd time probe triggered
2025-05-12 08:07:17 [debug] Address 0x40002800: 00000002 00000000 00000000 00000008 00000008 00002000 00000000 0000b000 00b00000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Full files here
eventlog.txt
eventlog.xlsx

[dc42]

@ironhydroxide thanks. if you mean that step "3. Send m122 b50 p1007 a{0x4000280c} v{0x00002000}" didn't produce any output, that's expected.

[ironhydroxide]

@dc42 doh, yeah, step 3

[dc42]

@ironhydroxide if you haven't reset the board yet please try sending this:

m122 b50 p1007 a{0x40002810} v{0x00002000}

and see whether the probe works after that, or is still stuck.

[ironhydroxide]

@dc42 Sadly reset the board already, but will go through the steps again adding that.

[dc42]

@ironhydroxide also please post the report from M122 B50 after the probe is stuck.