Babystepping bug
-
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.
