Wiring a Duet 3 Scanning Z-Probe v1.0 to a Toolboard v1.3

WOPR73

@gloomyandy So if I understand this correctly. From the Distribution Board run CAN and Power to the 1LC, But only use 1) CAN_L and 2) CAN_H to control the 1LC. Then use 3) CAN_L and 4) CAN_H from the Distribution Board for connecting to the SZP and pull +v5 and GND from the 1LC. Correct? Is this because 3) CAN_L and 4) CAN_H are not use due to 1LC not having a CAN_OUT?

dc42

@WOPR73 said in Wiring a Duet 3 Scanning Z-Probe v1.0 to a Toolboard v1.3:

@gloomyandy So if I understand this correctly. From the Distribution Board run CAN and Power to the 1LC, But only use 1) CAN_L and 2) CAN_H to control the 1LC. Then use 3) CAN_L and 4) CAN_H from the Distribution Board for connecting to the SZP and pull +v5 and GND from the 1LC. Correct? Is this because 3) CAN_L and 4) CAN_H are not use due to 1LC not having a CAN_OUT?

No, like this.

From the distribution board run a single pair of CAN wires from CAN1_L and CAN1_H (see https://docs.duet3d.com/duet_boards/duet_3_can_expansion/duet_3_tool_distribution_board_v0.5_wiring.png) to one pair of the the tool board CAN_L and CAN_H connections
Connect the other pair of tool board CAN_L and CAN_H connections to the CAN_L and CAN_H connections of the SZP
Connect +5V and GND of the tool board IO0 connector to +5V and GND on the SZP.
Make sure that the termination resistor is enabled on the SZP, and disabled on the tool board.

gloomyandy

@dc42 Does the OP need to remove the optional terminator from the distribution board in this configuration?

dc42

@gloomyandy the CAN bus won't proceed beyond the first of the four tool outputs on the distribution board if it is wired like this, so it doesn't matter whether the termination jumper is fitted or not,

WOPR73

This post is deleted!

WOPR73

@dc42 So, I can do all of this from Tool 0 CAN-FD on the distro board(remove jumpers). I am just splitting the two pairs of CAN, One to the Toolboard and the other pair to SZP.

dc42

@WOPR73 yes that's correct. The CAN bus will run from the main board to the distribution board, from that to the tool board, and from the tool board to the SZP. It will be terminated with 120 ohm resistors at both ends i.e. at the Duet 3 Mini and the SZP.

WOPR73

@WOPR73 wait. what? 120 ohm resistors at both ends? Duet 3 mini? Mini what?

droftarts

@WOPR73 I think you have a 6HC, not a Mini 5+. The mainboard has built in 120ohm resistor for termination, so you don't have to worry about terminating that end. At the other end of the CAN bus, the SZP provides the termination.

Ian

WOPR73

@droftarts yeah, I have a 6HC. I bought the distribution board after I saw that in one of the documents stating I would have to use a resistor in able to connect them. One would think that Duet would have some kind of unified standard of conformity for the connection between components that they have created. I am new to wiring up my own 3D printer and have to research a lot of this stuff to make sure I don't make a mistake. This is by no means close to plug-and-play. Welp, lesson learned I guess.

The Tool Distribution Board came with 4 premade CAN wires. I am not sure what would be easier or cleaner.

Using 2 premade CAN wires running back to the Tool Distribution board. One from the SZP and the other one from the 1LC, both being plugged in at the Distribution board.
or
trying to undo one pair of the wires on the 1LC CAN connection and run it to the SZP.

Would have been nice to just have a CAN out on the 1LC. Either way I still need to take the 5v+ and GND from the tool board so it wont be clean looking. I really wish I would have seen this coming.

Any thoughts?

WOPR73

@dc42 Sorry, But I have a 6HC and a Tool Distribution board. So, I should not need the resistor. With splitting the CAN pair from the Distribution board and one pair going to the 1LC and the other pair going to the SZP. Still unable to M115 or M122 to either. And yes I do have the jumper removed on the distribution board. Using the same connection on the 24v power supply that is being used on the 6HC. Then running power from the distribution board to the 1LC and a blue light is on. But, no response.

4/25/2024, 10:41:36 PM M122 B121
CAN response timeout: board 121, req type 6024, RID 8

4/25/2024, 10:41:11 PM M115 B121
CAN response timeout: board 121, req type 6024, RID 7

i've tried B20, B21 B10, etc; as referred to in some of the duet documents. I went back to the basics and I'm just using the 6HC, Tool Distribution Board and 1LC with supplied CAN cables that came with the Tool Distribution Board. Plus a default config from the RFF config tool.

I was able to upgrade to latest:
Duet Web Control 3.5.1
Panel Due 7i 3.4.1

config.g

Phaedrux

Can you share some photos of your wiring setup?

WOPR73

@Phaedrux Sure, Not the best lighting... but, it should do. I have just tried stand alone without a Pi4 and still can not talk to the 1LC.

4/26/2024, 12:05:11 AM M122 B121
CAN response timeout: board 121, req type 6024, RID 6
4/26/2024, 12:05:07 AM M122 B120
CAN response timeout: board 120, req type 6024, RID 5
4/26/2024, 12:05:01 AM M115 B120
CAN response timeout: board 120, req type 6024, RID 4
4/26/2024, 12:04:50 AM M115 B121
CAN response timeout: board 121, req type 6024, RID 3

droftarts

@WOPR73 from your pictures, I can see that you need to remove the bypass jumpers on the distribution board under the 1LC connection.

Are you having problems connecting to the 1LC on its own? Have you ever been able to connect? I can’t see the SZP wired in in your pictures, looks like just the 1LC is wired in at the moment to the distribution board. In this configuration (I can’t see the SZP connected) the termination jumper should be fitted on the distribution board too.

If you still can’t connect, check that your CAN cable from 6HC to distribution board is correct; flat cables like you have are often wired incorrectly for CAN, see https://docs.duet3d.com/en/User_manual/Machine_configuration/CAN_connection#example-of-a-good-cable

Then check your wiring; that the wire from the distribution board CAN_H goes to CAN_H on the toolboard, and so on.

As others have said, if you’re only ever going to run a 1LC and SZP, the distribution board is a bit redundant. You can take two wires from the 6HC (to the 1LC CAN in, then two wires from the 1LC CAN out to the SZP. Set the SZP to provide termination.

If you plan to add more tools, the distribution board makes sense, though the tool with the SZP will still need to be the last on the CAN bus.

Ian

WOPR73

@droftarts Those pictures are when I started over to troubleshoot and I was just trying to talk to the 1LC by itself... without the SZP. I ended up going though the entire chain and finding out that the main power "OUT 0 Power in" and "OUT 0 (out)" was not working even know it was showing correct voltage on a meter and the 1LC had a blue light on. So, I direct connected the Tool Distribution Board to the mains power "power in". After that I had to grab the "Duet2and3Firmware-3.5.1.zip" and install that. Using the RRF Config Tool zip seems to have conflicting versions of DWC vs 6HC Duet3Firmware_MB6HC.bin file in the download zip. Even after getting each 3.5.1 file from github it still complained after many reboots and reinstalls. So, I ripped out all the files started fresh with the "Duet2and3Firmware-3.5.1.zip" and the 1LC is able to be talked to.

5/2/2024, 6:18:27 PM M122 b121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.5.1 (2024-04-19 14:42:41)
Bootloader ID: SAMC21 bootloader version 2.4 (2021-12-10)
All averaging filters OK
Never used RAM 4152, free system stack 132 words
Tasks: Move(3,nWait 7,0.0%,129) HEAT(2,nWait 6,0.2%,129) CanAsync(5,nWait 4,0.0%,55) CanRecv(3,nWait 1,0.0%,71) CanClock(5,nWait 1,0.0%,67) ACCEL(3,nWait 6,0.0%,53) TMC(2,delaying,3.4%,53) MAIN(1,running,91.8%,315) IDLE(0,ready,0.0%,27) AIN(2,delaying,4.5%,112), total 100.0%
Owned mutexes:
Last reset 00:00:22 ago, cause: power up
Last software reset data not available
Driver 0: pos 0, 80.0 steps/mm, standstill, SG min 0, read errors 0, write errors 0, ifcnt 9, reads 11282, writes 9, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxLate 0 maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter 5/9, peak Rx sync delay 197, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 24.7, current 24.7, max 24.7
MCU temperature: min 35.1C, current 35.6C, max 35.6C
Last sensors broadcast 0x00000002 found 1 101 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 427, send timeouts 0, received 201, lost 0, errs 1, boc 0, free buffers 18, min 18, error reg 20000
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, contentions 0, other errors 0

Now its on to figuring out the SZP. I have a fast blinking red light not in sync with the main board or 1LC. It will not respond to the reset button on the SZP other than a quick green light, then back to flashing fast red. The SZP is/was fastened to the backside of the 3d printed part that the 1LC was on. I'll try to explain the connections I've made hopefully I have it correct. BTW. I bought the Tool Distribution board to avoid the janky resistor that I would have to use if I didn't buy it. Plus who knows what I might add later, right?

From the Tool Distribution Board using Tool 0, 4) CAN1_H and 3) CAN1_L I have connected to the 1LC and able to communicate with.
From the Tool Distribution Board Using Tool 0, 2) CAN_H 0-1 and 1) CAN_L_0-1 going to the SZP.
The SZP does have the solderable jumper on the back of the SZP to set the termination resistor.
The Tool Distribution Board does have all the default jumper on except for the two jumpers on "Tool 0 CAN - FD".

See Photos:

So, I am going back to reread the info on Duet and CAN to see what I missed and how I can get the SZP to talk... and then flash with new firmware. I assuming that is what the fast red blinking means. Any help would be great. Thanks!

Oh, yeah, the CAN cables are bought are from Filastruder on in the Duet section of the store. They're not home made looks like the good cable on that link... just black. But, I have made RJ11 and RJ45 cables before.

Now... I found this: "Only one Type 2 probe can be configured, and if using Duet 3 then it must be connected to the Duet 3 main board, not to a CAN-connected expansion or tool board."
M558: Set Z probe type

why? umm. what is the point of the 1LC... more limitations than it worth. Am I missing something?

droftarts

@WOPR73 Fast flashing red light on the SZP means no CAN connection, which is because you have wired the CAN incorrectly. You can't wire the SZP to the green and white wires from the Tool Distribution board (TDB from now on). If you just had a 1LC, they are the wire that would return from the 1LC to the TDB, to loop on to the next tool (ie the T1 output on the TDB).

From the TDB, the black and white wires should connect to the 1LC. Where these enter the 1LC, there should be another wire pair, that would normally return to the TDB. In your case, they should go to the SZP, and then back to the TDB, like this:

The SZP will actually be on a 'spur' from the CAN bus. Doing it this way will mean the TDB will provide termination to the CAN bus, so you don't have to terminate either the 1LC or the SZP.

Regarding the M558 probe limitation, it has nothing to do with the SZP. The SZP is an entirely separate toolboard from the 1LC. Yes, it's a limitation of the 1LC that not all types of probe can be connected to it. But most probes are encompassed by the types supported by the 1LC. A type 2 probe is a modulated analogue IR probe, which barely anyone uses any more. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_connecting#z-probe-modes-selectable-in-firmware

Probes connected to Duet 3 expansion or tool boards are limited to types 8 and 9. Firmware 3.5 also supports type 11.

Ian

WOPR73

@droftarts the black and white wires are coming from the TDB and going to the 1LC. As well as the white and green are coming from the same TDB and going to the SZP. Are we saying the same thing? Are you saying that I should daisy chain the CAN from the 1LC to the SZP and not from the TDB?

droftarts

@WOPR73 no, I’m saying it goes from the TDB to the 1LC (black and white wires), then to the SZP (wires I drew), then back to the TDB (yellow and green wires). No termination on the 1LC or SZP, termination on the TDB.

Ian

droftarts

@WOPR73 on the TDB, think of the black and white wires being ‘out’, and the green and yellow being ‘in’. It needs to be a loop from ‘out’ to ‘in’. There aren’t two ‘outs’ on one header.

Ian

WOPR73

@droftarts I got it! It the cable I modified was just plugged into the TDB and 1LC in reverse. SWEET!!! B0, B120 and B121 talking!

5/2/2024, 7:59:07 PM M122 B120
Diagnostics for board 120:
Duet SZP firmware version 3.5.0-rc.1+ (2023-11-20 12:50:20)
Bootloader ID: SAMC21 bootloader version 2.10 (2023-11-16)
All averaging filters OK
Never used RAM 14484, 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:44 ago, cause: power up
Last software reset data not available
Peak sync jitter 6/10, 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 27.1C, current 27.2C, max 27.3C
Last sensors broadcast 0x00000000 found 0 248 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 195, send timeouts 0, received 564, lost 0, errs 1, boc 0, free buffers 18, min 18, error reg 20000
Accelerometer: LIS2DW, status: 00
Inductive sensor: raw value 36434439, frequency 3.39MHz, current setting 13, ok
I2C bus errors 139, naks 3, contentions 0, other errors 0

5/2/2024, 7:59:05 PM M122 B121
Diagnostics for board 121:
Duet TOOL1LC rev 1.1 or later firmware version 3.5.1 (2024-04-19 14:42:41)
Bootloader ID: SAMC21 bootloader version 2.4 (2021-12-10)
All averaging filters OK
Never used RAM 4152, free system stack 132 words
Tasks: Move(3,nWait 7,0.0%,129) HEAT(2,nWait 6,0.2%,129) CanAsync(5,nWait 4,0.0%,55) CanRecv(3,nWait 1,0.0%,71) CanClock(5,nWait 1,0.0%,61) ACCEL(3,nWait 6,0.0%,53) TMC(2,nWait 6,3.4%,53) MAIN(1,running,91.8%,315) IDLE(0,ready,0.0%,27) AIN(2,delaying,4.6%,114), total 100.0%
Owned mutexes:
Last reset 00:00:42 ago, cause: power up
Last software reset data not available
Driver 0: pos 0, 80.0 steps/mm, standstill, SG min 0, read errors 0, write errors 0, ifcnt 9, reads 21055, writes 9, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxLate 0 maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter 5/9, peak Rx sync delay 205, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 24.7, current 24.7, max 24.7
MCU temperature: min 32.2C, current 35.0C, max 35.1C
Last sensors broadcast 0x00000002 found 1 146 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 829, send timeouts 0, received 381, lost 0, errs 1, boc 0, free buffers 18, min 18, error reg 20000
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS3DH, status: 00
I2C bus errors 0, naks 3, contentions 0, other errors 0

5/2/2024, 7:59:03 PM M122 B0
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.1 (2024-04-19 14:30:55) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956L2-G43S8-6J1D6-3SJ6K-KA06G
Used output buffers: 1 of 40 (26 max)
Error in macro line 60 while starting up: invalid Z probe index
=== RTOS ===
Static ram: 155208
Dynamic ram: 120424 of which 100 recycled
Never used RAM 67404, free system stack 204 words
Tasks: NETWORK(1,ready,35.7%,140) ETHERNET(5,nWait 7,0.1%,317) HEAT(3,nWait 6,0.0%,329) Move(4,nWait 6,0.0%,336) CanReceiv(6,nWait 1,0.0%,795) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,348) TMC(4,nWait 6,9.2%,56) MAIN(1,running,52.3%,105) IDLE(0,ready,2.6%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:39 ago, cause: power up
Last software reset at 2024-05-02 19:18, reason: User, Gcodes spinning, available RAM 70272, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 20.5, current 29.2, max 29.2
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 99/2, heap memory allocated/used/recyclable 2048/32/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 8, reads 21473, writes 16 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 21473, writes 16 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 21473, writes 16 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 21473, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 21478, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 21479, writes 11 timeouts 0
Date/time: 2024-05-02 19:59:02
Slowest loop: 3.32ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.2ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is ready with "M122 B0" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 355, received 923, lost 0, errs 1, boc 0
Longest wait 2ms for reply type 6053, peak Tx sync delay 68, free buffers 50 (min 49), ts 199/198/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 5.33ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0