extra z-offset every new print G29?

o_lampe

@IndeX4D said in extra z-offset every new print G29?:

G91 G1 Z20 F400 G90

@droftarts Just wild guessing, but maybe there is a bug when switching to G91 and back to G90?
Maybe FW applies (or forgets?) the meshbed correction?

I have a similar line in my stop.g, but I usually do a paper test after each homing sequence.

jay_s_uk

@o_lampe i think the issue is bunching multiple gcode instructions on one line.
see this thread https://forum.duet3d.com/topic/32279/multiple-commands-on-single-line-bug-rf3-5b3

o_lampe

@jay_s_uk That would be easy to find out for @IndeX4D

IndeX4D

@o_lampe
oh I´m not sure.
So I should delete this at my end?

gloomyandy

@IndeX4D Try changing it to...

G91
G1 Z20 F400
G90

IndeX4D

@gloomyandy

ah ok
to easy to be true
ok thanks

IndeX4D

@gloomyandy
sadly, that´s not working. I still have extra space after every print

Phaedrux

Are you able to make a short video of the issue? Perhaps if we see what's going on we may get an idea.

IndeX4D

@Phaedrux
I´m not sure how to do it. How can I make a video of a wrong behaviour made by any wrong calculations or a bug.
I mean the printer makes more offset and this is happening somewhere between finishing prints and starting.
I just can make a video where you see the nozzle howering a little bit to high over the heatbed, but you´ll see exactly what I described in this sentence.

IndeX4D

Is it now a question, because you don´t believe I have this Problem?

Exerqtor

@IndeX4D
Well, you're asking for help mate, that by nature makes it a question.

It's not that @Phaedrux don't believe you, it's to make the forum easier to navigate.

Once you get it sorted out it will be changed to "Solved". Makes it easier for everyone ✌️

engikeneer

@IndeX4D Marking it as a question, means it is now tagged as 'Unsolved'. Means its more likely to get responses as people know you still have an issue without having to read every comment!

I'm going to add my thoughts on your issue here.

First, have you tried adding M561 to the start of your homez and bed.g files as @Phaedrux suggested a few posts back? If not, you will be homing and tramming with mesh compensation active, so the two may be fighting each other.

Also, do you rehome Z after running G32/bed.g? the G32 tramming will affect the homed Z-height. If you are running it with mesh enabled (i.e. in your second print!), then I can see errors compounding.

IndeX4D

ah ok thanks to all!
I´ll double check everything and post my results.

dc42

@IndeX4D I just looked at the height map that you posted on 23 May and that definitely isn't right. If you home Z and then run G29 immediately, the height map error should be zero in the vicinity of the print where you probed to home Z - which is X150 Y150 so close to bed centre. The only slightly dodgy thing you are doing is to increase the feed rate to 1000 in homez.g. Assuming you are running RRF3 then you should instead in the M558 command in config.g select double-tap probing with different feed rates for the first and subsequent taps.

Be aware that the M558 F1000 command in homez.g will persist into a subsequent G29 command.

The Z acceleration in your M201 command in config.g is set to 2000 mm/sec^2 which may be higher than it can manage if it is driven by a leadscrew. That might account for the problem you report.

IndeX4D

@dc42

ok thanks.
I have to wait for 3.5 beta4 before testing everything.

I´ll give an update!