Random M32 with latest beta

[kuon]

With version 3.5beta2 I randomly get the following message after a few prints and I need to restart the duet:

Error: M32: Cannot set file to print, because a file is already being printed

All boards in the machine have the same firmware and nothing is printing when the error shows. M27 returns Not SD printing. when the error is present.

I'll share my M122 next time the issue appears.

[kuon]

Here is M122 when the issue is present:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5beta2 (2023-02-08 15:27:50) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J9D6-3S46J-TB8US
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 154344
Dynamic ram: 85088 of which 384 recycled
Never used RAM 102224, free system stack 122 words
Tasks: SBC(ready,35.2%,404) HEAT(notifyWait,0.9%,321) Move(notifyWait,30.4%,214) CanReceiv(notifyWait,2.0%,771) CanSender(notifyWait,0.3%,325) CanClock(delaying,0.2%,340) TMC(notifyWait,109.9%,56) MAIN(running,97.5%,446) IDLE(ready,0.1%,30), total 276.6%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 29:41:11 ago, cause: software
Last software reset at 2023-04-03 18:17, reason: User, Gcodes spinning, available RAM 102584, slot 0
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 229
MCU temperature: min 39.6, current 43.6, max 45.4
Supply voltage: min 23.7, current 23.9, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 99/5, heap memory allocated/used/recyclable 2048/464/368, gc cycles 800
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a, mspos 8, reads 63947, writes 0 timeouts 0
Driver 1: standstill, SG min 0, mspos 671, reads 63859, writes 88 timeouts 0
Driver 2: standstill, SG min 0, mspos 525, reads 63881, writes 66 timeouts 0
Driver 3: standstill, SG min 0, mspos 973, reads 63859, writes 88 timeouts 0
Driver 4: standstill, SG min 0, mspos 745, reads 63859, writes 88 timeouts 0
Driver 5: standstill, SG min 0, mspos 259, reads 63859, writes 88 timeouts 0
Date/time: 2023-04-04 23:58:45
Slowest loop: 71.08ms; fastest: 0.03ms
=== Storage ===
Free file entries: 20
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 ===
DMs created 125, segments created 24, maxWait 8362768ms, bed compensation in use: none, comp offset 0.000
no step interrupt scheduled
=== DDARing 0 ===
Scheduled moves 70991, completed 70991, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 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, chamber heaters 10 -1 -1 -1, ordering errs 0
Heater 10 is on, I-accum = 0.4
=== GCodes ===
Movement locks held by null, 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 doing "G4 P500" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2* is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 1676252, received 4253457, lost 0, boc 0
Longest wait 5ms for reply type 6024, peak Tx sync delay 429, free buffers 50 (min 39), ts 531609/531609/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 29980/29980
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x26934
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.0-beta.2 (2023-02-08 11:47:09)
File+Start:
> Busy
File+ProcessInternally:
> Busy
File2+ProcessInternally:
> Busy
File /opt/dsf/sd/gcodes/Pouch - Part 4(1).gcode is selected, processing, aborted
Daemon:
Buffered code: G4 P500
Buffered codes: 32 bytes total
>> Doing macro daemon.g, started by system
>> Number of flush requests: 1
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 23
Full transfers per second: 41.38, max time between full transfers: 82.6ms, max pin wait times: 74.0ms/9.9ms
Codes per second: 17.38
Maximum length of RX/TX data transfers: 4568/2088

Note: the file "Pouch - Part 4(1).gcode" is the file that just finished printing, and the printing finished properly.

[jay_s_uk]

@kuon one for @chrishamm

[chrishamm]

@kuon Please share your end G-code or ideally the full print file(s).

[OwenD]

@kuon
Is there anything in daemon.g that could contribute ?
Your M122 shows the daemon is running.
Probably worth posting the contents of that too.

[kuon]

Here is my daemon.g

if exists(global.config_finished) && global.config_finished
  while true
    if heat.heaters[10].state != "off"
      M106 S100 P10
    else
      M106 S0 P10

    if heat.heaters[10].state != "off" || sensors.analog[10].lastReading > 50 || global.force_pump_on
      M42 P13 S1
    else
      M42 P13 S0

    G4 P500 

And here is the gcode test.gcode

[chrishamm]

@kuon Thanks for your help, I may have figured out why this problem occurred. Please check if the problem persists in the upcoming v3.5-b3.

[kuon]

@chrishamm Great. I'll try the beta as soon as possible.

[T3P3Tony]

@kuon please can you confirm if this issue or resolved.

[kuon]

@T3P3Tony The issue did not yet occur, I think you can consider it fixed, if it happen again I will let you know.

[kuon]

@chrishamm After many prints, this issue did not appear again. So I have good hope it is fixed.