Start of print; XY move to max, extruder rattles
From time to time I have some weird behaviour when I start a print from the Jobs panel in DWC. The file executes until somewhere after the G28, then the X and Y axes move to their respective maximums, the extruder starts rattling, and that is what it keeps doing.
If I hit the emergency stop button when that happens and select the job again, printing starts fine.
Board: Duet2 Wifi
Printer is a CoreXY, a 24V/400W supply powers the printer electronics, bed is a 230V heater.
What I do:
- Enter DWC, start preheating bed and hotend
- Slice in CURA
- Use CURA plugin to upload to printer (but not start the print directly)
- Wait until the bed reaches thermal equilibrium
- in DWC, go to File Management->Jobs, select and start job
Start of the G code:
;Generated with Cura_SteamEngine 4.4.0 T0 M190 S110 M104 S235 M109 S235 M82 ;absolute extrusion mode G28 ;Home G29 S1 ; load mesh calibration G1 Z15.0 F6000 ;Move the platform down 15mm M83 ;relative extrusion mode G1 F1500 E-1 ;LAYER_COUNT:532 ;LAYER:0 M107 G1 F600 Z0.4 G0 F7200 X92.438 Y87.425 Z0.4 ;TYPE:SKIRT G1 F600 Z0.3 G1 F1500 E1 G1 X92.997 Y86.868 E0.04076
Heating and homing goes well, somewhere after homing the printer decides to move to Xmax, Ymax and start rattling the extruder; not sure what the drive gear is doing at that moment; it is invisible on a Bondtech BMG-X2.
As said before, when rebooting the Duet by hitting the emergency stop button or powercycling I can go into the DWC, select the job, and it prints just fine.
I am not sure yet if there is a link between uploading through the CURA plugin and this behaviour.
Anyone knows what causes this?
Phaedrux last edited by
What do you have in homeall.g?
DaBit last edited by DaBit
; homeall.g ; called to home all axes ; M98 Phomex.g ; BvH: this does Y too M98 Phomez.g
; homex.g ; called to home the X axis M98 Phomey.g ; BvH: Always home Y first to bring the carriage near the X home switch M98 Plowmotorcurrents.g ; BvH: switch to low motor currents. Prevents mechanical damage when a limit switch fails G91 ; relative positioning G1 Z5 F6000 H2 ; lift Z relative to current position G1 H1 X-265 F2000 ; move quickly to X axis endstop and stop there (first pass) G1 X10 F6000 ; go back a few mm G1 H1 X-20 F360 ; move slowly to X axis endstop once more (second pass) G92 X5 G1 Z-5 F6000 H2 ; lower Z again G90 ; absolute positioning M98 Phighmotorcurrents.g ; BvH: back to regular/high motor currents again
; homey.g ; called to home the Y axis M98 Plowmotorcurrents.g ; BvH: switch to low motor currents G91 ; relative positioning G1 Z5 F6000 S2 ; lift Z relative to current position G1 S1 Y270 F1800 ; move quickly to Y axis endstop and stop there (first pass) G1 Y-5 F6000 ; go back a few mm G1 S1 Y7 F360 ; move slowly to Y axis endstop once more (second pass) G1 Z-5 F6000 S2 ; lower Z again G90 ; absolute positioning M98 Phighmotorcurrents.g ; BvH: back to regular/high motor currents again
; homez.g ; called to home the Z axis ; ; generated by RepRapFirmware Configuration Tool v2.0.4 on Thu Oct 03 2019 22:32:52 GMT+0200 (Midden-Europese zomertijd) G91 ; relative positioning G1 Z5 F6000 S2 ; lift Z relative to current position G90 ; absolute positioning G1 X115 Y115 F6000 ; go to first probe point G30 ; home Z by probing the bed ; Uncomment the following lines to lift Z after probing G91 ; relative positioning G1 S2 Z5 F100 ; lift Z relative to current position G90 ; absolute positioning
; lowmotorcurrents.g ; BvH: program low motor currents and speeds, somewhat higher acceleration. Used during homing ; M906 X1800 Y1800 Z1800 E700:700 I30 ; set motor currents (mA) and motor idle factor in per cent
; highmotorcurrents.g ; BvH: program high/regular motor currents and speeds. Used during normal operation ; M906 X1800 Y1800 Z1800 E700:700 I30 ; set motor currents (mA) and motor idle factor in per cent
(these two are identical at the moment; need to address the overheating issues at higher currents)
Phaedrux last edited by
So this happens randomly? And if you restart the same file after an emergency stop it will print successfully?
Just a shot in the dark, but try adding an M400 before calling your motor currents files.
Yes, it happens randomly. And after powercycling the printer or hitting the emergency stop button I can select the job in DWC and it will execute fine.
I have a gut feeling that uploading the file (CURA plugin) and then starting the print (DWC) somehow has something to do with it.
I cannot remember seeing this behaviour when powering up the board and starting the print from SD by selecting the job in DWC.
But as said: a gut feeling at this time, I have not yet put much research in it.
I will add the M400 to the motor current macros. That is a good idea anyway.
M400 is needed before using M913 to adjust motor currents, but not before M906. The reason for the difference is so that when M913 is used to reduce motor currents in the power fail script, it happens immediately instead of waiting for all queued moves to complete.
Updated to RRF 2.05RC1 last week, behaviour is still there. M400 before M906 makes no difference, as expected.
It definitely has something to with uploading through the Cura plugin and immediately starting the print afterwards. I have not seen the weird behaviour when I upload first, hit the EStop button in DWC, and then start the job. I also have not seen the behaviour when I upload through DWC.
Hitting EStop before printing is a useable workaround, but something is buggy somewhere.
jay_s_uk last edited by
I upload using the cuts plugin all the time and swap between using the "print" function to automatically start a print and using the upload function.
It's not caused any issues for me yet.
I'm currently on 2.04