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

    Duet 3 +SBC : Print randomely freeze when runin my script on RPI

    Scheduled Pinned Locked Moved Solved
    Beta Firmware
    4
    19
    1.0k
    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.
    • Phaedruxundefined
      Phaedrux Moderator @Donpi
      last edited by

      @Donpi said in Duet 3 +SBC : Print randomely freeze when runin my script on RPI:

      How can I switch to 3.2.0-b4.1 ?

      You'd have to switch to the unstable branch and then update.

      https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Software_Installation

      Z-Bot CoreXY Build | Thingiverse Profile

      1 Reply Last reply Reply Quote 1
      • Donpiundefined
        Donpi
        last edited by

        It crash the print even with the 3.2.0-b4.1

        here is my M122

        M122
        === Diagnostics ===
        RepRapFirmware for Duet 3 MB6HC version 3.2-beta4.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
        Board ID: 08DJM-956BA-NA3TN-6JTDG-3SD6J-TABLT
        Used output buffers: 4 of 40 (15 max)
        === RTOS ===
        Static ram: 123292
        Dynamic ram: 137988 of which 36 recycled
        Never used RAM 130876, free system stack 188 words
        Tasks: Linux(ready,77) HEAT(blocked,297) CanReceiv(blocked,947) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,49) MAIN(running,1161) IDLE(ready,19)
        Owned mutexes: HTTP(MAIN)
        === Platform ===
        Last reset 00:25:28 ago, cause: software
        Last software reset at 2020-12-09 15:50, reason: HeatTaskStuck, GCodes spinning, available RAM 130188, slot 0
        Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0x00000000 SP 0x20410144 Task MAIN
        Stack: 2042328c 00429512 81000000 00000000 3e958000 00000000 4079a000 401fc5e4 3f9ca0f0 4530c6d9 4530c6d9 44b0c6d9 49371b00 37533333 43d697a0 00000000 42117d81 3f800000 00000000 60000011 20426c58 2040e0b4 20426c58 00000000 20423af8 00000080 a5a5a5a5
        Error status: 0x00
        MCU temperature: min 35.1, current 37.4, max 37.6
        Supply voltage: min 24.8, current 25.0, max 25.0, under voltage events: 0, over voltage events: 0, power good: yes
        12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
        Driver 0: position 0, standstill, reads 12980, writes 14 timeouts 0, SG min/max 0/0
        Driver 1: position 0, standstill, reads 12981, writes 14 timeouts 0, SG min/max 0/0
        Driver 2: position 0, standstill, reads 12980, writes 15 timeouts 0, SG min/max 0/0
        Driver 3: position 0, standstill, reads 12981, writes 15 timeouts 0, SG min/max 0/0
        Driver 4: position 0, standstill, reads 12983, writes 14 timeouts 0, SG min/max 0/0
        Driver 5: position 0, standstill, reads 12987, writes 11 timeouts 0, SG min/max 0/0
        Date/time: 2020-12-09 16:16:44
        Slowest loop: 4.12ms; fastest: 0.12ms
        === Storage ===
        Free file entries: 10
        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 ===
        FreeDm 375 (min 375), maxWait 0ms, bed compensation in use: none, comp offset 0.000
        === MainDDARing ===
        Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
        === AuxDDARing ===
        Scheduled moves 0, completed moves 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, chamberHeaters = -1 -1 -1 -1
        === GCodes ===
        Segments left: 0
        Movement lock held by 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
        Code queue is empty.
        === CAN ===
        Messages queued 6111, send timeouts 13750, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 47
        === SBC interface ===
        State: 0, failed transfers: 0
        Last transfer: 19ms ago
        RX/TX seq numbers: 15632/53872
        SPI underruns 0, overruns 0
        Number of disconnects: 0, IAP RAM available 0x209d8
        Buffer RX/TX: 0/0-0
        === Duet Control Server ===
        Duet Control Server v3.2.0-beta4
        Code buffer space: 4096
        Configured SPI speed: 8000000 Hz
        Full transfers per second: 1.96
        
        1 Reply Last reply Reply Quote 0
        • Donpiundefined
          Donpi
          last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • Donpiundefined
            Donpi
            last edited by

            The duet stop printing but the script continue

            1 Reply Last reply Reply Quote 0
            • chrishammundefined
              chrishamm administrators
              last edited by

              Many thanks for reporting this, I've just reproduced and fixed this problem. It will be fixed in the next version.

              Duet software engineer

              1 Reply Last reply Reply Quote 0
              • Donpiundefined
                Donpi
                last edited by

                Are there come log that I can check to see what is appening in the Duet ?
                Or what gcode is effetively executed .

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

                  There is this: https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M929_Start_stop_event_logging_to_SD_card

                  And this: https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Monitoring_optional

                  Z-Bot CoreXY Build | Thingiverse Profile

                  1 Reply Last reply Reply Quote 1
                  • chrishammundefined
                    chrishamm administrators
                    last edited by

                    TBH I had some problems with your plugin but I've got a fix ready - at least I haven't been able to reproduce it with the latest dev version. This problem only showed up when two G/M/T-codes from two different G-code channels were frequently sent.

                    To work-around this problem try to send your M106 code to the File channel (that's the same channel used for file prints) and consider adding a delay (e.g. await Task.Delay(1000);) after it. The second parameter of PerformSimpleCode lets you choose the target channel.

                    Duet software engineer

                    Donpiundefined 2 Replies Last reply Reply Quote 1
                    • Donpiundefined
                      Donpi @chrishamm
                      last edited by

                      @chrishamm Great, I'll test that today.

                      I thought I was abandoned alone with my problem 👍

                      1 Reply Last reply Reply Quote 0
                      • Donpiundefined
                        Donpi @chrishamm
                        last edited by

                        @chrishamm said in Duet 3 +SBC : Print randomely freeze when runin my script on RPI:

                        await Task.Delay(1000);

                        The workaround seems to work but it gives me many "Error parsing response" in the PanelDuet console

                        1 Reply Last reply Reply Quote 0
                        • chrishammundefined
                          chrishamm administrators
                          last edited by

                          @Donpi I tested your plugin with 3.2-RC1 and I no longer get unexpected crashes or other problems. In any case I recommend adding a short delay once object model updates have been received to reduce the CPU usage a bit.

                          Duet software engineer

                          1 Reply Last reply Reply Quote 1
                          • Donpiundefined
                            Donpi
                            last edited by

                            Good to hear that 😄
                            Thank you for the support

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