Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Start of print; XY move to max, extruder rattles

    Scheduled Pinned Locked Moved
    Duet Hardware and wiring
    4
    8
    426
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • DaBitundefined
      DaBit
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • Phaedruxundefined
        Phaedrux Moderator
        last edited by

        What do you have in homeall.g?

        Z-Bot CoreXY Build | Thingiverse Profile

        1 Reply Last reply Reply Quote 0
        • DaBitundefined
          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)

          1 Reply Last reply Reply Quote 0
          • Phaedruxundefined
            Phaedrux Moderator
            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.

            Z-Bot CoreXY Build | Thingiverse Profile

            1 Reply Last reply Reply Quote 0
            • DaBitundefined
              DaBit
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators
                last edited by

                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.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                1 Reply Last reply Reply Quote 1
                • DaBitundefined
                  DaBit
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • jay_s_ukundefined
                    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

                    Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Unless otherwise noted, all forum content is licensed under CC-BY-SA