M80 config.g

Marco Bona

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?

jens55

What does config.g do before calling M80 ?

A Former User

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)

Marco Bona

@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

jens55

Sounds like something for dc42 to elaborate on.

dc42

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.

Marco Bona

@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

dc42

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.

Marco Bona

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

dc42

@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.

Marco Bona

@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