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
    RRFirmware: 2.04
    DWC 2.0.4

    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?



  • What do you have in homeall.g?



  • ; 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)



  • 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.


  • administrators

    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.



  • 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


Log in to reply