Printer freezes at start of print

Phaedrux

Does it still freeze if you don't load a heightmap?

jumpedwithbothfeet

@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?

jumpedwithbothfeet

@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!

Phaedrux

@jumpedwithbothfeet said in Printer freezes at start of print:

I'm also a little unsure how to print without the height map as I believe the Gcode has it written into it,

You'd have to edit your slicer start gcode to comment out the G29 S1 command

PaulHew

@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!

Phaedrux

Ah yes, the old M112/M122 snafu. That's a dangerous one. It's a legacy issue now unfortunately.

https://duet3d.dozuki.com/Wiki/Gcode#Section_M112_Emergency_Stop
https://duet3d.dozuki.com/Wiki/Gcode#Section_M122_Diagnose

jumpedwithbothfeet

@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?

Phaedrux

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.

jumpedwithbothfeet

@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

Phaedrux

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.

jumpedwithbothfeet

@Phaedrux
bed.g

Phaedrux

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

jumpedwithbothfeet

@Phaedrux so changing the slicer to G32 wont work?

Phaedrux

@jumpedwithbothfeet

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.

jumpedwithbothfeet

@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?

Phaedrux

@jumpedwithbothfeet said in Printer freezes at start of print:

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.

https://forum.duet3d.com/topic/15343/dsf-1-3-1-unstable-released/
https://forum.duet3d.com/topic/15342/duet-web-control-2-1-1-released/

jumpedwithbothfeet

@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

@jumpedwithbothfeet if you need to ask me anything before @Phaedrux gets online, you have my details and am more than happy to help further.

I think I need to get a duet3 now so I can understand it better and put it on the Railcore.

Regards
Paul

jumpedwithbothfeet

@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

jumpedwithbothfeet

@PaulHew @Phaedrux, so I have some feedback about this issue, I’ve managed to do multiple prints today which I’m very happy about, and I’ve figured out the bug.

Every time the printer is turned off and restarted the height map won’t apply, it loads and displays but that’s it, once a G32 has been carried out again you can print back to back with no hang ups until you turn the printer off, now I don’t have power off resume added to my config.g so I can’t test it but if a power loss occurs I would assume a restart print wouldn’t be able to be done.

Another thing I’ve noticed is on start up the hot end is always active wouldn’t it be safer to default it “off”?

Cheers Jim