Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. flyscha
    3. Posts
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 35
    • Best 5
    • Controversial 0
    • Groups 0

    Posts made by flyscha

    • RE: Scanning Z probe support in RRF 3.5

      @jay_s_uk I tried over and over and over and somehow FINALLY the firmware updated! I must have tried 5 or 6 times, and it just so happened to stick. I won't speak too loudly or else it may scare it back to the previous version.

      @dc42 The new firmware was absolutely the fix for me! Now when I run the M122 diagnostics, I get 0 I2C bus errors. Every now and then there are a few naks (always 0 or 3), but that's about it.

      When sending the G29 command, I now get scanning probe coefficients, and the entire bed scans without any stops, errors, or hiccups.

      Thanks for everyone's help!

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @jay_s_uk Thank you! I for sure ran the M997 B69 after replacing the .bin file on the SD card last night, but maybe something got mixed up when moving bin files around.

      I'll try it all again tonight. Much appreciated!

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @jay_s_uk Ok thanks! Are you using an SBC?

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @jay_s_uk I'm seeing what you're seeing as well, where it's still showing the older version.

      Given that, the beginning of my last post seems to be the culprit:

      I deleted the Duet3Firmware_SZP.bin file from my SBC's SD card, and put the new file in its place.

      Regarding the other files from your link, (SZP.map, TOOL1RR.bin, and TOOL1RR.map), do I need to upload/replace those somewhere as well?

      Just checking because the SZP Documentation page just mentions the Duet3Firmware_SZP.bin file being needed.

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @dc42 Thank you for the update! I deleted the Duet3Firmware_SZP.bin file from my SBC's SD card, and put the new file in its place.

      Regarding the other files from your link, (SZP.map, TOOL1RR.bin, and TOOL1RR.map), do I need to upload/replace those somewhere as well?

      Just checking because the SZP Documentation page just mentions the Duet3Firmware_SZP.bin file being needed.

      With only the SZP.bin file replaced, I'm still getting the same errors of:

      -Error: sensor error during calibration
      -Error: Bad reading from scanning probe - try recalibrating the probe

      Here are the diagnostics as well:

      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:06:13 ago, cause: software
      Last software reset data not available
      Peak sync jitter 1/5, peak Rx sync delay 207, resyncs 0/0, no timer interrupt scheduled
      VIN voltage: min 4.9, current 5.0, max 5.0
      MCU temperature: min 24.9C, current 25.2C, max 25.3C
      Last sensors broadcast 0x00000000 found 0 76 ticks ago, 0 ordering errs, loop time 0
      CAN messages queued 1972, send timeouts 0, received 3785, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0
      Accelerometer: LIS2DW, status: 00
      Inductive sensor: raw value 42133425, frequency 3.92MHz, current setting 13, ok
      I2C bus errors 1344, naks 3, contentions 0, other errors 0

      Thanks!

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @gloomyandy Thanks for the reply.

      When I fire up the machine and I'm trying to get the SZP to calibrate, I get between 150-400 I2C bus errors when I run M122 B69. Letting it sit there for 5 minutes without touching anything, I2C bus errors are over thousand:

      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 124 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%,432) IDLE(0,ready,0.0%,27) AIN(2,nWait,0.2%,92), total 100.0%
      Last reset 00:44:51 ago, cause: power up
      Last software reset data not available
      Peak sync jitter 1/5, peak Rx sync delay 202, resyncs 0/0, no timer interrupt scheduled
      VIN voltage: min 4.9, current 5.0, max 5.0
      MCU temperature: min 18.8C, current 24.3C, max 24.3C
      Last sensors broadcast 0x00000000 found 0 30 ticks ago, 0 ordering errs, loop time 0
      CAN messages queued 1181, send timeouts 0, received 2612, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0
      Accelerometer: LIS2DW, status: 00
      Inductive sensor: raw value 39786813, frequency 3.71MHz, current setting 18, ok
      I2C bus errors 1097, naks 0, contentions 0, other errors 0

      This could be normal for all I know, I'm just grasping for straws currently.

      Thanks!

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      Hey guys, I hope everyone had a great Christmas.

      Unfortunately, I'm still stuck on the same issue. No progress with the Scanning Z Probe working how it should (calibrating, scanning, etc).

      I'm getting a few hundred i2c bus errors when I run the M122 command (see a few posts above). Most of the forum posts I've found about i2c problems seem to be when connecting Duet with Duex, but in my case I just have the 6HC board along with the Scanning Z Probe.

      Any help would be greatly appreciated.

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @gloomyandy Well that's good at least! Thank you

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @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.

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      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?

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @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
      
      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @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

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @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:
      HeightMapSZP.png

      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!

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @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?

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Scanning Z probe support in RRF 3.5

      @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!

      posted in Beta Firmware
      flyschaundefined
      flyscha
    • RE: Duet 3 6HC + Scanning Z Probe, not connecting

      @dc42
      Yes it is! Sorry, I meant to say "I'm NOW getting a connection..."

      Thank you all for your help!

      posted in Duet Hardware and wiring
      flyschaundefined
      flyscha
    • RE: Duet 3 6HC + Scanning Z Probe, not connecting

      @oliof
      Thanks very much, I'm not now getting a connection through CAN-FD to the SZP Board. For further searches, I did have to solder the termination jumper on the back of the SZP board.

      Much appreciated!

      posted in Duet Hardware and wiring
      flyschaundefined
      flyscha
    • RE: Duet 3 6HC + Scanning Z Probe, not connecting

      @oliof

      Thank you for the insight! I will give this a try tonight when I get home.

      posted in Duet Hardware and wiring
      flyschaundefined
      flyscha
    • Duet 3 6HC + Scanning Z Probe, not connecting

      Hi All,

      I've read and reread the documentation for the Scanning Z Probe several times as well as gone over the CAN-FD setup, but I'm still not understanding what I need to do. I'm sure I'm just missing something simple.

      I have a Duet 3 6HC board, with no expansions. I'm looking to connect the Scanning Z Probe directly to the 6HC main board.

      I've wired up the SZP board to ground & 5v. CAN_H & CAN_L wired to the CANFD-0 2-pin KK port.

      When I power everything up, the SZP board's red LED is just flashing rapidly (which I've found to mean there's just no CAN connection), while the status LED on the 6HC is flashing a slow, constant red.

      I've also tried soldering the termination jumper on the back of the SZP board, to no avail.

      Now I've never used anything regarding CAN before, but following the documentation of the SZP, it seems like I should be getting at least a recognized communication before digging into setting reassigning addresses, etc. Running the M115 B120 command just times out as well.

      The SZP doc says "If just using an SZP and a mainboard with no tool boards or other Duet 3 expansion boards CAN can be connected directly to the CAN port on the mini 5+ or other mainboard", which is what I've done.

      I also see on the documentation for the 6HC says (regarding the CAN0_OUT port I'm plugged into on the mainboard):
      "Revision 1.02 and later only: secondary CAN-FD bus. Termination resistor fitted so normally this board must be at the end of the bus however there are drill to disconnect jumpers that allow the termination resistor to be removed. That is not required in normal operation".

      Is what I'm trying to do not considered normal operation? Do I need to drill the jumper out?

      Let me also mention that I've done nothing in my config file for CAN purposes, aside from inputting the "G4 S2" line in, like the SZP documentation states. If there's a simple line of code that turns on CAN that I missed being stated somewhere, please accept my apologies up front.

      I'm using an SBC, and I'm on firmware 3.5.0-rc.2. DSF & DWC firmwares are also the same.

      Thank you for any direction!

      posted in Duet Hardware and wiring
      flyschaundefined
      flyscha
    • RE: Z probe homes, but won't run mesh bed compensation

      @fcwilt @droftarts

      Thanks so much to the both of you for all of your input, directions, and suggestions! After stuffing myself with turkey today, I was able to get the Z probe set up for Z homing, at least as a temporary solution. My Z motors are falling out of alignment with each other just from constant Duet restarts after config file changes, so I’ll be getting individual Z endstops set up ASAP.

      Thanks again!

      posted in Duet Hardware and wiring
      flyschaundefined
      flyscha