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

    RC6 crash with M409

    Scheduled Pinned Locked Moved
    Firmware developers
    2
    3
    147
    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.
    • arhiundefined
      arhi
      last edited by

      this worked at least with RC3 or 4, did not test with 5, and 6 does not work ok

      M409F"v,n,d10" -> crash
      M409F"v,n,d9" -> crash
      ...
      M409F"v,n,d3" -> crash

      M409F"v,n,d2" -> does not crash but does not return anything
      M409F"v,n,d1" -> works

      If I give it a key it works

      M409 K"move" F"v,n,d4" -> works
      M409 K"move" F"v,n,d9" -> works

      most times after crash it reboots, sometimes after crash it needs power cycle to get up

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

        Which Duet?

        Most Duets have insufficient memory to return the whole OM in one go, which is mostly what you are trying to do. But the firmware shouldn't crash, although you may get a network disconnect. Are you sure it crashed? What does M122 report for the software reset data?

        iI you really do want to read the whole OM, the recommended approach is;

        1. Send M409 F"d1" to get the list of root keys.
        2. For each of those root keys, send M409 K"xxx" where xxx is the key. You can add F"v" to that command if you want the verbose keys too.

        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

        arhiundefined 1 Reply Last reply Reply Quote 0
        • arhiundefined
          arhi @dc42
          last edited by

          @dc42 said in RC6 crash with M409:

          Which Duet?

          duet2eth

          Most Duets have insufficient memory to return the whole OM in one go

          ha, so new features... ok .. it worked on RC3/4 but yeah, more stuff added, all clear

          Are you sure it crashed? What does M122 report for the software reset data?

          Nope, not sure. Lost connection, then it returned, I assumed reboot, later on it just lot connection, did not return till power cycle. Will try now

          M122
          === Diagnostics ===
          RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC6 running on Duet Ethernet 1.02 or later
          Board ID: 08DGM-9T6BU-FG3S4-6J9FD-3SD6Q-KVRBF
          Used output buffers: 1 of 24 (24 max)
          === RTOS ===
          Static ram: 28052
          Dynamic ram: 93604 of which 20 recycled
          Exception stack ram used: 496
          Never used ram: 8900
          Tasks: NETWORK(ready,164) HEAT(blocked,1244) MAIN(running,1576) IDLE(ready,80)
          Owned mutexes:
          === Platform ===
          Last reset 02:46:59 ago, cause: software
          Last software reset time unknown, reason: User, spinning module GCodes, available RAM 8892 bytes (slot 3)
          Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
          Error status: 4
          Free file entries: 10
          SD card 0 detected, interface speed: 20.0MBytes/sec
          SD card longest block write time: 7.1ms, max retries 0
          MCU temperature: min 42.6, current 44.7, max 45.1
          Supply voltage: min 23.9, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
          Driver 0: standstill, SG min/max 0/350
          Driver 1: standstill, SG min/max 0/356
          Driver 2: standstill, SG min/max 0/1023
          Driver 3: standstill, SG min/max not available
          Driver 4: standstill, SG min/max not available
          Date/time: 2020-04-10 15:32:11
          Cache data hit count 4294967295
          Slowest loop: 15.72ms; fastest: 0.12ms
          I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
          === Move ===
          Hiccups: 0(0), FreeDm: 169, MinFreeDm: 166, MaxWait: 439095ms
          Bed compensation in use: none, comp offset 0.000
          === MainDDARing ===
          Scheduled moves: 140, completed moves: 140, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
          === AuxDDARing ===
          Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
          === Heat ===
          Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
          Heater 1 is on, I-accum = 0.0
          === GCodes ===
          Segments left: 0
          Movement lock held by null
          HTTP is ready with "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
          Daemon is idle in state(s) 0
          Autopause is idle in state(s) 0
          Code queue is empty.
          === Network ===
          Slowest loop: 39.51ms; fastest: 0.02ms
          Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
          HTTP sessions: 1 of 8
          Interface state active, link 100Mbps full duplex
          === Filament sensors ===
          Extruder 0 sensor: no data received
          

          iI you really do want to read the whole OM, the recommended approach is;

          I just wanted to dump the whole thing few times quckly and then diff the outputs to see what changed 😄 .. not something I need to use normally in production 🙂 ... it's totally ok as is, the lack of RAM did not came to mind 🙂

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