extra z-offset every new print G29?
-
@droftarts
I did already above..G1 X610.176 Y449.295 E0.10056 G1 X611.585 Y450.704 E0.19684 G1 X610.566 Y450.704 E0.10066 G1 X609.158 Y449.295 E0.19677 G1 X608.14 Y449.295 E0.10056 G1 X609.548 Y450.704 E0.19677 G1 X608.53 Y450.704 E0.10056 G1 X607.121 Y449.295 E0.19684 G1 X606.103 Y449.295 E0.10056 G1 X607.512 Y450.704 E0.19684 G1 X606.493 Y450.704 E0.10066 G1 X605.085 Y449.295 E0.19677 G1 X604.067 Y449.295 E0.10056 G1 X605.475 Y450.704 E0.19677 G1 X604.457 Y450.704 E0.10056 G1 X603.048 Y449.295 E0.19684 G1 X602.03 Y449.295 E0.10056 G1 X603.439 Y450.704 E0.19684 G1 X602.421 Y450.704 E0.10056 G1 X601.012 Y449.295 E0.19684 G1 X600.745 Y449.295 E0.02637 G1 X600.745 Y450.046 E0.07419 G1 X601.402 Y450.704 E0.09185 G1 X600.745 Y450.704 E0.0649 ;TIME_ELAPSED:5734.465541 G1 F6000 E-0.2 M140 S0 M204 P4000 M204 T4000 M566 X1200 Y1200 M82 ;absolute extrusion mode M107 G91 G1 Z20 F400 G90 M83 ;relative extrusion mode M104 S0 ;End of Gcode
-
@IndeX4D said in extra z-offset every new print G29?:
@droftarts
I did already above..Sorry, yes you did, missed that. I’d say it’s this last Z move:
G91 G1 Z20 F400 G90
It’s at 6.66mm/s over a longer distance than usual Z moves. Try halving the speed to F200 and see if it still does it.
Ian
-
@droftarts ok
no problem
I´ll try it.
thanks -
@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.
-
@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
oh I´m not sure.
So I should delete this at my end?
-
@IndeX4D Try changing it to...
G91 G1 Z20 F400 G90
-
ah ok
to easy to be true
ok thanks -
@gloomyandy
sadly, that´s not working. I still have extra space after every print -
Are you able to make a short video of the issue? Perhaps if we see what's going on we may get an idea.
-
@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.
-
-
-
Is it now a question, because you don´t believe I have this Problem?
-
-
@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.
-
ah ok thanks to all!
I´ll double check everything and post my results. -
@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.
-