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

[Exerqtor]

Just slapped together a stripped down bed.g, hopefully i get time to test it either today or tomorrow.

bed.g

[DonStauffer]

@dc42 Here are my testing results.

In bed.g, I inserted immediately after my first G30:

		G1 Z25 F75
		M99

Then I homed and did a G32. Nothing that happened was unexpected. The motors all ran in the correct direction. So the only issue I can confirm is that the adjustment when the G30 with the S parameter executes goes in the wrong direction for one of the motors - and not always the same one. Initially it was #7. Then when I did my "manual" tramming with bed.g doing S-1 to report the correct adjustments, it was #6. I did that manual tramming over and over, making very conservative adjustments, and throughout several hours it remained #6. But it absolutely was a different motor than the problem started on. And there's no doubt it isn't just a simple reversal - it's conditional, only apparently happening on the G30 S adjustments.

So, my answer is "neither #1 nor #2".

[edsped]

Switched back to 3.6 alpha 2 +3 and for me at least it looks like it's applying the the leadscrew adjustments in the wrong direction. If you look at my screenshot the offsets pretty much double on each iteration. Note, for the initial print adjustments were similar to what I got on 3.5.2 but G32 after the print gave the wonky adjustments.

Disregard the bed.g warnings I inadvertently hit save when exiting out of the editor.

[edsped]

@edsped Running a second tram immediately following the above resulted in my front left leadscrew ending ~4mm higher than the other two... FWIW, the front left side of my bed is also where my nozzle crashed due to that corner of the bed being too high. I should clarify, higher on my printer is actually - Z

Edit:
Powered down and back up and now get the following on G32...

8/3/2024, 4:38:57 PM Error: Compensation or calibration cancelled due to probing errors
8/3/2024, 4:38:52 PM Error: G30: Probe was not triggered during probing move

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