Babystepping bug
-
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 codeG21 ;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 extrusionend 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 partsZ 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 microstepMy homing files all refer to macros, do you want me to send them all ?
0_1548536235170_config.gThanks 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-commandTo 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. -
@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.
