[3.5b1+] Inaccurate print dimensions

IndeX4D

My print dimensions are correct, but when start a new print the z axis is exactly 0.2mm to deep.
+
After pause, It seemed like the z offset has completely gone. Should I make a new thread about this?

-4 z-axis
-Axis compensation active

dc42

@IndeX4D said in [3.5b1+] Inaccurate print dimensions:

My print dimensions are correct, but after every print, but every new print hast the Z axis 0.2 to deep.
+
After pause, It seemed like the z offset has completely gone. Should I make a new thread about this?

Yes please! Include your config file, and whether you are using babystepping or any other use of M290.

Diamondback

@dc42
Ok so, here are the results from 3.5b1+:

Active leveling before the print + mesh bed compensation active -> Broken
Only mesh bed compensation -> Broken
Only active leveling -> No issue

So it appears that mesh bed compensation is indeed related in some way.

dc42

@Diamondback thanks, that's very useful.

dc42

@Diamondback

Do you have any layer change script in those models, or anything else happening during the print (after initial heating etc.) other than G1 commands?
Do you have daemon.g running?

Diamondback

@dc42 Not exactly sure what you mean with the first point, I can share the gcode though.
AccuracyDebug.gcode

As for daemon, yes, at that point it was a regular daemon.g with NO loop in it that has this content:

if state.status == "idle" && global.deactivateToolAfterFilamentChange == true
	echo "Unloading tool after filament change"
	T-1

set global.deactivateToolAfterFilamentChange = false

if state.status == "processing" && state.gpOut[1].pwm > 0 && job.layer == 3
	M98 P"/macros/Misc/Lights/Off"

dc42

@Diamondback I tried to reproduce this on my tool changer, which uses a 6HC, but the print using the current RRF 3.5 build was the same height as the one using RRF 3.4.5 and doesn't show the layer artefacts. I had mesh bed compensation enabled.

Have you time to run some more tests? If so:

Please try the latest RRF build for the 6HC at https://www.dropbox.com/sh/5vxz29a7400gwcy/AAAPexxpGsP0LMo0jEFOOCqVa?dl=0
If it shows the same issue, try stopping the daemon task (rename daemon.g to something else)
If it still shows the same issue, try disabling bed compensation and instead enable segmentation using M669 S100 T10 (preferably, replace the 10 by the mesh spacing you use). This will tell me whether it is the bed compensation that provokes the issue, or the segmentation that occurs when bed compensation is enabled.

Diamondback

@dc42 Currently printing some actual parts, will do these tests afterwards.

dc42

@Diamondback do you have bed compensation taper enabled?

EDIT - yes I see that you have, from your config.g. Does disabling taper make the problem go away?

Diamondback

@dc42 Yes I do, will test that as well.

dc42

@Diamondback did you have a chance to run any tests?

Diamondback

@dc42 Literally printing tests all day already, I have issues replicating the issue on any of the 3.5 builds and trying to find out what changed. Since you mentioned daemon.g as a possible cause I'm reverting some changes there (most notably going back to the 10s dameon stuff rather than having an infinite loop in there)

I'll keep you posted.

Diamondback

@dc42 Hm, yea, I can't replicate this anymore, even with my older daemon setup (and this was perfectly possible before, I printed multiple instances with and without issues across multiple firmware flashes...) I will keep using the array element set build and see if it randomly comes back...

One thing I noticed about that build is that the Z acceleration seems weird/broken? When decreasing my Z position, it seems to use a tiny acceleration value instead of the defined one. Increasing Z works fine at the same time.

dc42

@Diamondback thanks for testing this.

@Diamondback said in [3.5b1+] Inaccurate print dimensions:

When decreasing my Z position, it seems to use a tiny acceleration value instead of the defined one. Increasing Z works fine at the same time

Is it only during probing moves that the acceleration is low? If so, that's expected because of a change to the M201.1 defaults.

Diamondback

@dc42 Yup, looks like it's only during probing. Shall I specifically add a M201.1 then to configure that? I would have expected it to use the normal defaults if no M201.1 is present?

dc42

@Diamondback yes, I suggest you add a M201.1 command for now.

I am thinking of changing M201.1 to take a percentage value of the normal acceleration in 3.5beta3 instead of an actual acceleration.

Diamondback

@dc42 Hmm, I wish I remebered which tool I printed the prints with issue with....
Two of my tools use extruders on a slave Mini 5 board while the other two tools are connected to the 6HC... Maybe it has to do with the extruders not being on the main board?

I just went back to older builds (specifically the one where you fixed the Mini 5 Slave OoM error) and I can see hints of the issue appearing again when I use one of the tools with an extruder on the Mini 5. It's not as bad as before, but maybe other things play a role.

I'll keep experimenting...