Dual 6HC not connecting via CAN and DWC won't update

[aetherialdesign]

Hi,
We’re currently commissioning the firmware and configuration for a large IDEX machine that utilizes two Duet 6HC v1.01 boards in SBC mode (required due to connectivity constraints). Here’s a breakdown of the setup:

• Primary 6HC: Controls 4 Y motors and 2 X motors and most peripherals.
• Secondary 6HC: Connected via CAN-FD, handles 2 extruders and 3 Z motors.

During the commissioning process, we’ve encountered a couple of issues:

1. CAN Connection Failure for Secondary 6HC

The secondary 6HC is not completing the CAN connection despite the following:

• Voltage lights are on, and the status lights are blinking on both boards.
• The SD card in the secondary board contains:
  /firmware folder with Duet3_CANiap32_MB6HC.bin.
  /sys folder with a single M954 A1 command in a config.g file (based on the documentation).

Are there additional steps or settings required to ensure the secondary 6HC connects via CAN successfully?

For reference, I’ve attached a basic bare-bones config file:
config.g

2. Firmware and DWC Version Mismatch

We are receiving critical errors for software mismatch versions.
When reviewing DWC we had the board and DSF firmware on 3.5.4 except DWC which was stuck on 3.5.3.
Attempting to update via sudo apt update and sudo apt upgrade did not fix this.
We then attempted several versions of the M997 command to get an update -> none stuck.
We then attempted to adopt the 3.6 beta 3 firmware via M997 -> this did not stick but DWC in the browser now showed it was on 3.5.4

Later, after a power cycle -> all firmwares were suddenly displaying as 3.6 beta 3; error stopped presenting itself.
However, after another power cycle -> DWC was back down to 3.5.3 again while the main 6HC and DSF were on 3.6 beta 3.

Looking for some assistance as to what may be going on here.
Previously these boards had been flashed to Kalico for other single tool builds but due to the inane way Klipper handles IDEX -> it was decided to re-adopt RRF. We followed the typical ERASE jumper and reset to get the boards back into programming mode and wipe out what was on them -> then reflashed via usb connection to RRF 3.5.4

Side Quest note: Docs specify the SZP keep out zone is 30mm...how strict is that? When this machine was on Kalico it was running a Beacon which is about 18mm below the all metal toolhead -> technically in Beacon's keep out zone but functionality was 'fine'

[jay_s_uk]

@aetherialdesign sounds like a browser cache issue. Clear the cache then see if it's now reporting the correct dwc version

[dc42]

@aetherialdesign regarding the CAN connection, most likely it's a problem with the cable. Check that the wires are not crossed between the two ends. Also check that both boards are actually running the same firmware version. Putting the firmware on the SD card is not sufficient, it needs to be installed.

[aetherialdesign]

@jay_s_uk said in Dual 6HC not connecting via CAN and DWC won't update:

@aetherialdesign sounds like a browser cache issue. Clear the cache then see if it's now reporting the correct dwc version

Bingo! Didn't even think to check caching. Incognito returned expected results while normal browser still reported 3.5.3. Cleared cache and versioning is right now. One headache down!

@dc42 said in Dual 6HC not connecting via CAN and DWC won't update:

@aetherialdesign regarding the CAN connection, most likely it's a problem with the cable. Check that the wires are not crossed between the two ends. Also check that both boards are actually running the same firmware version. Putting the firmware on the SD card is not sufficient, it needs to be installed.

Cable is the kernable that comes with the Duets. Was pulled off a working toolchanger, however, I've got some replacements coming in later this afternoon to test. Regarding firmware -> both boards were flashed with the same 3.5.4 files via BOSSA back to back. Although now that everything else is on 3.6 beta 3 I expect I need to go back and manually flash the 2nd board to this.

[droftarts]

@aetherialdesign You can connect a serial terminal via USB to the 6HC-as-expansion board, to check that it is in expansion board mode (send M122) and CAN address (send M954). The version mismatch shouldn't stop it connecting.

Do the red STATUS LEDs blink in time, or does one blink fast? See https://docs.duet3d.com/en/User_manual/Machine_configuration/CAN_connection#led-behaviour-and-error-codes

The red LED behaviour is:

• Flashing once per second, in time with the red STATUS or DIAG LED on the main board: operating normally, in CAN communication with the main board
• Flashing continuously and rapidly: board is running but does not have CAN communication with the main board

Ian

[aetherialdesign]

@droftarts

I reflashed the 2nd board to 3.6 beta3 to align with the auto update done on the rest of the system -> no results.
Like before -> status lights blink in unison but lacked connection when querying with a M115 B1

So on a whim I put the FULL folder directories, as if this were the mainboard, with all files onto the SD card for the 2nd board and merely added the Duet3_CANiap32_MB6HC.bin file to the list of files in /firmware and then wiped out the config.g to only have the M954 A1 command. These 2 folders and 2 files were in place prior but with no other directories or files.
CAN is now connected as expected.

@dc42
I think the documentation for connecting mainboard as a CAN board expansion could clarify this a bit as it currently implies you only need those two directories with the 1 file in each of them -> which apparently is not the case. Dumb mistake on my end again.

[jay_s_uk]

@aetherialdesign thats odd as i've definitely ran expansion board mode purely with those 2 files you mentioned. having a full config in there is going to screw things up I would suggest

[jay_s_uk]

@aetherialdesign i'm assuming you put the barebones config.g in a folder called sys?

[aetherialdesign]

@jay_s_uk
Yes, config.g with just M954 A1 was in /sys and the firmware file for CAN was in /firmware on previous attempts.
On this latest attempt same thing, except, I left all other files and folders in place.

[aetherialdesign]

Followup -> something wonky must've happened I reckon.
Backed up the newly working setup and went through and reset it back to the way Docs specify and now it works.
Same files I've used all along (copy/paste)

I won't question the gremlins in the hardware, its working now.

[droftarts]

@aetherialdesign Is this a different SD card? Maybe there was an issue reading the first SD card. I currently have a setup of two Mini 5+ boards and a 1LC. The Mini 5+ as-expansion has only a firmware folder with the iap file in it (and a couple of firmware binaries) and a sys folder with the config.g that sets CAN address only, so no, no other files are needed.

Ian

[aetherialdesign]

Same SD card; -> I did leave the other firmware binaries on the /firmware directory this time since that seemed harmless.
Its possible my adapter/reader corrupted something on previous attempts -> this time I did it through a laptop with reader built in.

[dc42]

@aetherialdesign if you haven't already done so, make sure there is a delay command (e.g. G4 S2) near the start of the main board config.g file, before any command that refers to the expansion board. This is to make sure that the expansion board has time to start up and switch into expansion mode before the main board tries to communicate with it.