Skew compensation in the Bambu X1C Firmware

[olxs]

Got my level…

(1) square as intended with corners A,B,C,D
(3) same as square (1) after skew printing with corners Ap,Bp,Cp,Dp

(2) same as square (1) rotated over 45 degrees with corners A’,B’,C’,D’
(4) square (2) after skew printing with corners A’p, B’p, C’p, D’p

Skew printing does not change the length of A-B,A-D etc. in (1) versus Ap-Bp,Ap-Dp etc. in (3) since these lengths are directly related to the timing belts of the printer.
However angle DAB is affected. And after printing the square has become a rhombus in (3).
Therefore, the length of diagonal A-C increase while length of diagonal B-D decreases by the same fraction. Both the diagonals A-C and B-D in (1) and Ap-Cp and Bp-Dp in (3) are perpendicular.

Now in drawing (2) and (4) the square in (1) is rotated over 45 degrees (2).
Basically the diagonal directions in (1) and (3) are swapped with the sides in (2) and (4) and the other way around.

Skew printing of (2) results in (4). Since the original directions A-C and B-D in (1) remain square in skew printing, A’-B’ and A’-D’ (2) versus A’p-B’p and A’p-D’p will remain square in skew printing.

However in (1) compared to A-C,B-D Ap-Cp has increased in length while Bp-Dp has decreased. Translating this to the rotated print from (2) to (4), the skewed A’p-B’p in (4) will increase with respect to the original A’-B’ in (1), while A’p-D’p in (4) will decrease (by the same fraction) with respect to A’-D’ in (2).

Bottom line, by rotating the original print object by 45 degrees a square becomes a rectangle (with perpendicular sides) instead of a rhombus. It should be possible to measure this back in those octagon prints.

As you can be seen from the drawings, this will only work for small skew angles. Which is hopefully the case.

Fixed typo in the description.

[EdStreet]

I Have a reply from Bambu on my ticket. The attached photo is their math used. @Nebur will have a field day with this one. They are making the skew into a right triangle and solving basic info, which is not correct.

[EdStreet]

@Nebur

Edit: Also - what kind of maniac writes on a pad with the spiral at the bottom - my hand hurts just looking at it

Sure here is the reply. I asked this

I would like to know the following. What is the formula used to calculate M1005 Xn Yn. It is our belief that the formula used is incorrect and gives errors.

WE have a post on the forums about this issue as well. see here for the discussion. Skew compensation in the Bambu X1C Firmware - #282 by EdStreet

[EdStreet]

@Nebur

Edit: Also - what kind of maniac writes on a pad with the spiral at the bottom - my hand hurts just looking at it

On a side note, Asian culture uses top-to-bottom writing. Many cultures also use right to left, and others use the left to right.

[klomar]

@olxs Thanks for the diagrams. It’s an interesting and clever idea but perhaps it’s not the most practical solution because of the drawbacks you mention and constraints on the placement of prints on the print bed. But it does highlight the implications for skew when you rotate the orientation of a print. Thanks for your contribution to our discussions!

[MrDB42]

@EdStreet

M500 is in there more than once.

I have to make a comment about this tidbit. Yes, in the start G-code section there are 3 total M500’s. Two of them are in conditional sections, and one M500 R (only Bambu knows what that one does). The M500 R is in the “laser and rgb calibration” section, so it’s only valid for the X1 series printer.

The conditional sections are for if you tick the ‘Bed Leveling’ and ‘Flow Dynamics Calibration’ check boxes at the time of sending your print to the printer.

If you uncheck those boxes, you only get M500 R processed on the X1 series printer.

My gut tells me that Bambu didn’t realize that the M500 wasn’t saving data properly till this skew debacle started. So, if you did tick those checkboxes, none of those updated calibrations were being saved no matter what.

EDIT: Or it’s just the skew and dimension commands not being saved… Who knows for sure.

[Thermal_Runaway]

Good news, in the latest update it looks like Bambu has fixed the save bug.

They have also added a toggle so it can be disabled without wiping the value.

Also in case anyone was wondering, it is most definitely possible to apply a skew while your printer is running. Be careful though. What I had in mind was micro-stepping skew value within the same print, so a calibration can be done with actual values being tested. I believe it will be possible to calibrate skew without any calculations at all. I have nothing against calculations, but my printer’s gantry will never be a perfect square so it doesn’t care about math.

Here’s an example:
5x5 grid of 4mmx4mm cubes printed on top of a thin raft. the first cube is printed with a skew of -0.5 deg, second is printed with a skew of -0.45 deg … and so on. The model will appear as a grid of perfect cubes, and gcode will be used to apply skew.

Then measure each cube. This model can be created with a script, so the skew range and grid size could be customized.

[ProtoSpyre]

This is making my big boy brain hurt… the incorrectness of incorrect. Please don’t tell me this is who operates R&D or engineering.

[Thermal_Runaway]

You can either solve the pythagorean theorum repeatedly or you can get straight to the point with trig functions. It makes little sense in my brain when represented with 5 different pythagorean equations, and a lot more sense when the trig relations are used.

You get the same result either way, so there are several right answers here.

I made this little drawing in illustrator to show what makes sense in my smooth brain. (the y_skew formula below is the only one Bambu is using at the moment, in a slightly convoluted way)

[ProtoSpyre]

Now this is mathing

[EdStreet]

As above linear vs non-linear ranges are at play here. The correct answer that yields more accurate results across the board is the non-linear method. This was the reason for the repeat usage of the linear equasions to adjust for the drifts.

[Thermal_Runaway]

The calculation that Bambu shared and the one in the post above are the same calculation but Bambu is apparently using the quadratic formula and the equation above uses trig. I’m not sure I’d say one is more correct than the other. They both use different assumptions, so you do have a point in that the correctness depends on the validity of the assumptions

[MrDB42]

@ProtoSpyre

Now this is mathing

That’s the fun thing about math, there are many ways to get to an equation of the same concept.

This goes along with what one of my math instructors said: Math is a language, it has rules, syntax, etc. just like any other language (English, Spanish, German, etc.). But there is one thing we do with math. We take the complex and try to make it as simple as possible. By complex, we take an equation with a lot of operations (+, -, /, *, sqrt, limits, sin, cos, tan, integrals, differentials, etc.) and try to get it down to the lest number of operations. It’s a “game” in a sense. Sometimes you think you got to the least number of operations at the end, then someone else comes along and points out “If you use this… you can simplify it even more”. Or “If you go at it this way, you end up here with only this number of operations.”

An example is that I found another formula for finding the skew angle. I used WolframAlpha and plugged in my original equation just to make sure I did it right, and it spat out a different equation with fewer operations than mine. I didn’t feel like signing up for the monthly subscription to get the ‘step-by-step’ explanation, so I decided to try it myself and I did get there by seeing something and thinking “HEY!!! I’ve seen this formula before and there is a substitution/relation for it, but what is it.” Looked it up and substituted it, and got the same answer as WolframAlpha.

So, here’s another formula for finding the skew correction:

Edit:
Going from a lot of operations, down to the least number of operations = “Simplify the equation”

[Thermal_Runaway]

I just made something quite evil… a skew compensation slider in a branch of x1plus that will never be public

I hope to report back with some truly cursed results.

[EdStreet]

You do know that someone one said that art that is not shared is a crime against humanity right?

[Thermal_Runaway]

Here’s one to get the ball rolling.

This is just messing around with skew on a 20x20mm cube. Just manually flipping the slider back and forth. I haven’t even touched M290.2 yet!

While this is quite entertaining, I do have some results on a more controlled skew adjustment for a calibration procedure. I will share in a bit. If anyone skilled at designing calibration methods would be interested in helping design and test a skew calibration that requires no calculation at all, I am more than happy to share any scripts or data that would help.

[klomar]

I just don’t understand how you get that shape by adjusting skew. It looks like the length along one axis of the print is changing and position is shifting along that axis too but I can’t see the orientation of any of the sides changing. Was it printed in that orientation on the print bed? What range of skew were you adjusting it through?

Edit: Was the square rotated 45 degrees on the printbed?

[Thermal_Runaway]

Yes something I didn’t mention in my initial post there is the exact issue you noticed. The dimensions are not changing with skew, only the coordinates are!

I was adjusting skew from -0.05 to 0.05 (radians) which should have produced a dramatic change in dimensions

I need to confirm there’s not an error on my part, but this appears to me that the command does not work as we expect it to. I remember @EdStreet was saying he repeated this many times and saw no improvement, and I have printed several skew calibrations back to back with different skews and did not see the change I was expecting.

This was a 3x3 grid of perfectly aligned cubes (different print) and this was a “by object” print. At each object change I increased the total skew by 0.15 deg. One of them detached from my plate as it was cooling. I have measured all of these with calipers and they are all without a doubt the same dimensions. I haven’t calculated the dimensions to expect from an overall 1.5 deg change in skew, but I know it’s large enough to measure

Pardon the terrible image, but I will have to take a better one after testing this again.

[Thermal_Runaway]

I overlayed a grid in photoshop to show how much difference there was in the coordinates, but sadly all of these popped off of the plate after this photo was taken so I will have to print it again to get a better photo.

I do still need to rule out that this is not a side effect of changing skew between objects in a print, so I don’t have a definitive conclusion on this yet.

tldr is Bambu appears to be skewing the coordinate system, not the geometry.

[klomar]

If you printed a large square covering the area that all the small squares occupy then you would expect the top right corner of that square to be in different positions with different skew angles. So shouldn’t the top right corner of the top right small square be in different positions with different skew angles? This applies to all the other small squares too. You varied the skew for each square so we shouldn’t expect them to line up with each other.