Printer freezes at start of print
-
@PaulHew first height map, I have now levelled the bed further and will carry out G32 again!
Thanks
-
@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
Bearing block (smoothed).gcode
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!
-
@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
-
@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.
https://duet3d.dozuki.com/Wiki/Gcode#Section_M112_Emergency_Stop
https://duet3d.dozuki.com/Wiki/Gcode#Section_M122_Diagnose -
@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?