Babystepping bug

Phaedrux · 26 Jan 2019, 19:21

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.

jasperkm · 26 Jan 2019, 20:57

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

Phaedrux · 26 Jan 2019, 21:16

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 · 26 Jan 2019, 21:18

@phaedrux Is this a Voron2 by chance?

jasperkm · 26 Jan 2019, 22:47

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

Phaedrux · 27 Jan 2019, 00:24

What firmware version were you running before?

jasperkm · 6 Feb 2019, 20:28

2.02 RC4

RandomFactoid · 27 Jan 2019, 15:55

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.

RandomFactoid · 2 Jun 2019, 07:05

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

RandomFactoid · 6 Feb 2019, 20:13

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 ?

Phaedrux · 6 Feb 2019, 20:25

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

dragonn · 6 Feb 2019, 20:28

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

dc42 · 6 Feb 2019, 20:55

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