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

    SPI connection lost - broken DUET3 6hc ?

    Scheduled Pinned Locked Moved
    General Discussion
    5
    16
    538
    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.
    • IndeX4Dundefined
      IndeX4D @chrishamm
      last edited by IndeX4D

      @chrishamm
      I used a different (and working on other printer) Raspberry, cable for power the pi, Ribbon Cable, 3 different sd cards.
      No change.... I also used the updatet version of duetPi and the older ones which came out in january ( the experimental boomwork). Can you please tell me which I should use? Raspberry pi 5....

      ESD? The backside of the duet 6HC looks fine. Or where should i look. I also recognized, that after long power OFF, the printer is resetting in a slower way and one time I could home.
      But when I want to make a prompt, it gets worst.

      I´m going to print in standalone mode, now. I´ll report.

      I got my board a few weeks ago from Dold-Mechatronik.com

      Phaedruxundefined 1 Reply Last reply Reply Quote 0
      • IndeX4Dundefined
        IndeX4D @Phaedrux
        last edited by

        @Phaedrux When I try to connect with YAT .,.... not possible.

        f70d6180-dc67-45dc-bab0-7ed89983287b-image.png

        1 Reply Last reply Reply Quote 0
        • Phaedruxundefined
          Phaedrux Moderator @IndeX4D
          last edited by

          @IndeX4D said in SPI connection lost - broken DUET3 6hc ?:

          I got my board a few weeks ago from Dold-Mechatronik.com

          Please send an email to warranty@duet3d.com and CC your reseller. Include a link to this forum thread and the details of your original purchase. You'll receive a reply with a form to fill out.

          Z-Bot CoreXY Build | Thingiverse Profile

          1 Reply Last reply Reply Quote 0
          • IndeX4Dundefined
            IndeX4D @Phaedrux
            last edited by IndeX4D

            @Phaedrux

            Edit: sorry, I haven´t seen your post. Still a case of warranty?
            thanks

            While DWC is ´´disconnectedt´´ , I could make a M122.
            Strangely, after reflashing the image, the printer is starting quiet normal till the first prompts```
            M122
            === Diagnostics ===
            RepRapFirmware for Duet 3 MB6HC version 3.5.1 (2024-04-19 14:30:55) running on Duet 3 MB6HC v1.02 or later (SBC mode)
            Board ID: 08DLM-9K6R1-L83T8-6J1F6-3S46P-1FJTN
            Used output buffers: 1 of 40 (2 max)
            === RTOS ===
            Static ram: 155208
            Dynamic ram: 85688 of which 0 recycled
            Never used RAM 105096, free system stack 204 words
            Tasks: SBC(2,ready,0.3%,652) HEAT(3,nWait 6,0.0%,363) Move(4,nWait 6,0.0%,336) CanReceiv(6,nWait 1,0.0%,797) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,351) TMC(4,nWait 6,9.0%,56) MAIN(2,running,90.3%,444) IDLE(0,ready,0.4%,30), total 100.0%
            Owned mutexes: HTTP(MAIN)
            === Platform ===
            Last reset 00:00:33 ago, cause: power up
            Last software reset at 2024-05-03 21:13, reason: User, Gcodes spinning, available RAM 94648, slot 0
            Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
            Error status: 0x00
            MCU temperature: min 43.3, current 44.3, max 44.3
            Supply voltage: min 24.1, current 24.2, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
            12V rail voltage: min 12.2, current 12.3, max 12.4, under voltage events: 0
            Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
            Events: 0 queued, 0 completed
            Driver 0: standstill, SG min n/a, mspos 8, reads 51700, writes 11 timeouts 0
            Driver 1: standstill, SG min n/a, mspos 8, reads 51701, writes 11 timeouts 0
            Driver 2: standstill, SG min n/a, mspos 8, reads 51701, writes 11 timeouts 0
            Driver 3: standstill, SG min n/a, mspos 8, reads 51701, writes 11 timeouts 0
            Driver 4: standstill, SG min n/a, mspos 8, reads 51701, writes 11 timeouts 0
            Driver 5: standstill, SG min n/a, mspos 8, reads 51701, writes 11 timeouts 0
            Date/time: 1970-01-01 00:00:00
            Slowest loop: 0.21ms; fastest: 0.06ms
            === Storage ===
            Free file entries: 20
            SD card 0 not detected, interface speed: 37.5MBytes/sec
            SD card longest read time 0.0ms, 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 -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 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 0x0000000
            Code queue 0 is empty
            Q1 segments left 0, axes/extruders owned 0x0000000
            Code queue 1 is empty
            === CAN ===
            Messages queued 166, received 928, lost 0, errs 1, boc 0
            Longest wait 0ms for reply type 0, peak Tx sync delay 68, free buffers 50 (min 50), ts 166/165/0
            Tx timeouts 0,0,0,0,0,0
            === SBC interface ===
            Transfer state: 5, failed transfers: 1, checksum errors: 4
            RX/TX seq numbers: 1389/1303
            SPI underruns 3, overruns 3
            State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x253c0
            Buffer RX/TX: 0/0-0, open files: 0
            === Duet Control Server ===
            Duet Control Server version 3.5.1 (2024-04-19 16:23:47, 64-bit)
            HTTP+Executed:

            Executing M122
            Trigger:
            Buffered code: M950 H0 C"out0" T0 ; create bed heater output on out0 and map it to sensor 0
            Buffered code: M140 H0
            Buffered code: M307 H0 R0.468 K0.275:0.000 D19.70 E1.35 S1.00 B0 ; disable bang-bang mode for the bed heater and set PWM limit
            Buffered code: M143 H0 S120
            Buffered code: M308 S1 P"temp1" Y"pt1000" T100000 B4138 ; configure sensor 1 as PT1000 on pin 121.temp0
            Buffered code: M950 H1 C"out1" T1 ; create nozzle heater output on out1 and map it to sensor 1
            Buffered code: M307 H1 R6.672 K0.682:0.000 D2.57 E1.35 S1.00 B0 V23.3 ; disable bang-bang mode for heater and set PWM limit
            Buffered code: M143 H1 S260
            Buffered codes: 480 bytes total

            Doing macro config.g, started by system
            Code buffer space: 4096
            Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
            Full transfers per second: 7.54, max time between full transfers: 771.1ms, max pin wait times: 257.0ms/499.8ms
            Codes per second: 0.98
            Maximum length of RX/TX data transfers: 3284/808

            1 Reply Last reply Reply Quote 0
            • IndeX4Dundefined
              IndeX4D
              last edited by

              hey,
              sadly I have the same Problem with the new board.
              I tried different raspberrys.
              It´s quiet strange that I could print 2 or 3 times. When I wanted to print next day after switch off, the printer is stuck in the error loop.
              How can It change so crazy. Working one day, next day broke till maybe 2 hours later it´s suddenly working..?!
              I need some help.
              All other printers are running completely fine.
              00aa273e-8933-4014-863c-566e8da48944-image.png

              jay_s_ukundefined 1 Reply Last reply Reply Quote 0
              • jay_s_ukundefined
                jay_s_uk @IndeX4D
                last edited by

                @IndeX4D that error is nothing to do with SPI. It tells you theres an issue with the CAN connection to your other boards

                Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                IndeX4Dundefined 1 Reply Last reply Reply Quote 0
                • IndeX4Dundefined
                  IndeX4D @jay_s_uk
                  last edited by

                  @jay_s_uk
                  ok thank you.
                  the topic is almost 0ne year old, sorry

                  Funny fact. I had to return the last board because of that problem.
                  Thanks a lot
                  Is there a way to finf out more about the problems?

                  jay_s_ukundefined 1 Reply Last reply Reply Quote 0
                  • jay_s_ukundefined
                    jay_s_uk @IndeX4D
                    last edited by

                    @IndeX4D i guess its a wiring issue

                    Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                    IndeX4Dundefined 2 Replies Last reply Reply Quote 0
                    • IndeX4Dundefined
                      IndeX4D @jay_s_uk
                      last edited by

                      @jay_s_uk
                      Probably... but between the can connections?
                      I have this expensive shielded cables...
                      let me check!

                      1 Reply Last reply Reply Quote 0
                      • IndeX4Dundefined
                        IndeX4D @jay_s_uk
                        last edited by

                        @jay_s_uk
                        I disconnected the can cable from the mainboard and I have still the same problem.
                        Can it still be a wiring problem. I think it can´t be?
                        08339aa4-83de-43ae-b785-f30b6825d6a2-image.png

                        jay_s_ukundefined droftartsundefined 2 Replies Last reply Reply Quote 0
                        • jay_s_ukundefined
                          jay_s_uk @IndeX4D
                          last edited by

                          @IndeX4D post a photo of the connection between the mainboard and the pi

                          Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                          1 Reply Last reply Reply Quote 0
                          • droftartsundefined
                            droftarts administrators @IndeX4D
                            last edited by

                            @IndeX4D For "Timeout while waiting for transfer ready pin" errors, see https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup#troubleshooting

                            This error, reported in the DWC console, is usually caused by:

                            • Other wires running too close to the ribbon cable, creating interference. Heater and motor wires can be particularly noisy, route them as far away as possible.
                            • Ribbon cable too long, damaged or poorly connected. Check installation of ribbon cable. Ribbon cable should ideally be not longer than 150mm.
                            • Signal reflections have been reported by one user. This may have been caused by a ribbon cable that was too long, or damaged.

                            Ian

                            Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

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