Printer freezes at start of print
Afternoon, I'm not sure if i have the topic area correct, but I suspect my latest issue is CURA.
I'm attempting to start a print, the printer homes/heats fine then loads the height map, then as it start to move towards the cleaning line the nozzle freezes and just sits there, the board responds I can input Gcodes, pause the print it does everything but start printing!
could someone please take a look at my start code, I've also included an M122 on the off chance its the printer.
G91 ; relative position
G1 Z-1 ; Move Z down 1
G90 ; Absolute Positioning
M280 P0 S160 ;BLTouch alarm release
G4 P100 ;delay for BLTouch
M561 ; Clear any bed transform
M375 P"heightmap.csv" ; Load heightmap
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position (seems to lock up moving here!)
G1 X10.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line
G1 X10.4 Y200.0 Z0.28 F5000.0 ;Move to side a little
G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.01-RC6 running on Duet 3 MB6HC v0.6 or 1.0
Board ID: 08DJM-956L2-G43S8-6JKDG-3SS6L-KB12H
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154084
Dynamic ram: 161088 of which 24 recycled
Exception stack ram used: 528
Never used ram: 77492
Tasks: NETWORK(ready,2076) HEAT(blocked,1196) CanReceiv(suspended,3820) CanSender(suspended,1440) CanClock(blocked,1436) TMC(blocked,80) MAIN(running,4892) IDLE(ready,76)
=== Platform ===
Last reset 00:02:46 ago, cause: power up
Last software reset at 2020-04-08 16:12, reason: User, spinning module LinuxInterface, available RAM 77416 bytes (slot 1)
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 37.6, current 41.2, max 41.7
Supply voltage: min 19.6, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0
Driver 0: standstill, reads 36596, writes 17 timeouts 0, SG min/max 0/229
Driver 1: standstill, reads 36597, writes 17 timeouts 0, SG min/max 0/259
Driver 2: standstill, reads 36597, writes 17 timeouts 0, SG min/max 0/284
Driver 3: standstill, reads 36601, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 36604, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 36604, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-04-08 16:24:43
Slowest loop: 3.89ms; fastest: 0.21ms
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 373, MaxWait: 139690ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 7, completed moves: 7, 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 = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== 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: 0.49ms; 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 -
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 571, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 16ms ago
RX/TX seq numbers: 4609/4610
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v126.96.36.199
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 10.4
Many thanks Jim
- Ethernet -
@PaulHew first height map, I have now levelled the bed further and will carry out G32 again!
@PaulHew, post levelling G32.... yup it looks better!
@PaulHew @Phaedrux ok so after our phone call Paul the printer is still freezing, I’ve turned it off let it cool and tried it again it now freezes every time at the same point at the start of the print, the printer board responds as in I can go into different menus but any input is queued as the board reports it is processing.
This seems to happen just after it loads the height map it just sits at the home point and doesn’t do anything else, if I press emergency stop the board unfreezes and works as normal.
I have also slaved in my pi4 in case my pi3 is not up to the job but it does exactly the same thing, however it is the same sd card running both, any clue as to what to do next? Stand-alone?
Thanks in advance
Can you post the entire gcode file please?
And it would be good to know if it has a similar problem when in standalone mode. That would let us know if it's potentially a DSF/Pi issue.
I suspect you may be having the same issue as reported here: https://forum.duet3d.com/topic/15342/duet-web-control-2-1-1-released/33?_=1586311059377
Does it still freeze if you don't load a heightmap?
@Phaedrux I assume you mean the file I've been trying too print it was sliced on prusa2.2 with Pauls help
I'll take a look at the link you posted and see if its the same, I'm also a little unsure how to print without the height map as I believe the Gcode has it written into it, can I disable it in DWC or should I slice without?
@Phaedrux I have some of those issues like the control all not working and occasionally the heat bed doesn't display on start up but reappears once I either reset or press the emergency stop, the annoying part was the part actually started printing the first time it was tried, then I went to put M122 into the console whilst it was printing and typed M112 instead, once that got sorted and the bed cleared it didn't print again!
PaulHew last edited by
@jumpedwithbothfeet In the start code I gave you in 'Printer settings, insert a ; like you did when the original slicer code
@Phaedrux , whilst chatting with Jim, it was printing OK until he put the M112 in!
It had done its purge line and started to print Jim's object, Jim wanted to check that mesh was enabled.
I forgot it could be done in DWC, but asked him to type M122 in the console instead.
I too have made that mistake during a 3hour print, maybe the command could be removed and replaced!
Ah yes, the old M112/M122 snafu. That's a dangerous one. It's a legacy issue now unfortunately.
@Phaedrux so...I went into the slicer and commented out G29 as you suggested and then whilst I was there also sliced the same model again with the G29 added, the file with G29 removed printed! it was no where near the bed but it did it, the other file however gave me the exact same fault, it sat and did nothing, so should I carry out G32 again or is there something else amiss?
Sorry, just to get myself up to speed, does G32 do any automatic axis leveling in your case or does it just call G29 to do a mesh compensation probing?
If it does leveling, then you should probably be doing G32 before every print.
I think you may need to either wait for some issues with 3.01 RC6/DWC2.1.1/DSF1.3.1 to be resolved, or go back to the previous versions to continue.
Welcome to the bleeding edge.
@Phaedrux honest answer I’ve not a clue I was under the impression that G32 defines the bed mesh and G29 implements it but I’ve only been attempting to use Gcode for the last week! so I’m having a pretty steep learning curve!
I will try putting in G32 instead of G29 in the slicer and see what happens I’ll let you know what happens failing that I’ll look into how to roll back the firmware, something else I know nothing about! Still you learn something new everyday
first please post the contents of bed.g, since that is what G32 ultimately executes. That will tell us exactly what it's doing.
I assumed that G32 is doing some leveling based on your heightmap image above being tilted and then you ran G32 and it was no longer tilted.
Ok, so G32 is ultimately just running G29
; bed.g ; called to perform automatic bed compensation via G32 ; ; generated by RepRapFirmware Configuration Tool v2.1.8 on Mon Apr 06 2020 18:55:28 GMT+0100 (British Summer Time) M561 ; clear any bed transform G29 ; probe the bed and enable compensation
@Phaedrux so changing the slicer to G32 wont work?
You can try. It will just cause it to probe the whole bed surface before printing.
The G29 S1 that you had in there already was loading a saved heightmap (from the last time you ran G32)
Either way, it would appear that there is a bug that is causing a hang when loading a heightmap. So maybe probing a fresh heightmap will behave differently than loading a saved one.
@Phaedrux Yup just found that out! I'll run a fresh bed map and see if it changes anything, is this something the new firmware update will likely address?
is this something the new firmware update will likely address?
Yes, the full releases of 3.01 is on the horizon with much work going into DWC and DSF.
I suggest digging into the DWC/DSF release threads to see how it's progressing and what else is being reported.
@Phaedrux @PaulHew Ok so I ran the new bed map, actually I ran it twice is I forgot to heat the bed and nozzle, amazing what a difference that makes to the level, but any way it worked it's printing! ill run some test prints again tomorrow hopefully it was the cause, thanks again for all your help and your time
PaulHew last edited by
@PaulHew I have to say even tho it’s taken over a week to get something printed and that’s mainly down to user induced faults! I still feel like I’ve got out of an escort and jumped into a Ferrari with this board, all I’ve got to do now is learn how to drive