M600 still problem?
-
I was trying to find some info about the M600 filament change. I found this, for example.
Basically, the M600 will call filament-change.g but it will not be able to start printing again. The extruder moves to the correct position (resume.g) but printing not starts. He is still "paused". If he clicks "resume", filament-change.g will run again and again. When I deleted filament-change.g, I also couldn't restore printing.
Separately (form LCD buton) pause and resume functions work without problems.
I run duet3 6HC + 1LC with SBC Rpi4, duet ver 3.3
Any ideas?
pause.g
M83 ; relative extruder moves G1 E-10 F3600 ; retract 10mm of filament G91 ; relative positioning G1 Z5 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X50 Y50 F6000 ; go to X=0 Y=0 resume.g
G1 R1 X0 Y0 Z5 F6000 ; go to 5mm above position of the last print move G1 R1 X0 Y0 ; go back to the last print move M83 ; relative extruder moves G1 E10 F3600 ; extrude 10mm of filament filament-change.g
M83 ; relative extruder moves G1 E-10 F3600 ; retract 10mm of filament G91 ; relative positioning G1 Z25 F360 ; lift Z by 5mm G90 ; absolute positioning G1 X50 Y50 F6000 ; go to X=0 Y=0 G1 E-20 F300 ; Retract 20mm of filament at 300mm/min G4 S5 G1 E-150 F3000 ; Retract 480mm of filament at 3000mm/min M400 ; Wait for the moves to finish M291 P"remove old filament, load new filament and press OK" R"Filament has to be changed M600" S2 ; display message to change filament Filament has run out m122
=== Diagnostics === m122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-9P63L-DJMSS-6J1F8-3S46N-9VFV8 Used output buffers: 1 of 40 (10 max) === RTOS === Static ram: 150904 Dynamic ram: 62116 of which 0 recycled Never used RAM 141172, free system stack 200 words Tasks: SBC(ready,5.0%,328) HEAT(delaying,0.0%,325) Move(notifyWait,0.0%,302) CanReceiv(notifyWait,0.0%,774) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,6.9%,93) MAIN(running,88.0%,1246) IDLE(ready,0.0%,29), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:16:28 ago, cause: power up Last software reset at 2021-08-06 15:28, reason: User, none spinning, available RAM 137924, slot 1 Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 Step timer max interval 130 MCU temperature: min 20.5, current 24.4, max 32.6 Supply voltage: min 0.1, current 28.1, max 28.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 0.1, current 12.1, max 12.1, under voltage events: 0 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Driver 0: position 0, standstill, reads 3767, writes 14 timeouts 0, SG min/max 0/0 Driver 1: position 0, standstill, reads 3767, writes 14 timeouts 0, SG min/max 0/0 Driver 2: position 0, standstill, reads 3767, writes 14 timeouts 0, SG min/max 0/0 Driver 3: position 0, standstill, reads 3767, writes 14 timeouts 0, SG min/max 0/0 Driver 4: position 0, standstill, reads 3767, writes 14 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 3767, writes 14 timeouts 0, SG min/max 0/0 Date/time: 2021-08-07 08:10:17 Slowest loop: 0.45ms; fastest: 0.03ms === 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 === DMs created 125, 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 Heater 1 is on, I-accum = 0.0 === 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. === Filament sensors === Extruder 0: no data received === CAN === Messages queued 8810, received 12052, lost 0, longest wait 2ms for reply type 6049, peak Tx sync delay 57514, free buffers 49 (min 48), ts 4941/4818/0 Tx timeouts 0,0,122,0,0,0 last cancelled message type 30 dest 127 === SBC interface === State: 4, failed transfers: 1, checksum errors: 0 Last transfer: 2ms ago RX/TX seq numbers: 34693/34693 SPI underruns 0, overruns 0 Disconnects: 0, timeouts: 0, IAP RAM available 0x2c83c Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.3.0 Code buffer space: 4096 Configured SPI speed: 8000000Hz Full transfers per second: 0.78, max wait times: 19.6ms/0.0ms Codes per second: 0.00 Maximum length of RX/TX data transfers: 3084/900 gcode
.... ;WIPE_END G1 E-0.03500 F2100.000 G1 Z15.300 F18000.000 ;AFTER_LAYER_CHANGE ;15.05 ; LAYER: 114 ;COLOR_CHANGE,T0 M600 G1 E-0.70000 F2100.000 G1 X213.238 Y262.401 F18000.000 G1 X213.027 Y264.554 G1 Z15.050 G1 E0.70000 F2100.000 .... -
Perhaps it is because you are running with a SBC.
SBC "mode" has been lagging behind SD "mode" (no SBC) in terms of features.
Can you try running without the SBC?
Frederick
-
@fcwilt - it is no so simply put SD card to 6HC board in my setup. So if it not absolutely necessary, he would like to avoid it.
However, it seems to be right.Is there any plan improvement? For now, I can change the filament manually, but it's annoying.
-
@petrkroupa said in M600 still problem?:
@fcwilt - it is no so simply put SD card to 6HC board in my setup. So if it not absolutely necessary, he would like to avoid it.
However, it seems to be right.Is there any plan improvement? For now, I can change the filament manually, but it's annoying.
I have one SD card for SBC mode and one SD card for SD mode.
They are mostly the same with just a very few differences - one or two related to network settings, others related to global variables names.
I haven't yet found any compelling reason to use SBC mode so I am staying with SD mode for now.
I'm sure they programmers will eventually get SBC mode working the same as SD mode but who knows when that will be.
Frederick
-
@fcwilt - For me is diference LCD. I have hdmi touch lcd on Pi. Whithout SBC i dont have lcd. I can install clear rasbian on Pi and use it just for Duet web but it is not clear solution for me. Maybe in ver 3.4 will M600 work. I can not try beta for now. I need print some parts.
-
@petrkroupa said in M600 still problem?:
M291 P"remove old filament, load new filament and press OK" R"Filament has to be changed M600" S2 ; display message to change filament Filament has run out Can you try without the M291 command? Does that prompt show up and does it clear correctly when you hit ok?
-
@phaedrux - sure, I can. But even without filament-change.g same problem happend. And in pause.g is no M291.
Mesage show correct and can be confirm by OK.
Interesing is when send M600 by type command everiting went well.
-
This is all happening during a print from the SD card, correct?
-
@phaedrux - yes. Gcode is on SD card in Raspberry. And is preaty big. 40hours print.
-
@petrkroupa Thanks for reporting this, I've got fixes ready for this problem. It will be fixed in the next RRF version.
@fcwilt The upcoming v3.4 will support everything in SBC mode that is already supported in standalone mode. The overall performance will be significantly higher in v3.4, too. -
@chrishamm said in M600 still problem?:
@fcwilt The upcoming v3.4 will support everything in SBC mode that is already supported in standalone mode. The overall performance will be significantly higher in v3.4, too.
That's good to know.
Frederick
-
@chrishamm - Perfect! Many thanks for info!
