Following closely this excellent discussion. Thank you all!
Just one note: I don’t think, whole numbers for the measurements are any important for the users. Various impacts will always make those numbers off anyway. And users might be unhappy if one number is closer to whole and another is off, while they should only compare those numbers to each other.
So maybe it is even better to choose them deliberately off to protect users from bias.
2 Likes
don’t mix info from the old and new post
Ok, sorry for that. I’ll check with the formulas in the latest post.
1 Like
UPDATE: *pictures have been replaced and minor edits to match. I updated my skew representation to more accurately match actual machine kinematics. Previously some controlling dimensions in the skewed shape (height of square and octagon) were aligned to the skew angle - this was incorrect. Those dimensions were moved to align to the Y-Axis, because that’s the move the machine will physically make (at those same values). This changed the effect a bit but overall is still valid. A couple small aspects of the explanation changed as a result.
Same here, I knew there was a mismatch with something I was seeing but was having a hard time pinning it down.
When I stepped away from the problem something dawned on me and I’ve got one more thing to add to this that will be a more satisfying conclusion for the both of us. The “mismatch” I mentioned is real in the physical world and the math of using a hexagon is sound. Both things are true.
I know where this went wrong and think I see the whole picture now. There was an evolution in what I discovered trying to represent the skewed octagon shape - first I set it up where I saw it influencing the size of the calculated square, then I set it up where I saw it show a problem when the “square” became a rectangle. Looking back I think it all related to the angular relationship of the squares diagonal and the 45 deg. side of the Octagon.
I wanted to make that relationship 90 degrees. That’s the way an octagon works and more specifically thats the way we assume our physical measurement works - that we put the calipers across the related sides of the printed piece and we get the real number of that diagonal. This ends up being the variance I was chasing…
The orientation we’re measuring across (spanning the 45’s of the octagon) isn’t actually perpendicular to the diagonal of the “square” under all conditions - only under one, when there is no skew. As soon as there is, you are technically measuring a different length over the sides of the octagon - that diagonal and the octagon faces are no longer perpendicular to each other.
In yellow: top number is aligned to Octagon, bottom number is aligned to the squares diagonal. In blue: angle of Octagon sides to the squares diagonals
Left shapes: “equal side square”. Right shapes: “rectangular” (top, skewed shape only)
Having said that, it takes a lot of skew to get a significant effect where this really matters in the practical world. Its slightly annoying to have a variable like this that you can’t take out in practice, but ultimately not really a problem here.
If the aspect ratio of the print is off and things become more “rectangular” that has an interesting secondary effect that can either correct for, or compound, how far away from perpendicular the diagonal of the “square” and the octagons sides are to each other. This sketch I’m using is parameter driven for skew and aspect ratio, I tested a bunch of stuff and this mostly looks more pronounced when your “square” has “equal” sides and you apply a higher angle of skew (I know the terms are problematic - by “equal square” I mean for that shape X-Width = Y-Travel, in the example below - the green dimensions).
The octagon doesn’t really do anything worse either (and from this, for me, it’s now given a firm understanding of what’s at play). The original Bambu support shape for skew measurement essentially had octagon faces already (just shorter stubs of it ends of the diagonals). Having a face of the octagon, short or long, enforces the same orientation of the measurement.
It’s obvious that there’s no real good way getting away from it, if you try to eliminate this it’s just harder to measure and prone to an even bigger error that overshadows what you’re trying to eliminate (and other print related issues like bulging corners). I’m just happy to have a better perspective on what didnt add up. This ended up having nothing to do with using the Octagon to calculate the square, but by looking into the relationship of the octagon and square geometrically, it revealed that there is this discrepancy with the alignment of the physical measurement.
One more exaggerated example (large skew angle but “equal” width “square”)…
1 Like
@Nebur Thanks for that clarification. Marlin refer to it as XY_SKEW_FACTOR so they use a ratio. Can we assume that Bambu does too? I think it will be difficult to determine this from a test print and measurements. @jason.t In your calculator you also use an angle in radians as the skew factor for the I parameter.
You could open a ticket with bambu and ask them what formula they are using for xy_comp_ang.
1 Like
That might be worth trying. They might just say that they don’t currently support the use of the In parameter.
I’ve reverted back to using a ratio in my calculator. I now think that’s probably the input that Bambu use for their skew compensation.
One way we could figure it out is applying a skew correction with M1005 X Y, saving, then checking to see what the stored XY_comp_ang is. Then we do the same calculation and see which value matches the one saved on the machine.
Easy way to find this is searching syslog for “M1005”. If you have root access I mean. There’s an Mqtt command to check it too, but a user was having trouble with it so I’m going to look into that more
If you input M1005 X Y I am pretty sure it estimates the measurement it’s missing and then does the same calculation that is in your worksheet (or is very similar). So it should be saving an XY_comp_ang value from this.
I haven’t yet got root access and haven’t had a XY_comp_ang response via MQTT.
Here’s an extract from syslog from @EdStreet in an earlier post so they do refer to it as an angle:
Could someone with root access test this as suggested by @Thermal_Runaway above?
In practice, for small skew angles, the difference between inputting a ratio or an angle is tiny. In the case of my printer with ~ 0.2 degrees of skew the inputs are the same to 7 decimal places of precision.
But it would be good to get it right.
Ok!! Here is some data for everyone to play with. I grabbed several M1005 X__ Y__ values and pulled the comp_ang from the logs. If anyone wants to find out what their I value is then reply and I will grab that. I did toss in some that I have seen in the post above.
M1005 X79.37 Y79.55
Apr 29 15:29:13 info forward[1033]: [MCU][BMC]M1005:M1005 X79.37 Y79.55
Apr 29 15:29:13 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00050
Apr 29 15:29:13 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00277M1005 X79.62 Y79.51
Apr 29 15:32:57 info forward[1033]: [MCU][BMC]M1005:M1005 X79.46 Y79.67
Apr 29 15:32:57 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00277
Apr 29 15:32:57 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00541M1005 X79.46 Y79.67
Apr 29 15:35:14 info forward[1033]: [MCU][BMC]M1005:M1005 X79.46 Y79.67
Apr 29 15:35:14 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00541
Apr 29 15:35:14 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00805M1005 X79.52 Y79.60
Apr 29 15:36:39 info forward[1033]: [MCU][BMC]M1005:M1005 X79.52 Y79.6
Apr 29 15:36:39 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00805
Apr 29 15:36:39 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00905M1005 X119.61 Y119.67
Apr 29 15:38:43 info forward[1033]: [MCU][BMC]M1005:M1005 X119.61 Y119.67
Apr 29 15:38:43 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00905
Apr 29 15:38:43 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00955M1005 X50 Y50
Apr 29 15:40:42 info forward[1033]: [MCU][BMC]M1005:M1005 X50 Y50
Apr 29 15:40:42 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00955
Apr 29 15:40:42 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00955M1005 X120 Y120
Apr 29 15:45:19 info forward[1033]: [MCU][BMC]M1005:M1005 X120 Y120
Apr 29 15:45:19 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00955
Apr 29 15:45:19 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00955Apr 29 15:47:20 info forward[1033]: [MCU][BMC]M1005:M1005 X119.98 Y119.98
Apr 29 15:47:20 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00955
Apr 29 15:47:20 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00955Apr 29 15:49:29 info forward[1033]: [MCU][BMC]M1005:M1005 X119.10 Y119.11
Apr 29 15:49:29 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00955
Apr 29 15:49:29 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00964M1005 X79.95 Y79.61
Apr 29 15:52:16 info forward[1033]: [MCU][BMC]M1005:M1005 X79.95 Y79.61
Apr 29 15:52:16 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00964
Apr 29 15:52:16 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00538–>>> M1005 I0.004262
M1005 X120.28 Y120.01
Apr 29 15:56:18 info forward[1033]: [MCU][BMC]M1005:M1005 X120.28 Y120.01
Apr 29 15:56:18 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00538
Apr 29 15:56:18 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00313
–>>> M1005 I-0.002247M1005 I-0.002247
Apr 29 15:59:04 info forward[1033]: [MCU][BMC]M1005:M1005 I-0.002247
Apr 29 15:59:04 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00313
Apr 29 15:59:04 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = -0.00225M1005 X119.63 Y119.66
Apr 29 16:04:50 info forward[1033]: [MCU][BMC]M1005:M1005 X119.63 Y119.66
Apr 29 16:04:50 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = -0.00225
Apr 29 16:04:50 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = -0.00200M1005 I0.000502
Apr 29 16:10:50 info forward[1033]: [MCU][BMC]M1005:M1005 I0.000502
Apr 29 16:10:50 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = -0.00200
Apr 29 16:10:50 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.00050
1 Like
Thanks @EdStreet
Could you try:
X120.77 Y101.34
and:
I-0.1745
That’s a skew angle of 10 degrees. That should show a difference in the 3rd decimal place which is within the 5 decimal places of precision used by Bambu.
Sure.
Apr 29 16:34:30 info forward[1033]: [MCU][BMC]M1005:M1005 X120.77 Y101.34
Apr 29 16:34:30 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = 0.00050
Apr 29 16:34:30 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = -0.17313Apr 29 16:35:49 info forward[1033]: [MCU][BMC]M1005:M1005 I0.1745
Apr 29 16:35:49 info forward[1033]: [MCU][BMC]M1005:current XY_comp_ang = -0.17313
Apr 29 16:35:49 info forward[1033]: [MCU][BMC]M1005:new XY_comp_ang = 0.17450
Hmm the user Nebur mentioned that they were not receiving the mqtt response either. I will look into it. I’m running version 01.07.00 currently (x1plus runs on 01.07.03 though) so it’s possible the command has changed a bit in the last couple revisions.
1 Like
These are the inputs:
X=120.77 Y=101.34
Result:
I=-0.17313
“Current” XY_comp_ang is the value it’s calculated but hasn’t saved yet.
Thanks.
I calculate that In should be -0.17451 as an angle or -0.17631 as a ratio.
So it looks like Bambu are using an angle.
The result of the Xn Yn input will depend on how Bambu are deriving the angle from only 2 measurements.
EDIT:
I corrected the sign (-ve) of the results of my calculation.
@EdStreet I think you used I0.1745 instead of I-0.1745 but that doesn’t really matter.
1 Like
I’m pretty sure they’re using some kind of linear regression to produce these values so this makes sense. Values chosen based on confidence intervals. I don’t think it’s possible to avoid overshoot when using that form of the command
1 Like
So, I’m going to go back to using the angle in radians in my calculator.
I don’t think it really matters in practice but it will mean the results are compaible with the output in Bambu’s syslog for anyone testing large skew angles.
Thanks for all your help with this.