Z-axis / tramming issues with 3.6.0-alpha2+3

[DonStauffer]

@edsped Interesting. I was only having one of the three go in the wrong direction.

[edsped]

@DonStauffer That's what mine was doing the first time. I reverted to 3.5.2 then back to 3.6 a2+3 and added the M400 as suggested by @dc42 and what I posted above are my results. This time knowing what I was looking for I was able to bail before anything bad happened.

[dc42]

Currently, after performing probing a bed tramming move is executed with all Z motors moving simultaneously in different amounts and a mixture of directions. Would there be any problem if the Z motor moves were executed one at a time sequentially instead?

[gloomyandy]

@dc42 Could this in some situations cause a nozzle strike? I'm thinking of a situation with a very highly tilted bed and homing/probing in the middle portion of the bed, you could in theory end up with the nozzle lower then one edge of the bed and if you then raise the (currently) lower edge first the bed would hit the nozzle? The same situation with a simultaneous move may not cause the strike? Probably not very likely though.

Possible mitigating actions: Perform any negative (moving the bed away from the nozzle) moves first? Limit the distance each motor moves in one operation and cycle through the motors until the move is complete?

[dc42]

@gloomyandy said in Z-axis / tramming issues with 3.6.0-alpha2+3:

ould this in some situations cause a nozzle strike? I'm thinking of a situation with a very highly tilted bed and homing/probing in the middle portion of the bed, you could in theory end up with the nozzle lower then one edge of the bed and if you then raise the (currently) lower edge first the bed would hit the nozzle?

If the probe had to make a deeper than normal move ton reach the lower edge, it will still rise to the dive height above the Z=0 reference afterwards. So I don't think this is a risk, provided that the maximum permitted correction is less than the dive height - which already needs to be the case if nozzle strikes are to be avoided.

[Exerqtor]

@dc42 said in Z-axis / tramming issues with 3.6.0-alpha2+3:

Currently, after performing probing a bed tramming move is executed with all Z motors moving simultaneously in different amounts and a mixture of directions. Would there be any problem if the Z motor moves were executed one at a time sequentially instead?

@gloomyandy said in Z-axis / tramming issues with 3.6.0-alpha2+3:

@dc42 Could this in some situations cause a nozzle strike? I'm thinking of a situation with a very highly tilted bed and homing/probing in the middle portion of the bed, you could in theory end up with the nozzle lower then one edge of the bed and if you then raise the (currently) lower edge first the bed would hit the nozzle? The same situation with a simultaneous move may not cause the strike? Probably not very likely though.

Possible mitigating actions: Perform any negative (moving the bed away from the nozzle) moves first? Limit the distance each motor moves in one operation and cycle through the motors until the move is complete?

I don't know if this is possible, but is it possible to do it sequentially like you are proposing, but RRF "automatically" choose which axis/stepper to move 1st, 2nd, 3rd, etc. depending on the specified adjustmen that has to be made (taking my drive mapping as example)?

; (While looking at the printer top down)
;             0.0-----0.1
;              |  0.2  |
;              |-------|
;              |0.3|0.4|
;               ---+---
;                Front
;  Driver 0.1 & 0.2 is for the CoreXY motion, 0.2-0.4 is for the bed kinematics.

Example 1:
Adjustments needed after probing:

• Driver 0.2 = -0.5mm
• Driver 0.3 = -0.2mm
• Driver 0.4 = +0.9mm

To avoid potential nozzle craches RRF will move the driver/axis that needs to adjust TOWARDS the nozzle last, and the driver/axis that needs to move the most AWAY from the nozzle first:

1. Lower driver 0.4 by 0.9mm.
2. Raise driver 0.3 by 0.2mm.
3. Raise driver 0.2 by 0.5mm.

This should both put the least mechanical strain on the bed (depending on how the bed is built ofc.), and it would provide maximal clearance to the nozzle.

Example 2:
Adjustments needed after probing:

• Driver 0.2 = +3.7mm
• Driver 0.3 = -0.3mm
• Driver 0.4 = +1.1mm

Adjustment order:

1. Lower driver 0.2 by 3.7mm.
2. Lower driver 0.4 by 1.1mm.
3. Raise driver 0.3 by 0.3mm.

[dc42]

@Exerqtor that's a good idea.

[gloomyandy]

@Exerqtor said in Z-axis / tramming issues with 3.6.0-alpha2+3:

To avoid potential nozzle craches RRF will move the axis the driver/axis that needs to adjust TOWARDS the nozzle last, and the driver/axis that needs to move the most AWAY from the nozzle first:

Yes that's what I was suggesting with:

@gloomyandy said in Z-axis / tramming issues with 3.6.0-alpha2+3:

Possible mitigating actions: Perform any negative (moving the bed away from the nozzle) moves first

[Exerqtor]

@dc42 Got any builds I/we could test incorporating this commit?

[dc42]

@Exerqtor yes, is this for D3 Mini or another board?

[Exerqtor]

@dc42 said in Z-axis / tramming issues with 3.6.0-alpha2+3:

@Exerqtor yes, is this for D3 Mini or another board?

Yes in my case it's for a D3 mini at least ☺️

[dc42]

I've put new RRF builds at https://www.dropbox.com/scl/fo/yc7mnauicu5vqw6yegeq7/AKnV4j8k1MCADG4VE4EIG6Y?rlkey=skjxh23i9c953yvxm2tb8qr36&dl=0. Some notes:

• The issue with bed tramming might be fixed. I don't have a suitable machine to test it on.
• Scanning Z probes are fixed (they didn't work in previous 3.6.0 alpha releases)
• Also included are 3.6.0 alpha versions of some expansion board firmware (not EXP1HCL or M23CL). You can revert to 3.5.2 versions if you have any issues with them.

See https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-beta1-in-preparation for more details.

[edsped]

@dc42 Still seeing accumulation on one of the leadscrews so I'm hesitant to test...

[edsped]

@dc42 Same iterations on 3.5.2

[o_lampe]

@dc42 said in Z-axis / tramming issues with 3.6.0-alpha2+3:

The issue with bed tramming might be fixed. I don't have a suitable machine to test it on.

IIRC, the problem was also seen on a Delta printer...that's why I hesitate to test 3.6.a+

[dc42]

@o_lampe no this issue does not affect deltas.

[dc42]

@edsped thanks, looks like it's adjusting the 3rd leadscrew the wrong way on the second and subsequent iterations.

[dc42]

I have now reproduced and fixed this issue. I've prepared a new alpha release which I hope to make available tomorrow after some internal testing.

[Exerqtor]

@dc42 Sweet, i just saw the commits and was about to ask for a build, but i'll wait til you've done the internal one

[edsped]

@dc42 Awesome, looking forward to giving it a try as improved input shaping looks very promising.

Running a 6HC board FWIW.