Scanning Z probe support in RRF 3.5

dc42

I think the one that @gringo linked to may pre-date the Beacon. It claims to be supported by Marlin since August 2022 and its Github repo goes back to May 2022.

A Former User

This post is deleted!

droftarts

@Herve_Smith Link to doc should be: https://github.com/markniu/Bed_Distance_sensor/wiki/Data-Protocol

Ian

A Former User

This post is deleted!

droftarts

@Herve_Smith said in Scanning Z probe support in RRF 3.5:

I thought i already had linked to it.

You did, but the link didn't work. I posted the correct link. You have since edited your original post, with the correct link. You can see the post edit history by clicking on the small square icon next to the post date.

Ian

A Former User

This post is deleted!

martin7404

I am sorry to write on old tread but I have a lamer question is this going ot support duet 2 wifi

T3P3Tony

@martin7404 our implementation will use a CAN-FD based sensor board so only compatible with Duet 3.

flyscha

@dc42
Any chance you have an update to what these codes should be, with the production SZP?

I've tried using these codes and adjusting accordingly, but there seems to be a disconnect when it comes to at least calling out the C"xxxx" you used in the M558 line. I'm using the CAN1_L & CAN1_H pins, but when I try to call them out while using the CAN address assigned to the SZP, I'm getting an error of "expansion boards do not support Z probe output ports".

Also, I'm getting another error of "Invalid Z probe index" for the G31 line, but I'm not sure if it's a problem stemming from the M558 line.

Any help is appreciated.

Thanks!

dc42

@flyscha use C"120.i2c.ldc1612" assuming it is at the default CAN address 120.

flyscha

@dc42 That worked, thank you so much!

Is there somewhere where this type of information is listed within the docs, where odd pin names that aren't called out on the board pinout diagrams are talked about? Or maybe I just didn't search in the proper place?

dc42

@flyscha I think it's been omitted from the documentation. We will correct it.

flyscha

@dc42 Thanks again!

I'm looking for some further help with getting everything going with the SZP, if you don't mind!

Notes:
-I have an MK52 style bed (with 28 magnets), using a few different types of steel sheets, but I'm not convinced that's the issue
-I've tried both included flat 4 pin cables (50mm & 150mm) between SZP board and 12mm coil (I have not tried 15mm yet)
-I've tried running the M558.1 calibration over a non-magnetic area of the bed, as well as the homing point (that's nowhere near the edge of the bed sheet)
-I've tried M558.1 K1 S1/S2/S3 without much difference
-While sitting idle at the Z probe homing height, the SZP sensor reading on DWC bounces around between 0, a steady value (currently around 5985, with a red background), and 999999 with a red background as well.. continuously fluctuating between the three
-I didn't originally have a mesh.g file, but I've also tried creating one and pasting in your code, without any difference in the end result

In the end, whenever I run the G29 K1 command, I get varying results. None of them ever result in the full bed being scanned. Sometimes it errors out right away, others it gets 1-6 rows in before it tells me "Error: sensor error during calibration" or "Error: Bad reading from scanning probe - try recalibrating the probe".

I've tried your exact coding in the config file you shared, regarding the SZP. I've tried only modifying the mesh grid parameters, and about everything in between.

Here's an example of the the calibration results when they actually come through from time to time:
M558.1 K1 S2
Scanning probe coefficients [1.828e-1, -8.680e-4, -3.628e-10, 1.249e-15], reading at trigger height 8256, rms error 0.355mm

Here's my current code:

; SuperPinda Z-Probe
M558 P5 C"io3.in" H1.00 F1500:120 T20000 K0 R0.20 S.05  ; Set Z probe type to effector, set pin number, dive height, probing speeds, Z probe number, recovery time tolerance
G31 P50 X0 Y0 Z0.8675 K0                                ; P50 Z0.8675 Set Z probe trigger value, offset, trigger height (more positive is closer to the bed), probe number
;M557 X7.00:249.00 Y10.00:220.00 S80.666666:70          ; Define mesh grid

; Scanning Z probe
M558 K1 P11 C"69.i2c.ldc1612" F25000 T30000             ; Set Z probe type to SZP, the axes for which it is used and the dive height + speeds
G31 Z3 K1                                               ; Set SZP trigger height, Z probe number
G32                                                     ; Home all then independent Z motor leveling
G28                                                     ; Home all
;M558.2 K1 S-1                                          ; Z probe number, drive level current (-1 being automatically detected)
M558.1 K1 S2                                            ; Z probe number, scan height above/below trigger height
M557 X13:243 Y22:232 S10 	                        ; Define mesh grid

On the off chance I got a partial height map to read, here's what it looked like:

Let me know if you need any further details to help narrow down what's going on. I'm just at a loss as to what the next step might be.

Thank you for everything!

jay_s_uk

@flyscha can you let the machine sit for a while and then grab an M122 B120 output? Does it show a high number of i2c errors?

dc42

@flyscha to avoid the 999999 readings you need to use M558.2 to calibrate the sensor drive level. When you've established the best drive level you can save it in config.g.

flyscha

@jay_s_uk
Thanks for the reply!

Here's what I just pulled from it:

M122 B69
Diagnostics for board 69:
Duet SZP firmware version 3.5.0-rc.2 (2023-12-14 08:58:41)
Bootloader ID: SAMC21 bootloader version 2.10 (2023-11-16)
All averaging filters OK
Never used RAM 14496, free system stack 136 words
Tasks: HEAT(2,nWait,0.1%,131) CanAsync(5,nWait,0.0%,55) CanRecv(3,nWait,0.0%,79) CanClock(5,nWait,0.0%,67) ACCEL(3,nWait,0.0%,53) MAIN(1,running,99.7%,434) IDLE(0,ready,0.0%,27) AIN(2,nWait,0.2%,92), total 100.0%
Last reset 00:01:38 ago, cause: power up
Last software reset data not available
Peak sync jitter 1/4, peak Rx sync delay 198, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 4.9, current 4.9, max 5.0
MCU temperature: min 18.6C, current 20.7C, max 20.7C
Last sensors broadcast 0x00000000 found 0 132 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 417, send timeouts 0, received 728, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0
Accelerometer: LIS2DW, status: 00
Inductive sensor: raw value 37214006, frequency 3.47MHz, current setting 13, ok
I2C bus errors 316, naks 3, contentions 0, other errors 0

flyscha

@dc42 Yes sir, I have done this as well. Not any change in behavior when I save those values in the M558.2 line:

; SuperPinda Z-Probe
M558 P5 C"io3.in" H1.00 F1500:120 T20000 K0 R0.20 S.05  ; Set Z probe type to effector, set pin number, dive height, probing speeds, Z probe number, recovery time tolerance
G31 P50 X0 Y0 Z0.8675 K0                                ; P50 Z0.8675 Set Z probe trigger value, offset, trigger height (more positive is closer to the bed), probe number
;M557 X7.00:249.00 Y10.00:220.00 S80.666666:70          ; Define mesh grid

; Scanning Z probe
M558 K1 P11 C"69.i2c.ldc1612" F25000 T30000             ; Set Z probe type to SZP, the axes for which it is used and the dive height + speeds
G31 Z3 K1                                               ; Set SZP trigger height, Z probe number
G32                                                     ; Home all then independent Z motor leveling
G28                                                     ; Home all
M558.2 K1 S13 R138498                                   ; Z probe number, drive level current (-1 being automatically detected) S13 R138498
M558.1 K1 S3                                            ; Z probe number, scan height above/below trigger height
M557 X13:243 Y22:232 S10 			        ; Define mesh grid

flyscha

I've now switched to the 15mm coil, and I get this when running the M122 command:

Diagnostics for board 69:
Duet SZP firmware version 3.5.0-rc.2 (2023-12-14 08:58:41)
Bootloader ID: SAMC21 bootloader version 2.10 (2023-11-16)
All averaging filters OK
Never used RAM 14496, free system stack 136 words
Tasks: HEAT(2,nWait,0.1%,131) CanAsync(5,nWait,0.0%,55) CanRecv(3,nWait,0.0%,79) CanClock(5,nWait,0.0%,67) ACCEL(3,nWait,0.0%,53) MAIN(1,running,99.7%,434) IDLE(0,ready,0.0%,27) AIN(2,nWait,0.2%,92), total 100.0%
Last reset 00:00:42 ago, cause: software
Last software reset data not available
Peak sync jitter 1/4, peak Rx sync delay 202, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 4.9, current 4.9, max 5.0
MCU temperature: min 24.4C, current 24.4C, max 24.5C
Last sensors broadcast 0x00000000 found 0 142 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 199, send timeouts 0, received 285, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0
Accelerometer: LIS2DW, status: 00
Inductive sensor: raw value 39745043, frequency 3.70MHz, current setting 18, ok
I2C bus errors 148, naks 3, contentions 0, other errors 0

Does this still seem high for I2C bus errors?

flyscha

@dc42 said in Scanning Z probe support in RRF 3.5:

I2C doesn't travel long distances well. It was designed for connections between ICs on a single PCB. The signal is pulled to ground actively but relies on pullup resistors to pull it high, which makes it susceptible to noise - and I2C has no error correction protocol. Therefore I advise against using I2C with wire lengths greater than a few cm.

Could this be my problem possibly, or has this been rectified with the production SZP release? The wires I've run from the 6HC mainboard to the SZP board are around 750mm. I'm just not sure how I could do it differently without mounting the SZP board inside 6HC case, and then running a 750mm ribbon cable to the coil.

gloomyandy

@flyscha The i2c connection is only used within the SZP board, the connection between the mainboard to the SZP uses CAN-FD which is designed for that sort of thing, so you don't need to worry about that.