Duet 3 +SBC : Print randomely freeze when runin my script on RPI

chrishamm

@Donpi I have just tried the updated test app and it's working on my test setup with 3.2.0-b4.1:

   Duet   21.4 C°
Reading model                                               Pi   47.7 C°

If you still have problems with 3.1.1, please consider upgrading to the latest unstable version. We're hoping to publish a first release candidate for 3.2 quite soon.

Donpi

@chrishamm it crash the same with your rewrite.
It stoped printing after about 30 minutes.

How can I switch to 3.2.0-b4.1 ?

Phaedrux

@Donpi said in Duet 3 +SBC : Print randomely freeze when runin my script on RPI:

How can I switch to 3.2.0-b4.1 ?

You'd have to switch to the unstable branch and then update.

https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Software_Installation

Donpi

It crash the print even with the 3.2.0-b4.1

here is my M122

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-beta4.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6JTDG-3SD6J-TABLT
Used output buffers: 4 of 40 (15 max)
=== RTOS ===
Static ram: 123292
Dynamic ram: 137988 of which 36 recycled
Never used RAM 130876, free system stack 188 words
Tasks: Linux(ready,77) HEAT(blocked,297) CanReceiv(blocked,947) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,49) MAIN(running,1161) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:25:28 ago, cause: software
Last software reset at 2020-12-09 15:50, reason: HeatTaskStuck, GCodes spinning, available RAM 130188, slot 0
Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0x00000000 SP 0x20410144 Task MAIN
Stack: 2042328c 00429512 81000000 00000000 3e958000 00000000 4079a000 401fc5e4 3f9ca0f0 4530c6d9 4530c6d9 44b0c6d9 49371b00 37533333 43d697a0 00000000 42117d81 3f800000 00000000 60000011 20426c58 2040e0b4 20426c58 00000000 20423af8 00000080 a5a5a5a5
Error status: 0x00
MCU temperature: min 35.1, current 37.4, max 37.6
Supply voltage: min 24.8, current 25.0, max 25.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.0, max 12.1, under voltage events: 0
Driver 0: position 0, standstill, reads 12980, writes 14 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 12981, writes 14 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 12980, writes 15 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 12981, writes 15 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 12983, writes 14 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 12987, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-12-09 16:16:44
Slowest loop: 4.12ms; fastest: 0.12ms
=== Storage ===
Free file entries: 10
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 ===
FreeDm 375 (min 375), maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 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, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by 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 idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 6111, send timeouts 13750, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 47
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 19ms ago
RX/TX seq numbers: 15632/53872
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x209d8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta4
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 1.96

Donpi

This post is deleted!

Donpi

The duet stop printing but the script continue

chrishamm

Many thanks for reporting this, I've just reproduced and fixed this problem. It will be fixed in the next version.

Donpi

Are there come log that I can check to see what is appening in the Duet ?
Or what gcode is effetively executed .

Phaedrux

There is this: https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M929_Start_stop_event_logging_to_SD_card

And this: https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Monitoring_optional

chrishamm

TBH I had some problems with your plugin but I've got a fix ready - at least I haven't been able to reproduce it with the latest dev version. This problem only showed up when two G/M/T-codes from two different G-code channels were frequently sent.

To work-around this problem try to send your M106 code to the File channel (that's the same channel used for file prints) and consider adding a delay (e.g. await Task.Delay(1000);) after it. The second parameter of PerformSimpleCode lets you choose the target channel.

Donpi

@chrishamm Great, I'll test that today.

I thought I was abandoned alone with my problem

Donpi

@chrishamm said in Duet 3 +SBC : Print randomely freeze when runin my script on RPI:

await Task.Delay(1000);

The workaround seems to work but it gives me many "Error parsing response" in the PanelDuet console

chrishamm

@Donpi I tested your plugin with 3.2-RC1 and I no longer get unexpected crashes or other problems. In any case I recommend adding a short delay once object model updates have been received to reduce the CPU usage a bit.

Donpi

Good to hear that
Thank you for the support