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

    Any tips on debugging techniques for out of memory?

    Scheduled Pinned Locked Moved
    Gcode meta commands
    7
    27
    788
    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.
    • dc42undefined
      dc42 administrators @DonStauffer
      last edited by

      @DonStauffer how about getting your macro to also echo the amount of free memory at various points? It's available in the object model.

      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

      DonStaufferundefined 1 Reply Last reply Reply Quote 0
      • DonStaufferundefined
        DonStauffer @dc42
        last edited by DonStauffer

        @dc42 OK, about my "knowing the object model by heart" ... except that! 🙂

        boards[0].freeRam?

        dc42undefined 1 Reply Last reply Reply Quote 0
        • dc42undefined
          dc42 administrators @DonStauffer
          last edited by

          @DonStauffer yes that's the one. It's the same as Never Used RAM in the M122 report.

          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

          DonStaufferundefined 1 Reply Last reply Reply Quote 0
          • DonStaufferundefined
            DonStauffer @dc42
            last edited by

            @dc42 Thanks. I'll look at it, though my immediate problem seems to be solved. But undoubtedly I'll run out of memory again at some point. But I'm pretty happy now.

            dc42undefined 1 Reply Last reply Reply Quote 0
            • dc42undefined
              dc42 administrators @DonStauffer
              last edited by

              @DonStauffer I'd be interested to know whether you have less or more free memory after running a print with 3.6 alpha compared to 3.5.2.

              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

              DonStaufferundefined 2 Replies Last reply Reply Quote 0
              • DonStaufferundefined
                DonStauffer @dc42
                last edited by

                @dc42 I'm a little afraid to install an alpha though. Is reverting easy?

                dc42undefined 1 Reply Last reply Reply Quote 0
                • dc42undefined
                  dc42 administrators @DonStauffer
                  last edited by

                  @DonStauffer assuming you are running in standalone mode not SBC mode, reverting is very easy. To make it even easier you can install just the 3.6 Duet2CombinedFirmware.bin file and continue running DWC 3.5.2. You can ignore the warning about incompatible software versions in this case.

                  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

                  DonStaufferundefined 1 Reply Last reply Reply Quote 0
                  • gloomyandyundefined
                    gloomyandy @DonStauffer
                    last edited by

                    @DonStauffer Just running M122 in the console should provide an idea of what the memory situation is before the print starts and after your startup code has run.

                    DonStaufferundefined 1 Reply Last reply Reply Quote 0
                    • DonStaufferundefined
                      DonStauffer @gloomyandy
                      last edited by

                      @gloomyandy Echoing boards[0].freeRam at various places throughout a small, 15 minute, 8-layer print job with tool changes, it looks like this (no units given; bytes?):

                      Machine turn-on: 8544
                      Partway through job startup: 8520
                      Before purge in job startup: 4000
                      After purge: 920
                      Beginning of Layer 1: 920
                      Layer 2: 848
                      Layer 3: 848
                      Layer 4: 848
                      Layer 5: 848
                      Layer 5 before tool change: 464
                      Layer 6: 72
                      Layer 6 before tool change: 72
                      Layer 7: 72
                      Layer 7 before tool change: 72
                      Layer 8: 72
                      Layer 8 before tool change: 72
                      After job finished: 72

                      It seems like I'm grazing the treetops. Most of my global data is created from config.g, so I'm not really sure why my startup script uses so much memory compared to the job proper.

                      1 Reply Last reply Reply Quote 0
                      • DonStaufferundefined
                        DonStauffer @dc42
                        last edited by

                        @dc42 OK, I'll do that. I have the details on free memory echoing throughout a job and I recorded them. So I'll have something to compare it with.

                        1 Reply Last reply Reply Quote 0
                        • DonStaufferundefined
                          DonStauffer @dc42
                          last edited by

                          @dc42 Same GCode file as the free RAM I posted for RRF 3.5.2, but after installing 3.6 alpha 2:

                          After upgrade: 22624
                          I couldn't believe that so I did an M999 and looked again: 22600 (where are my 24 bytes?)
                          Partway through job startup: 22600
                          Before purge in job startup: 16840
                          After purge: 14472
                          Beginning of Layer 1: 14472
                          Layer 2: 14472
                          Layer 3: 14304
                          Layer 4: 14280
                          Layer 5: 14280
                          Layer 5 before tool change: 13512
                          Layer 6: 13096
                          Layer 6 before tool change: 13096
                          Layer 7: 13096
                          Layer 7 before tool change: 13096
                          Layer 8: 13096
                          Layer 8 before tool change: 13096
                          After job finished: 13096

                          What wizardry is this?!

                          oliofundefined 1 Reply Last reply Reply Quote 0
                          • oliofundefined
                            oliof @DonStauffer
                            last edited by

                            @DonStauffer probably the work noted at https://github.com/Duet3D/RepRapFirmware/blob/bd8d9119d49ba425864f2280b005875b368746c0/src/Todo-next.txt#L25

                            <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

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