[3.5b1+] Inaccurate print dimensions

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