M80 config.g



  • Hello, I would like to add an atx switch but I am experiencing an 11-12 second delay on starting M80 from config.g while if I start it from the console it is instantaneous.
    The card is a duet3 with the latest firmware (RRF3.01 RC4). Is it correct to have this delay or am I doing something wrong?



  • What does config.g do before calling M80 ?



  • the order in config.g ins't 100% the same order the firmware executes things in; or at least thats what I took away from a recent post by dc42 about M552 being deferred until the end. (if memory serves me right)



  • @jens55 , I tried to perform it both at the beginning and at the end but it does not change, when I feed the duet the leap time remains 11 seconds, instead if I restart it from console or active M80 \ M81 is instantaneous



  • Sounds like something for dc42 to elaborate on.


  • administrators

    M80 will be acted on as soon as the command is encountered in config.g. You would normally put it at the start. So if you are seeing an 11-second delay, I think that can only mean that the whole of config.g is being delayed for 11 seconds. Possible reasons for that include:

    • Power coming up very slowly
    • A problem communicating with the SD card, so that RRF has to make several attempts to communicate with the SD card, at decreasing speeds. You can find the connected speed in the M122 report.


  • @dc42 , I am currently powering the 12V card to perform tests, could this be the cause of the problem?
    I attach the report

    m122
    === Diagnostics ===
    RepRapFirmware for Duet 3 MB6HC version 3.01-RC4 running on Duet 3 MB6HC v0.6 or 1.0
    Board ID: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
    Used output buffers: 1 of 40 (8 max)
    === RTOS ===
    Static ram: 154084
    Dynamic ram: 162628 of which 56 recycled
    Exception stack ram used: 296
    Never used ram: 76152
    Tasks: NETWORK(ready,2076) HEAT(blocked,832) CanReceiv(suspended,3408) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,216) MAIN(running,4956) IDLE(ready,80)
    Owned mutexes:
    === Platform ===
    Last reset 00:04:08 ago, cause: software
    Last software reset at 2020-03-27 14:10, reason: User, spinning module LinuxInterface, available RAM 76144 bytes (slot 2)
    Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 not detected, interface speed: 37.5MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 30.5, current 30.7, max 31.0
    Supply voltage: min 11.8, current 11.9, max 12.0, under voltage events: 0, over voltage events: 0, power good: yes
    12V rail voltage: min 10.9, current 11.0, max 11.1, under voltage events: 0
    Driver 0: standstill, reads 45329, writes 14 timeouts 0, SG min/max 0/0
    Driver 1: standstill, reads 45329, writes 14 timeouts 0, SG min/max 0/0
    Driver 2: standstill, reads 45330, writes 14 timeouts 0, SG min/max 0/0
    Driver 3: standstill, reads 45327, writes 17 timeouts 0, SG min/max 0/0
    Driver 4: standstill, reads 45331, writes 14 timeouts 0, SG min/max 0/0
    Driver 5: standstill, reads 45331, writes 14 timeouts 0, SG min/max 0/0
    Date/time: 2020-03-27 14:14:20
    Slowest loop: 300.31ms; fastest: 0.15ms
    === Move ===
    Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 0, completed moves: 0, 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 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
    === 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
    LCD is idle in state(s) 0
    SBC 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: 1.07ms; fastest: 0.01ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 0 of 8

    • Ethernet -
      State: disabled
      Error counts: 0 0 0 0 0
      Socket states: 0 0 0 0 0 0 0 0
      === Filament sensors ===
      Extruder 0: no data received
      Extruder 1: no data received
      === CAN ===
      Messages sent 1008, longest wait 1ms for type 6018
      === Linux interface ===
      State: 0, failed transfers: 0
      Last transfer: 19ms ago
      RX/TX seq numbers: 31997/7156
      SPI underruns 0, overruns 0
      Number of disconnects: 0
      Buffer RX/TX: 0/0-0
      === Duet Control Server ===
      Duet Control Server v1.2.5.0
      Code buffer space: 4096
      Configured SPI speed: 2000000 Hz
      Full transfers per second: 26.51

  • administrators

    You are running a Duet 3 with attached SBC. So before config.g can be executed, the SBC has to start up. That 11 seconds is I presume the tie taken for the SBC to start up and establish communication with the Duet.



  • @dc42 ,So is this normal? I try to connect it with arduino by taking the atx signal


  • administrators

    @Marco-Bona said in M80 config.g:

    @dc42 ,So is this normal?

    It's normal for anything running Linux to take at least a few seconds to start up. Whereas most embedded systems such as Arduinos and Duets start up almost instantly.



  • @dc42 ,I managed to solve by connecting an Arduino, although in reality it is M80 in sleep.g which gives the signal to interrupt. I publish the Arduino code that I used if someone were to serve it.
    Duet3_on_off_switch.txt


Log in to reply