Babystepping bug



  • Hi all,

    I have a problem when using duet, it's been going on for a while. When I turn on the printer and start a first print, sometimes I need babystepping of 0.05 or 0.1mm This is all OK and the print is perfect (first and second layer etc.) while babystepping stays at the value for the entire print.

    After the first print I remove parts from the bed and want to start a second print. Now babystepping is reset back to 0 and I need new offset (sometimes more than 0.1mm, like 0.2mm, extreme example). The first layer is then perfect but the second layer is mashed into the first layer causing overflow and problems when I keep babystepping at this value of like 0.2.

    I discovered that when I reset babystepping on the second print after the first layer using M290 R0 S0, the second layer is now good again. If I reset babystepping on the first print after the first layer, it prints too high and the print is messed up. Hope you understand what I'm saying. So this method kind of works, but I was wondering is this a bug in RRF, and can you maybe look into this? Thanks in advance.

    Duet Web Control 2.0.0-RC3 (this is unrelated, problem exist long before the update)
    Electronics: Duet WiFi 1.02 or later + DueX5
    Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.02(RTOS) (2018-12-24b1)
    Duet WiFi Server Version: 1.21RC4(08b3)

    Kind regards,

    Jasper



  • How are you homing before and in between prints?

    What do you have in your slicer start and end gcode?

    What is your Z axis? Is it repeatable, or are you getting backlash?

    What is your z probe? Is it repeatable, or are you getting slightly different height results each time?

    Can you post your config.g and homing files?

    Unrelated, but your wifi server version is out of date.



  • Before and in between print is always full xyz home
    Start code

    G21				;set units to mm 
    G90				;use absolute coordinates
    M290 R0 S0			;reset babystepping
    M220 S100			;reset speed multiplier
    G92 E0				;reset e count
    T0
    ;-----------------------Placeholder retraction and PA---------------------------------
    
    ;M207 S3.3 R0 F6000 T1800 Z0	;firmware retraction for 0.4mm nozzle abs
    ;M572 D0 S0.06			;pressure advance for 0.4mm nozzle abs
    ;M593 F38.5			;Dynamic acceleration adjustment  
    				;Divide the speed at which the outer perimeter was printed (in mm/sec) by the distance between adjacent ringing peaks (in mm)
    				;Change back acceleration to 3000 when turning this off, 3200 when on, can print 60mm/s outer perimiters with this
    
    ;-----------------------FIRST LAYER TEMPS---------------------------------
    M140 S105			;set bed temperature do not wait
    M109 S235			;set first layer temp and wait
    M98 P"/macros/homing/scripts/zhop_up.g"		;hop and home without moving back to center
    M98 P"/macros/homing/scripts/probe_x.g"		;home x
    M98 P"/macros/homing/scripts/probe_y.g"		;home y
    G90				;use absolute coordinates
    ;-----------------------PRIMING AND WIPING--------------------------------
    G0 X100 Y252 Z7 F9000		;drop down to 7 height for priming
    G92 E0				;zero the extruded length
    ;G1 E-4 F4800			;retraction move before wiping
    G90				;use absolute coordinates
    
    G0 X100 Y252 Z0 F9000		;wipe moves
    G0 X68 Y252 Z0 F9000		
    G0 X100 Y252 Z0 F5000		
    G0 X68 Y252 Z0 F5000		
    G0 X105 Y252 Z0 F1800	
    G0 X125 Y252 Z3 F9000	
    
    G0 X178.5 Y254 Z3 F9000            	;move to directly above mechanical Z-switch
    
    M98 P"/macros/zprobe/use_mslow.g"	;probe z offset
    G30	
    		
    G0 X100 Y100 F18000			;move to center of bed
    G1 E10 F150				;prime extruder
    G92 E0					;reset extrusion
    

    end code

    M104 S0					;turn off hotend/extruder heater
    M140 S0					;turn off bed heater
    M106 S0					;turn off fans
    G91					;set to relative positioning
    G1 Y20 X20 Z1 F2000			;move away from print quickly
    G1 E-5 F600				;retract the filament a bit before lifting the nozzle to release some of the pressure
    G1 Z30					;raise Z from current position
    G1 E-8 F500				;retract filament even more
    G90					;set to absolute positioning
    M98 P"/macros/moveto/park_xy.g"		;Move XY towards back
    M106 S255				;full fans for cooling hotend
    M106 P5 S255				;full exhaust fan
    M84 X Y E0:1				;Disable XY and E motors
    G4 S180					;wait 3 mins
    M106 S0					;fans off
    M106 P5 S0				;exhaust fan off
    M106 P7 S0				;leds off
    
    M140 S50				;set bed temp for remove parts
    

    Z axis is always good, 4 motors belted z, all tight, checked mechanics
    Z probe is mechanical offset switch for nozzle offset and induction on toolhead for bed leveling, bed is level within 1 microstep

    My homing files all refer to macros, do you want me to send them all ?
    0_1548536235170_config.g

    Thanks for looking into it

    I'll update wifi server



  • Yes, it would help to see your macros.

    With a belted Z there is the potential for backlach.

    Are you using mesh grid compensation as well?



  • @phaedrux Is this a Voron2 by chance?



  • Yes it's a voron2, macros are attached. After printer startup I run warmup macro, then print and everything is good.
    Then second print and babystepping causes issues.
    Not using mesh grid compensation, only G32 for bed leveling.

    IIRC, this problem occurred to me after updating to latest firmware, before that I didn't really have issues. I've tried my best to rule out anything voron related before posting here to see if it might be something in RRF.

    I've put the macros in a zip file, but it wouldn't let me upload so I made the extension .gcode. If you change it back to .zip it will open
    0_1548543015387_Macros.gcode



  • What firmware version were you running before?



  • 2.02 RC4



  • I have been having similar issues. I didn't need to babystep for the 1st print as I had the printer quite well dialed in. However if I wanted to start a second print straight away after removing the 1st one, it'd print at a higher z height. Interestingly it would be ~0.5mm too high even if I tried re-homing the printer. What's also surprising is that doing a simple papertest yealds the same results as before the 1st print - the nozzle does go to the same height as usual. No clue why but it seems like for the 2nd print duet applies some weird offset.



  • I know several people, especially from Voron users, were having these issues. Shame they're not really being addressed. I heard there might be an issue how the duet actually looks at leveling a moving gantry to a static bed and am thinking whether the issue is coming from there.

    I feel a few steps away from migrating to Klipper on a highly priced board such as the DuetWifi+Ex...which is a shame



  • I found this thread that looks very similar to our issue, however it's not homing related.
    https://forum.duet3d.com/topic/1042/z-as-reported-by-m114-increases-by-0-02mm-with-x-or-y-home-command

    To be honest I'm not sure what to make of this, but it looks like a lead to our problem could be here. Perhaps the pros have some insight ?



  • @randomfactoid There was a Z offset stacking issue that was resolved around 1.21/2.0 So if running the latest 2.02a firmware it shouldn't be an issue. That's not to discount that there may be some other issue.

    There was also an issue of I2C errors in communication between the Duet and Duex5. Have you seen the recent threads discussing that issue?

    I'm vaguely familiar with the Voron2 belted z axis setup. Have you confirmed that there is no backlash or binding happening to prevent repeatable z axis motion?

    The Voron2 probing routine is also a little complicated. Could you describe the probing sequence? Going through the configs is rather tedious because everything is spread out in multiple macros.

    Is the z probe giving consistent results if you probe with G30 S-1 multiple times?

    Can you try setting Probe type to P0 to enable manual jogging to set Z0 and see if the behaviour persists? This would remove the probe and any of its own issues from the equation just as a test.



  • @jasperkm said in Babystepping bug:

    2.02 RC4

    I don't understand why people are running RC version firmware when stable version is already available.
    First troubleshooting step should be updating to the latest stable version.


  • administrators

    @dragonn said in Babystepping bug:

    @jasperkm said in Babystepping bug:

    2.02 RC4

    I don't understand why people are running RC version firmware when stable version is already available.
    First troubleshooting step should be updating to the latest stable version.

    Quite so, I do not support beta or RC firmware versions when the corresponding stable release is available.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.