Duet 3HC Expansion looses Connection
-
@developeralgo222 To summarise, you got all Duets to sync on your test setup? They failed to sync completely when mounted on the PnP machine? You assume the only difference between both setups to be the CAN wiring - which you verified with your Fluke?
At this point, it is safe to state that all Duets (the 6XD and 4x 3HC) work as expected - that’s proven by your test setup.
The only thing that comes to mind is that the Duet CAN Bus might be unreliable and not as tolerant as its expected to be
That’s exactly the single one topic to be ruled out for sure: with its dedicated controllers and a robust protocol, CAN is one of the most reliable communication means, even in harsh environments.
The CAN cables on the PnP machine are tested good, but some issues still may exist: intermitted contact of the connectors, CAN bus termination, topology of your CAN wiring. To properly commission your setup, add one 3HC at a time and verify the sync. If it doesn’t work, replace the cable (temporarily) and check proper termination.
As was the case with the initial fault - missing GND connection between the two PSUs - there might be „hidden“ issues lurking around as well. These are difficult to diagnose from a distance, so we have to rely on you to tell us the potentially relevant facts. One such example that comes to my mind is an improper mix of GND and Earth: this can lead to quite ”interesting” effects but is extremely difficult to spot.
One question in this context: how do you provide VIN and GND to the 3HCs? With two lines each: PSU -> 3HC, with a common V– line, or V– on the machine’s frame?
But first things first: Commissioning! Please add one 3HC at a time and report your findings.
Good luck,
mb -
@infiniteloop said in Duet 3HC Expansion looses Connection:
@developeralgo222 To summarise, you got all Duets to sync on your test setup? They failed to sync completely when mounted on the PnP machine? You assume the only difference between both setups to be the CAN wiring - which you verified with your Fluke?
At this point, it is safe to state that all Duets (the 6XD and 4x 3HC) work as expected - that’s proven by your test setup.
The only thing that comes to mind is that the Duet CAN Bus might be unreliable and not as tolerant as its expected to be
That’s exactly the single one topic to be ruled out for sure: with its dedicated controllers and a robust protocol, CAN is one of the most reliable communication means, even in harsh environments.
The CAN cables on the PnP machine are tested good, but some issues still may exist: intermitted contact of the connectors, CAN bus termination, topology of your CAN wiring. To properly commission your setup, add one 3HC at a time and verify the sync. If it doesn’t work, replace the cable (temporarily) and check proper termination.
As was the case with the initial fault - missing GND connection between the two PSUs - there might be „hidden“ issues lurking around as well. These are difficult to diagnose from a distance, so we have to rely on you to tell us the potentially relevant facts. One such example that comes to my mind is an improper mix of GND and Earth: this can lead to quite ”interesting” effects but is extremely difficult to spot.
One question in this context: how do you provide VIN and GND to the 3HCs? With two lines each: PSU -> 3HC, with a common V– line, or V– on the machine’s frame?
But first things first: Commissioning! Please add one 3HC at a time and report your findings.
Good luck,
mbI know that CAN BUs protocol itself is very reliable from my expeience. I tested and added one board at a time as per previous posts. I have 2 x PSUs (24V,20A ) connected as per suggestions above & diagram above. Each of the VIN & GND from each 3HC to goes individual terminals pair on the PSUs ( i have 6XD, 3HC1, & 3HC2 on PSU1 and 3HC3 , 3HC4 on PSU2 )
After the test setup , moved everything to PnP Machine. As indicated above i tested each individual expansion 3HC board( 4 boards in total ) with nothing connected to them only power.
6XD --> Board 1 (with CAN Jumpers) CAN_IN / CAN_OUT -- Sync
6XD --> Board 2 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 3 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 4 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
FYI:
NOTE: i know it shouldn't be connected this way and it should not work . The CAN Bus Termination jumpers should only be on the Last 3HC board (which is board 4 in my case) in the Chain but to my surprise when i leave the CAN Bus termination Jumpers on each board and connect them , they sync without any issues
@dc42, @infiniteloop, @droftarts , What's happening here , is this even supposed to work ? Termination on each board in the CAN Bus chain works ?
1/19/2024, 9:51:42 AM: M122 B0: === Diagnostics === RepRapFirmware for Duet 3 MB6XD version 3.5.0-rc.2 (2023-12-14 10:33:00) running on Duet 3 MB6XD v1.01 or later (standalone mode) Board ID: 0JD2M-999AL-D25S0-7J9DA-3SJ6S-T43V2 Used output buffers: 1 of 40 (29 max) === RTOS === Static ram: 153284 Dynamic ram: 117416 of which 0 recycled Never used RAM 72436, free system stack 191 words Tasks: NETWORK(1,ready,167.6%,182) ETHERNET(5,nWait,0.0%,317) HEAT(3,nWait,0.0%,369) Move(4,nWait,0.0%,340) CanReceiv(6,nWait,0.0%,797) CanSender(5,nWait,0.0%,334) CanClock(7,delaying,0.0%,343) MAIN(1,running,349.0%,444) IDLE(0,ready,4.1%,30), total 520.7% Owned mutexes: HTTP(MAIN) === Platform === Last reset 01:58:07 ago, cause: power up Last software reset at 2024-01-18 17:43, reason: User, Gcodes spinning, available RAM 72856, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 MCU temperature: min 25.6, current 41.5, max 42.8 Supply voltage: min 0.3, current 24.0, max 24.7, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 0.1, current 12.2, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/12/12, gc cycles 0 Events: 8 queued, 8 completed Driver 0: ok Driver 1: ok Driver 2: ok Driver 3: ok Driver 4: ok Driver 5: ok Date/time: 2024-01-19 09:51:42 Slowest loop: 10.11ms; fastest: 0.07ms === Storage === Free file entries: 20 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 2.4ms, 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, 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 -1 -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 35524, received 8481, lost 0, errs 64909191, boc 60488 Longest wait 0ms for reply type 0, peak Tx sync delay 17202, free buffers 50 (min 49), ts 35439/1747/0 Tx timeouts 0,0,3438,0,0,0 last cancelled message type 30 dest 127 === Network === Slowest loop: 5.67ms; 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 1 1 0 0 Socket states: 5 2 2 2 2 0 0 0 === Multicast handler === Responder is inactive, messages received 0, responses 0 1/19/2024, 9:51:45 AM: M122 B1: Diagnostics for board 1: Duet EXP3HC rev 1.02 or later firmware version 3.5.0-rc.2 (2023-12-14 08:56:47) Bootloader ID: SAME5x bootloader version 2.4 (2021-12-10) All averaging filters OK Never used RAM 156976, free system stack 194 words Tasks: Move(3,nWait,0.0%,182) HEAT(2,nWait,0.0%,120) CanAsync(5,nWait,0.0%,67) CanRecv(3,nWait,0.0%,80) CanClock(5,nWait,0.0%,70) TMC(2,nWait,5.8%,103) MAIN(1,running,93.1%,399) IDLE(0,ready,0.0%,39) AIN(2,delaying,1.1%,263), total 100.0% Last reset 00:09:46 ago, cause: power up Last software reset data not available Driver 0: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 60274, writes 11 timeouts 0, steps req 0 done 0 Driver 1: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 60275, writes 11 timeouts 0, steps req 0 done 0 Driver 2: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 60275, writes 11 timeouts 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/7, peak Rx sync delay 180, resyncs 1/0, no timer interrupt scheduled VIN voltage: min 24.1, current 24.1, max 24.2 V12 voltage: min 12.4, current 12.4, max 12.4 MCU temperature: min 19.4C, current 28.7C, max 28.7C Last sensors broadcast 0x00000000 found 0 149 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 3092, send timeouts 232, received 1773, lost 0, errs 706207, boc 134, free buffers 38, min 38, error reg ff0000 Last cancelled message type 4511 dest 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0 1/19/2024, 9:51:47 AM: M122 B2: Diagnostics for board 2: Duet EXP3HC rev 1.02 or later firmware version 3.5.0-rc.2 (2023-12-14 08:56:47) Bootloader ID: SAME5x bootloader version 2.4 (2021-12-10) All averaging filters OK Never used RAM 156976, free system stack 194 words Tasks: Move(3,nWait,0.0%,182) HEAT(2,nWait,0.0%,114) CanAsync(5,nWait,0.0%,67) CanRecv(3,nWait,0.0%,80) CanClock(5,nWait,0.0%,70) TMC(2,nWait,5.8%,103) MAIN(1,running,93.1%,391) IDLE(0,ready,0.0%,39) AIN(2,delaying,1.1%,263), total 100.0% Last reset 00:09:49 ago, cause: power up Last software reset data not available Driver 0: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 2629, writes 11 timeouts 0, steps req 0 done 0 Driver 1: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 2630, writes 11 timeouts 0, steps req 0 done 0 Driver 2: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 2631, writes 11 timeouts 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 -7/4, peak Rx sync delay 182, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 24.2, current 24.2, max 24.3 V12 voltage: min 12.3, current 12.4, max 12.4 MCU temperature: min 22.1C, current 32.3C, max 32.3C Last sensors broadcast 0x00000000 found 0 244 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 2486, send timeouts 319, received 1335, lost 0, errs 2290420, boc 2, free buffers 38, min 38, error reg ff0000 Last cancelled message type 4519 dest 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0 1/19/2024, 9:51:50 AM: M122 B3: Diagnostics for board 3: Duet EXP3HC rev 1.02 or later firmware version 3.5.0-rc.2 (2023-12-14 08:56:47) Bootloader ID: SAME5x bootloader version 2.4 (2021-12-10) All averaging filters OK Never used RAM 156976, free system stack 194 words Tasks: Move(3,nWait,0.0%,182) HEAT(2,nWait,0.0%,114) CanAsync(5,nWait,0.0%,67) CanRecv(3,nWait,0.0%,80) CanClock(5,nWait,0.0%,70) TMC(2,nWait,5.8%,103) MAIN(1,running,93.1%,421) IDLE(0,ready,0.0%,39) AIN(2,delaying,1.1%,263), total 100.0% Last reset 00:09:51 ago, cause: power up Last software reset data not available Driver 0: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 12506, writes 11 timeouts 0, steps req 0 done 0 Driver 1: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 12507, writes 11 timeouts 0, steps req 0 done 0 Driver 2: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 12508, writes 11 timeouts 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 -4/5, peak Rx sync delay 178, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 24.2, current 24.2, max 24.2 V12 voltage: min 12.3, current 12.3, max 12.4 MCU temperature: min 21.9C, current 31.1C, max 31.3C Last sensors broadcast 0x00000000 found 0 171 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 2616, send timeouts 303, received 1263, lost 0, errs 1911382, boc 244, free buffers 38, min 38, error reg ff0000 Last cancelled message type 4519 dest 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0 1/19/2024, 9:51:54 AM: M122 B4: Diagnostics for board 4: Duet EXP3HC rev 1.02 or later firmware version 3.5.0-rc.2 (2023-12-14 08:56:47) Bootloader ID: SAME5x bootloader version 2.4 (2021-12-10) All averaging filters OK Never used RAM 156976, free system stack 194 words Tasks: Move(3,nWait,0.0%,182) HEAT(2,nWait,0.0%,114) CanAsync(5,nWait,0.0%,67) CanRecv(3,nWait,0.0%,80) CanClock(5,nWait,0.0%,70) TMC(2,nWait,5.8%,103) MAIN(1,running,93.0%,399) IDLE(0,ready,0.0%,39) AIN(2,delaying,1.1%,263), total 100.0% Last reset 00:09:55 ago, cause: power up Last software reset data not available Driver 0: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 26004, writes 11 timeouts 0, steps req 0 done 0 Driver 1: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 26005, writes 11 timeouts 0, steps req 0 done 0 Driver 2: pos 0, 80.0 steps/mm, standstill, SG min 0, mspos 8, reads 26006, writes 11 timeouts 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 -7/5, peak Rx sync delay 177, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 24.2, current 24.2, max 24.3 V12 voltage: min 10.9, current 12.4, max 12.4 MCU temperature: min 21.9C, current 31.5C, max 31.5C Last sensors broadcast 0x00000000 found 0 235 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 3284, send timeouts 213, received 1169, lost 0, errs 5792377, boc 1162, free buffers 38, min 38, error reg ff0000 Last cancelled message type 4519 dest 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0As per CAN Bus Protocol documentation, The CAN bus must be properly terminated using a 120 Ohms CAN bus termination resistor at each end of the bus.
Looking at the explanations on CAN Bus, The resistance of the CAN bus terminal is usually 120 ohms. Two 60 ohm resistors are linked in series in the design, and there are usually two 120 ohm nodes on the CAN bus. This is how i think of it
-
@developeralgo222 said in Duet 3HC Expansion looses Connection:
Noticing an interesting issue, when i moved the test setup 6XD plus 4x 3HC to the PNP Machine with only Power and CAN Bus Cables connected as before , it doesn't sync at all . The only thing that i changed is the length of the cable from 6XD to 3HC1( from 0.5 ft (shielded ) to 10 ft(shielded) .
Almost certainly the 10ft cable is faulty. Have you checked that it doesn't have crossed connections between the two ends?
@developeralgo222 said in Duet 3HC Expansion looses Connection:
After the test setup , moved everything to PnP Machine. As indicated above i tested each individual expansion 3HC board( 4 boards in total ) with nothing connected to them only power.
6XD --> Board 1 (with CAN Jumpers) CAN_IN / CAN_OUT -- Sync
6XD --> Board 2 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 3 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 4 (with CAN Jumpers) CAN_IN / CAN_OUT -- No SyncDid you use the same cable between the 6XD and the 3HC in all cases?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in Duet 3HC Expansion looses Connection:
@developeralgo222 said in Duet 3HC Expansion looses Connection:
Noticing an interesting issue, when i moved the test setup 6XD plus 4x 3HC to the PNP Machine with only Power and CAN Bus Cables connected as before , it doesn't sync at all . The only thing that i changed is the length of the cable from 6XD to 3HC1( from 0.5 ft (shielded ) to 10 ft(shielded) .
Almost certainly the 10ft cable is faulty. Have you checked that it doesn't have crossed connections between the two ends?
@developeralgo222 said in Duet 3HC Expansion looses Connection:
After the test setup , moved everything to PnP Machine. As indicated above i tested each individual expansion 3HC board( 4 boards in total ) with nothing connected to them only power.
6XD --> Board 1 (with CAN Jumpers) CAN_IN / CAN_OUT -- Sync
6XD --> Board 2 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 3 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 4 (with CAN Jumpers) CAN_IN / CAN_OUT -- No SyncDid you use the same cable between the 6XD and the 3HC in all cases?
Used same cables except 6XD to 3HC1 where i used a longer cable 10ft
-
Termination on each board in the CAN Bus chain works ?
What @dc42 says. To test, throw-in some cheapo telephone lines (RJ11) and terminate CAN properly.
-
@infiniteloop said in Duet 3HC Expansion looses Connection:
Termination on each board in the CAN Bus chain works ?
What @dc42 says. To test, throw-in some cheapo telephone lines (RJ11) and terminate CAN properly.
i will try another cable , probably a phone cable or another ADSL 2+ high speed cable to replace the 10 ft cable from 6XD to 3HC1 and see if that makes a difference .
-
-
@infiniteloop said in Duet 3HC Expansion looses Connection:
@developeralgo222 said in Duet 3HC Expansion looses Connection:
i will try another cable
Great
Made 2 different straight cables which are shielded and 1 std phone cable (Normally crossed, so i cut one end and crimped it to straight cable ).
Cable 1 - Made from CAT 6 Cable (using only 2 pairs for CAN Bus --technically on 2 wires are used) and RJ11 at the ends
Cable 2 - Made from CAT 8 Cable (using only 2 pairs for CAN Bus --technically on 2 wires are used) and RJ11 at the ends
Cable 3 - Made from Std Phone Cable (using only 2 pairs for CAN Bus --technically on 2 wires are used) and RJ11 at the endsAll of them behaved the same when testing each of the 4 x 3HC boards with nothing connected to them only power.
6XD --> Board 1 (with CAN Jumpers) CAN_IN / CAN_OUT -- Sync
6XD --> Board 2 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 3 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
6XD --> Board 4 (with CAN Jumpers) CAN_IN / CAN_OUT -- No Sync
Not sure why CAN Bus would be this unreliable. For sure i checked the cables , tested them using a different cable tester ( Sperry ) this time to rule out anything. i don't think its the cables after this round of tests
-
@developeralgo222 something to do with the mounting? You have them stacked, using what looks like electrically conductive standoffs. I don’t know if that connects the grounds of the boards at a point that causes problems, rather than at the PSUs. You could try powering all four boards (or all boards) from one PSU, see if that makes a difference.
Ian
-
@droftarts said in Duet 3HC Expansion looses Connection:
@developeralgo222 something to do with the mounting? You have them stacked, using what looks like electrically conductive standoffs. I don’t know if that connects the grounds of the boards at a point that causes problems, rather than at the PSUs. You could try powering all four boards (or all boards) from one PSU, see if that makes a difference.
Ian
Hmmm!!! i don't think so unless the boards themselves have Power rail circuit layer (copper) touching the mounting holes . That would be really really bad. When i did the Test setup they were separated (Not mounted) although still on Brass standoffs. Your thought might be something to investigate , i will check that and try Nylon standoffs
-
@developeralgo222 said in Duet 3HC Expansion looses Connection:
Not sure why CAN Bus would be this unreliable.
It's not about CAN - I've built several applications for constructing machinery from the ground up, connecting controllers via CAN, and these connections are rock-solid. This said, I am now convinced that we can rule out your CAN wiring as cause of the problem. Which leads me to believe we might face an effect which I described as "interesting" early on: some interference between GND and Earth.
In your test setup, the boards were strictly isolated from Earth (which was just connected to the two PSUs). Earth is received from the electrical outlets and internally connected with the metal cases of the PSUs. In addition, the metal parts of you PnP machine should be "earthed" as well. The one million dollar question now is: have GND and Earth any potential contact? Or are they maybe decisively synced somewhere?
The latter case is something I've done myself, but is not without pitfalls, so I'd like to ask @droftarts for a second opinion. At least, he's on the same trail …
-
@infiniteloop said in Duet 3HC Expansion looses Connection:
@developeralgo222 said in Duet 3HC Expansion looses Connection:
The one million dollar question now is: have GND and Earth any potential contact? Or are they maybe decisively synced somewhere?The latter case is something I've done myself, but is not without pitfalls, so I'd like to ask @droftarts for a second opinion. At least, he's on the same trail …
Today, I have isolated all the PSUs and all are “Earthed” ( AC Ground ) . They don’t touch the aluminum metal table at all anywhere. I will also “Earth” (AC ground ) the aluminum metal table today.
Is there anything I might be forgetting on this GND solution. I am trying to avoid creating GND loops
-
Is there anything I might be forgetting on this GND solution. I am trying to avoid creating GND loops
That’s complex. As a general rule, imagine a star topology, I.e. for each and every voltage, there should be a single point (or rail) from where to further route the power lines.
For your dual PSUs, you already have this central point: V+ (1 rail with 3 connectors on each PSU) is now interconnected as discussed above in this thread.
Now, if you connect GND (of the DC-output) to Earth, do it at a single point as well. Think of it as a common rail where all GND lines meet - kind of a ”local Earth”. Don’t take GND or V– from distant parts of the frame. Aside from the common rail, consider them as not being the same.
Voltage lines may be split or chained on their run, but may then never refer to another source of the same voltage again (that’s a loop). You often run into this trap with shielded lines: the shield carries GND (or, in some cases, V–), but if you supply GND from both ends, you might involuntarily establish a ground loop. The golden rule here is to always feed GND from the origin - leave it unconnected at the destination end.
The fact that most devices in your machine are controlled via V– complicates things. All switched V– lines from the DUETs may never have contact with the ”local Earth”, GND or any other V–.
Grounding the PnP machine is another topic: not all metal parts are always in touch with each other, there are potential isolators such as coatings, belts or lubricants in the way, some parts are clearly isolated by design (printed joints etc). Short cable bridges help in some cases, but for moving parts, you might need to route a dedicated GND line through your cable chain.
Considering USB ground loops, I recommend this article from the documentation: USB ground loops
-
@developeralgo222 have you confirmed that the wires are not crossed between the ends of the 10ft cable? Your cable tester might not detect that. See https://docs.duet3d.com/en/User_manual/Machine_configuration/CAN_connection#example-of-a-good-cable and the photo after that.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in Duet 3HC Expansion looses Connection:
@developeralgo222 have you confirmed that the wires are not crossed between the ends of the 10ft cable? Your cable tester might not detect that. See https://docs.duet3d.com/en/User_manual/Machine_configuration/CAN_connection#example-of-a-good-cable and the photo after that.
Yes i double checked that . i was suspecting that it might be the case but no. Cable tester that i use checks for all kinds of errors on cable from crossed , shorts , reversed, miswires, continuity, shield , etcs i have used various Fluke professional Cable testers for over 20 years and they have never failed, so i am confident when after all testing it says the cable is good, then its good.
They are Straight through cable (Left to right ) and on both ends
- Blue, Blue-white, Orange, Orange-white
Technically , in this case , Blue-White and Orange wires are used by CAN Bus connection in Duet Boards
-
@developeralgo222 i don’t know if this matters that much for a short cable, but wires of the same colour, ie blue and white-with-blue-stripe, make up the twisted pair. These should be wired to the centre two pins that Duet use for CAN. The other pair goes on the pins outside these. You’re using one wire from each twisted pair.
Ian
-
@droftarts said in Duet 3HC Expansion looses Connection:
@developeralgo222 i don’t know if this matters that much for a short cable, but wires of the same colour, ie blue and white-with-blue-stripe, make up the twisted pair. These should be wired to the centre two pins that Duet use for CAN. The other pair goes on the pins outside these. You’re using one wire from each twisted pair.
Ian
Let me try it . i have tried almost everything Grounding, and everything in between that has been suggested but to no avail. Sometimes its usually the smallest thing that creates a nightmare.
-
@developeralgo222 said in Duet 3HC Expansion looses Connection:
@droftarts said in Duet 3HC Expansion looses Connection:
@developeralgo222 i don’t know if this matters that much for a short cable, but wires of the same colour, ie blue and white-with-blue-stripe, make up the twisted pair. These should be wired to the centre two pins that Duet use for CAN. The other pair goes on the pins outside these. You’re using one wire from each twisted pair.
Ian
Let me try it . i have tried almost everything Grounding, and everything in between that has been suggested but to no avail. Sometimes its usually the smallest thing that creates a nightmare.
Didn't make a difference at all .
I have tried every kind of Cable connection as per the requirement but there is no reliable sync of CAN connection. I don't believe i am the only one who is building a PnP or a 3D printer that is encountering this issue. i have worked with various kinds of connections and boards but have never encountered such an issue with CAN Bus.
Can't Sync 3HC boards no matter the cable. Have used the documentation to double check everything. Remake the cables and test them. Not sure if it might actually be a Duet 3 3HC Hardware issue that is causing this ?
-
@developeralgo222 said in Duet 3HC Expansion looses Connection:
Twisted pair cables terminated in RJ11 connectors are sold in some countries as "High Speed ADSL cables". One supplier of such cables is Kenable. Note, ADSL and telephone cables made with flat wire often cross the connections, making them unsuitableThe price of kenable cables in US is so expensive while in UK they are extremely cheap. Can anyone point me to a link on Amazon or ebay for cable that works with Duet 3HC or 6XD CAN Bus without me cutting and remaking it, and is affordable
-
@developeralgo222 I'm sorry you're having so many problems with this. It really shouldn't be this difficult, and it has us foxed as well! Maybe the best option is to return to the last known working configuration, which was as a bench setup.
For cables in the USA on Amazon, these look like the correct ones: https://www.amazon.com/Kenable-Speed-Broadband-Modem-Cable/dp/B011SS7LYU
Ian
