M150 Crashes My Duet3 Mini5

Topher

I seem to be having my machines get hung on code around M150 commands. I've moved the positioning of the M150 command a few times, found it works best only when it's in the first line of the file being executed. Here is my file that gets hung up:

G91 ; Set relative position for Z clear
G1 Z5 ; Lift Z height 5mm
G90 ; Set absolute
G1 X110 Y110 F3000 ; position head over center of bed
M104 S0 ; turn off extruder
M106 S255 ; turn fan on 100% to speed up bed cooling
M150 U255 R150 ; set cooling color

;---------------set cooling temp here before part cant be accessed---------------
M190 R41 ; Wait for bed temp to cool to 41c
;--------------------------------------------------------------------------------

M140 S0 ; Turn off bed
M98 P"stop.g"

In this instance, the bed temp stayed at its previous temperature of 60c and seemed to sit in a waiting state unresponsive to additional terminal commands.

=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.3 (2021-06-15 21:46:11) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: HUQGK-7296U-D65J0-40KMW-2013Z-R5NM3
Used output buffers: 14 of 40 (14 max)
=== RTOS ===
Static ram: 102724
Dynamic ram: 112048 of which 12 recycled
Never used RAM 26064, free system stack 112 words
Tasks: NETWORK(ready,359.5%,236) HEAT(notifyWait,1.0%,344) Move(notifyWait,16.2%,274) CanReceiv(notifyWait,0.0%,941) CanSender(notifyWait,0.5%,357) CanClock(delaying,0.5%,332) TMC(notifyWait,23.2%,106) MAIN(running,111.4%,426) IDLE(ready,1.8%,29) AIN(delaying,28.5%,264), total 542.5%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 08:18:47 ago, cause: software
Last software reset at 2021-07-27 01:05, reason: User, GCodes spinning, available RAM 26040, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,1
MCU revision 3, ADC conversions started 29925530, completed 29925529, timed out 0, errs 0
Step timer max interval 9771
MCU temperature: min 37.7, current 40.9, max 43.2
Supply voltage: min 26.4, current 27.3, max 27.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/8, heap memory allocated/used/recyclable 2048/774/636, gc cycles 41
Driver 0: position 211334, standstill, SG min/max 0/10, read errors 0, write errors 1, ifcnt 27, reads 60942, writes 13, timeouts 0, DMA errors 0
Driver 1: position 140900, standstill, SG min/max 0/52, read errors 0, write errors 1, ifcnt 25, reads 60943, writes 12, timeouts 0, DMA errors 0
Driver 2: position 178756, standstill, SG min/max 0/38, read errors 0, write errors 1, ifcnt 28, reads 60941, writes 13, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, SG min/max 0/22, read errors 0, write errors 1, ifcnt 29, reads 60940, writes 14, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/34, read errors 0, write errors 1, ifcnt 27, reads 60942, writes 13, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-07-27 09:24:03
Cache data hit count 4294967295
Slowest loop: 211.93ms; fastest: 0.09ms
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 4.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 374234ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 671217, completed moves 671217, hiccups 780130, stepErrors 0, LaErrors 0, Underruns [292, 0, 3], 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, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 0
Movement lock held by File
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
=====>File is doing "M190 R41 " in state(s) 0 0, running macro
USB is idle in state(s) 0
Aux is assembling a command in state(s) 0
Trigger is idle in state(s) 0
=====>Queue is doing "M150 U255 R150 " 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 269334, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 17 (min 17), ts 149636/0/0
Tx timeouts 0,2,149635,0,0,119694 last cancelled message type 30 dest 127

=== Network ===
Slowest loop: 213.14ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(2) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address f0:08:d1:02:eb:c6
WiFi Vcc 3.35, reset reason Power up
WiFi flash size 2097152, free heap 21864
WiFi IP address 192.168.2.122
WiFi signal strength -63dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 4 4 0 0 0 0 0 0

cosmowave

@leckietech

M190 R41

this code waits until your bed temp is below 41°C!

Edit:
I think you should switch off the bed somewhere...??

fcwilt

@leckietech

Hi,

You are waiting for the bed to cool.

Where do you stop the bed from heating?

Frederick

Topher

@cosmowave yes, I am waiting for the bed to cool to 41c before M140 is called to turn the bed off. Before the above file is called, the bed's temp is 60c at the end of my print, M190 R41will set the temp to 41c and wait till it is reached before continuing - this is intentional. It's so the print head can use the part fan to assist in cooling the bed for faster part removal, also, our team tends to remove parts when the bed is too hot causing damage to the print surface or part. This is a good way to prevent that for us.

Topher

@fcwilt said in M150 Crashes My Duet3 Mini5:

@leckietech

Where do you stop the bed from heating?

If the bed temp is 60c currently, sending M190 R41 will stop the heating by setting the temp to 41c and wait until it is reached. The next line turns off the bed using M140 S0.

fcwilt

@leckietech said in M150 Crashes My Duet3 Mini5:

@fcwilt said in M150 Crashes My Duet3 Mini5:

@leckietech

Where do you stop the bed from heating?

If the bed temp is 60c currently, sending M190 R41 will stop the heating by setting the temp to 41c and wait until it is reached. The next line turns off the bed using M140 S0.

Thanks.

Is there a reason you want to use M190 to wait rather than just turning off the bed heater with M140?

Frederick

Topher

@fcwilt said in M150 Crashes My Duet3 Mini5:

Is there a reason you want to use M190 to wait rather than just turning off the bed heater with M140?

It's so the print head can use the part fan over the center of the bed to assist in cooling the bed for faster part removal, also, our team tends to remove parts when the bed is too hot causing damage to the print surface or part. This is a good way to prevent these mistakes.

fcwilt

@leckietech

Interesting.

So you don't use one of the removable bed surface products?

I do and when the print is finished I remove the flexible plate and wave it madly in the air until it is cool.

Frederick

Topher

@fcwilt said in M150 Crashes My Duet3 Mini5:

@leckietech
So you don't use one of the removable bed surface products?

Hey thanks for the suggestion! But we already manufacture our own from 0.012" spring steel cut on our fiber laser and embedded magnets into an aluminum plate we run on our haas. Makes it easy for changing our Kapton tape bed surface but that's about it. If you factor the labor on removing and reinstalling 60 bed plates 3 times a day and heaven forbid the guys touch the surface with their fingers causing the next print to not sick or debris ends up between the print surface and aluminum plate, it just makes sense for us. When the bed reaches 40c, the print is basically 100% released.

My script has been working fine for 2 years, 10's of thousands of prints, no problems! its just recently become an issue because we added LEDs to all of our printers via the Fysetc 12864 screen, therefore, requiring M150 commands.

dc42

@leckietech I'm not sure why the M150 command seems to be getting held up, however you may find that a M400 command just before it helps.

Topher

@dc42 Thanks! Ill give that a shot!

Topher

@dc42 said in M150 Crashes My Duet3 Mini5:

@leckietech I'm not sure why the M150 command seems to be getting held up, however you may find that a M400 command just before it helps.

Bam! That did it! I just took the last 20 or so lines of code and put them in a file so I can run this over and over in a real-life situation. 3 times in a row, the printer would get stuck here:

File is doing "M190 R41 " in state(s) 0 0, running macro
Queue is doing "M150 U255 R150 " in state(s) 0

I added M400 and ran it 5 times and it never missed. You've saved me some hair on my head. Thank's again for the many tips today!

dc42

@leckietech thanks for confirming. I will fix the bug in RRF 3.4.