Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Toolboard 1LC won't connect to Mini 5+ through CAN

    Scheduled Pinned Locked Moved
    Duet Hardware and wiring
    3
    7
    292
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • nmsmith89undefined
      nmsmith89
      last edited by nmsmith89

      I'm at my wits end...

      My Toolboard 1LC that I've had for a while and has worked through multiple rewires will not connect after rewiring the printer. It blinks rapidly indicating no CAN connection; CAN timeout error in console; Toolboard reset gives 4 blinks (no connection).

      After trying pretty much everything I'm reaching out here. I have programming and PCB design experience so I know (for the most part) what I'm doing and I've been able to rule out some things.

      As far as I can tell (see below) the CAN cable is electrically connected. The only things I can think of is either there's a decoupling cap or maybe inductor or something that was blown/shorted or I'm missing something really stupid. I haven't had the patience to go through each board probing components.

      Please help!
      Thanks in advance!

      ~ Neil

      Thing I've tried

      • M115 B121
      • Firmware upgrade
        • to latest beta
      • Firmware downgrade
        • to v3.4.6
      • Verified CAN_H to CAN_H connection and vice versa
      • Alternate cable
        • Power & CAN - self crimped - 110Ω termination.
      • Alternate short cable
        • Power & CAN - self crimped - 110Ω termination.
      • Toolboard double button reset
      • PCB inspection
        • No visible flaws on either boards.
        • Fuses & crystals seem OK
      • Multimeter testing
        • Continuity & resistance
        • Tested cable as well as at the connector header solder joints (only on the Toolboard end since I didn't feel like unmounting the mainboard yet).

      Specs & Diagnostics

      Printer:

      • RatRig V-Core 3.1

      Hardware:

      • Duet 3 Mini 5+ - V1.0
      • Duet 3 Toolboard 1LC - V1.0

      M122:

      Note: Motors not hooked up to mainboard and nothing hooked up to Toolboard.

      === Diagnostics ===
      RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-beta.4 (2023-06-08 23:40:14) running on Duet 3 Mini5plus WiFi (SBC mode)
      Board ID: 524WM-Y296U-D65J0-40KM8-MB03Z-HJSAK
      Used output buffers: 1 of 40 (17 max)
      Error in macro line 6 while starting up: M569: Response timeout: CAN addr 121, req type 6018, RID=0
      === RTOS ===
      Static ram: 102996
      Dynamic ram: 109084 of which 24 recycled
      Never used RAM 27096, free system stack 208 words
      Tasks: SBC(2,ready,1.5%,381) HEAT(3,nWait,0.0%,331) Move(4,nWait,0.0%,358) CanReceiv(6,nWait,0.0%,939) CanSender(5,nWait,0.0%,337) CanClock(7,delaying,0.0%,342) TMC(4,nWait,1.2%,116) MAIN(2,running,94.9%,792) IDLE(0,ready,1.6%,29) AIN(4,delaying,0.8%,266), total 100.0%
      Owned mutexes: HTTP(MAIN)
      === Platform ===
      Last reset 00:22:33 ago, cause: software
      Last software reset at 2023-08-06 02:00, reason: User, Expansion spinning, available RAM 28924, slot 2
      Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00487000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
      Error status: 0x00
      MCU revision 3, ADC conversions started 1354002, completed 1354000, timed out 0, errs 0
      MCU temperature: min 28.8, current 29.5, max 30.8
      Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
      Heap OK, handles allocated/used 99/28, heap memory allocated/used/recyclable 2048/1044/500, gc cycles 0
      Events: 0 queued, 0 completed
      Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 57525, writes 10, timeouts 0, DMA errors 0, CC errors 0
      Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
      Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
      Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
      Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
      Driver 5: standstill, SG min 0, read errors 0, write errors 1, ifcnt 58, reads 57520, writes 14, timeouts 0, DMA errors 0, CC errors 0
      Driver 6: standstill, SG min 0, read errors 0, write errors 1, ifcnt 42, reads 57524, writes 10, timeouts 0, DMA errors 0, CC errors 0
      Date/time: 2023-08-09 23:13:56
      Cache data hit count 2827400447
      Slowest loop: 3.84ms; fastest: 0.12ms
      === Storage ===
      Free file entries: 20
      SD card 0 not detected, interface speed: 0.0MBytes/sec
      SD card longest read time 0.0ms, write time 0.0ms, max retries 0
      === Move ===
      DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
      no step interrupt scheduled
      === 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, chamber heaters -1 -1 -1 -1, ordering errs 0
      === GCodes ===
      Movement locks held by null, null
      HTTP* is doing "M122" 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 0x0000803
      Code queue 0 is empty
      Q1 segments left 0, axes/extruders owned 0x0000000
      Code queue 1 is empty
      === CAN ===
      Messages queued 12108, received 0, lost 0, boc 0
      Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 17), ts 6770/0/0
      Tx timeouts 0,0,6769,16,0,5320 last cancelled message type 4514 dest 127
      === SBC interface ===
      Transfer state: 5, failed transfers: 0, checksum errors: 0
      RX/TX seq numbers: 57485/57485
      SPI underruns 0, overruns 0
      State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0d484
      Buffer RX/TX: 0/0-0, open files: 0
      === Duet Control Server ===
      Duet Control Server version 3.5.0-beta.4 (2023-06-09 10:49:49)
      Code buffer space: 4096
      Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
      Full transfers per second: 42.59, max time between full transfers: 4967.0ms, max pin wait times: 2358.8ms/17.3ms
      Codes per second: 0.19
      Maximum length of RX/TX data transfers: 4431/804
      
      JoergS5undefined deckingmanundefined 2 Replies Last reply Reply Quote 0
      • JoergS5undefined
        JoergS5 @nmsmith89
        last edited by

        @nmsmith89 hello, I propose you publish the main config files also, in case you changed there something without remembering, or something like the time delay is missing. As first step you can macro call config.g to see whether you inserted a syntax error.

        nmsmith89undefined 1 Reply Last reply Reply Quote 0
        • deckingmanundefined
          deckingman @nmsmith89
          last edited by

          @nmsmith89 Try swapping the two CAN wires on the tool board. I had the same problem and found that the instructions were a little ambiguous. Swapping the can wires fixed it for me.

          Ian
          https://somei3deas.wordpress.com/
          https://www.youtube.com/@deckingman

          1 Reply Last reply Reply Quote 0
          • nmsmith89undefined
            nmsmith89 @JoergS5
            last edited by

            @JoergS5
            I have the config file broken up into a bunch of M98 calls to keep things organized but it makes it a little hard to post.

            All of the up-to-date config files can be found on my GitHub repo.

            If it makes it easier I also wrote a python script to condense it all into a single file so let me know if you'd like me to post that.


            @deckingman
            I Just tried that and no change.

            JoergS5undefined 3 Replies Last reply Reply Quote 0
            • JoergS5undefined
              JoergS5 @nmsmith89
              last edited by

              @nmsmith89 thanks for the link to github, this is an impressive organization. You're right, it's hard to analyze, but I didn't find an error.

              During searching, I had the following ideas, which may all be nonsense:

              • maybe the address of the board is changed
              • v1.0 of the toolboard may have a problem with current firmware
              • if the config has a problem, creating a very simple one just to check the toolboard connection
              • last resort would maybe to debug the toolboard through SWD. This is of course very elaborate
              1 Reply Last reply Reply Quote 0
              • JoergS5undefined
                JoergS5 @nmsmith89
                last edited by JoergS5

                @nmsmith89 you can also try M115 B10, which documentation tells to try as alternative if B121 doesn't work.

                source: https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Toolboard_1LC#testing-communication

                1 Reply Last reply Reply Quote 0
                • JoergS5undefined
                  JoergS5 @nmsmith89
                  last edited by

                  @nmsmith89 the comment of David https://forum.duet3d.com/topic/32343/response-timeout-can-addr-121-while-bed-mapping that ground must be shared if two separate PSUs are used may also be a reason.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Unless otherwise noted, all forum content is licensed under CC-BY-SA