Skew compensation in the Bambu X1C Firmware

[Nebur]

Oh, I’m sorry! Evidently what I posted is nonsense!
The rotation transformation of course rotates the whole coordinate system and we only need to rotate the x-axis and offset y.

So the transformation matrix should be:

     / cos(a)   0\ -1
T = |             |
     \ sin(a)   1/

Okay, I give up on trying to type the inversion and multiplication in this editor. Borderline impossible. Will finish it on paper tonight and post the end result and possibly the derivation as a ‘paper screenshot’.

Nevertheless - those three test prints with identical width show that bambus skew correction is half-backed.

The ‘software skew correction’ needs to have the same end result as physically rotating the x-axis back to perpendicularity with the y-axis.

[ProtoSpyre]

Yes, this is big factor while using (Especially, those pictured - [Mitutoyo Absolute Digital] Calipers) / Many like to use the [Thumb Wheel] but that applies various pressure therefore you essentially get a range of values.

In a machine shop setting, keeping the most accurate I like to use the [Thicker] upper portion of the teeth since they’re not a fine point at the tip where you can’t achieve the most surface area on measuring parts - then I’ve only ever used my thumb on the [Slide] to move up against parts.

Great thread for this as I just finished calibrating my skew on [1] 13 month old X1C and a [1] week old X1C. New one is perfect and the older one had a [M1005 I-0.003755]… kinda wild but it completely solved my issue with (cali cubes) being off in Y but not in X…

Thanks to everyone that’s contributed on this project! Well done

[Thermal_Runaway]

And this just takes some experience. The thumb wheel mitutoyos are not perfect, but with enough “practice” you’ll learn how to be consistent with them pretty quickly. Gage blocks are useful for this.

Another big source of error is the alignment of the caliper jaws with the object. If the object is not almost perfectly perpendicular with the jaws then there’s considerable error in the measurements so you will end up with a correction factor too large.

I designed the octagonal model so it can be measured on a flat surface with calipers resting on top. You can get a near perfect square with your calipers this way, which should simplify measurements for some people

[Thermal_Runaway]

The highest skew value I’ve set is 0.01, and I actually forgot I’d done this until I started a print and saw that my calibration line were at a large slant.

I don’t think I’d go above 0.01. At a certain point it wouldn’t be too easy to measure

[Thermal_Runaway]

I’ll share more on this later.

It’s essentially the same general process I’m using for a skew calibration script in x1plus. You’d save your skew factor locally or directly in the workflow I guess. Then request the stored value via MQTT. If there’s no stored value, you publish
M1005 I{skew}\nM500\n
And repeat until M1005 returns a value. That’s the sparknotes version of the logic, anyway.

The easiest solution to this if you have an X1 is rooting, but I realize not everyone is able to or wants to do so.

[vladimir.minkov]

Great work , and as much as i like it and is great idea the software skew alignment, it has some draw backs over attacking the root cause, probably the biggest draw back in this case is related to VFA and fast printing with ringing , the second one is out of alignment rods and movement will cause extra wear and tear. and is not cheap to replace and extra time. Also it may cause extra tolerances in the print out after a while

here is a few ideas, note that was just quick skim not extensive research:
partial Alignment

Bambu Labs Banding Fix, Step-By-Step Tutorial!

Pullley alignment

P1P Belt/Pulley Alignment - VFA’s,Noises?

This topic has been discussed extensively and brought up numerous times at this point since becoming a known/regular instance. I wanted to shed my insight on the subject after inspecting a P1P suffering a constant HMS: [Abnormal Motor-A resistance] error alarm every start up and print job… for months now. Reading a lot about toothed pulley versus smoothed pulleys, doesn’t seem to be a permanent fix. I’ll side with BL on their comment based from a user stating they’ve found it t…

i am sure there is a lot more information online or as engineers you can find more methods to align the actual printer, I would not expect after spending 2000EUR to have a basic skew and alignment issues, fortunately my one actually is pretty good or with in acceptable range

In saying that keep it up as extra SW compensation is always good
Probably make sure that you can turn it off and on as changing parameters to 0 is not aways the easiest way

Again great work

[Thermal_Runaway]

Nice, I like nicknames too. I’m happy to help still, so if you are still having issues please share more info next time. device, version, etc. There are differences in MQTT data that’s published between models and versions, especially on the x1. hope you figure it out.

[EdStreet]

I have looked at that vid some time ago and even have the squares and etc to test it and see. I have yet to get that far.

I can say on the MQTT bits, home assistant on a pi does work and you can see many things on it but its several pitfalls and several layouts for it. raspberry pi installer will do home assistant also there is the website itself.

[Nebur]

@Nebur

The ‘software skew correction’ needs to have the same end result as physically rotating the x-axis back to perpendicularity with the y-axis.

Stuff below should transform any point on the skewed coordinate system to the regular orthogonal one as illustrated above. So, it’s what I would bambu lab expect to implement in the context of M1005.
Apparently only the y-coordinate is corrected right now, leading to the x-coordinate staying ‘short’.

Input variables:

• a: angle the x-axis is skewed physically on the machine (counterlockwise is positive, clockwise is negative!)
• x : programmed x-coordinate
• y : programmed y-coordinate

Output variables:

• x’ : x-coordinate the skewed x-axis needs to move to, to reach programmed x physically
• y’ : y-coordinate the y-axis needs to move to, to reach programmed y physically

Calculation to get the corrected / descewed coordinates:

• x’ = x / cos(a)
• y’ = -x * sin(a) / cos(a) + y

Derivation / math mambo jambo:

[Thermal_Runaway]

Marlin’s skew factor command allows you to define XY, XZ, and YZ skew separately.
I don’t have issues with z axis dimensions but it seems like the applications for z skew are not quite as useful

[Nebur]

Assuming you are referring to my post - there is no Z involved. This is all on the x/y-plane. Not sure if the character Z even appears anywhere in the text.
I guess just looking at the illustrations it might look 3D-ish.

[Thermal_Runaway]

My comment was in reference to your mention of Bambu modifying the command in the future, not your diagram. I see what you’re saying

Since they’ve followed the same format that Marlin’s command uses for XY correction, I would assume they would implement the full command to support XZ and YZ correction. I haven’t seen a skew compensation technique on other devices where there is more than one factor for the XY axis. the question is whether a separate factor for x and y axes would improve the current outcome or not

[EdStreet]

Can you do us a favor and show in printed objects how this becomes a problem?

[Nebur]

@Thermal_Runaway

My comment was in reference to your mention of Bambu modifying the command in the future

Ahhh, I see. But nope that was about x/y too…

@Thermal_Runaway

I haven’t seen a skew compensation technique on other devices where there is more than one factor for the XY axis

Not sure what you mean by ‘factor’. The transformation only needs the physical scew angle of the x axis. So one constant, not several.

@Thermal_Runaway

the question is whether a separate factor for x and y axes would improve the current outcome or not

Moving only x or y would be a shear transformation and mathematically wrong. For small angles the error is of course small. But why not do it correctly?

Exaggerated angles illustrate the error on x:

Edit:
To quantify things: For a scew of ~3° the error

• on x=100mm would be roughly ~0.14mm
• on x=250mm would be roughly ~0.34mm

[Nebur]

See image in my prev post.

[EdStreet]

that’s not what i was asking.

You said the error from the computation. that is what I was asking about. the margin of error does that show up in the print and list that ONLY.

What you posted was an exaggerated value which for the most part is meaningless for the goal here.

[Nebur]

@EdStreet

that’s not what i was asking.

Yeah, I imagined. Reason I added some examples for the error below the image.

Edit:
Basically you can just calculate the error yourself for any angle and x coordinate:

• x_error = - x_position - x_position / cos(skew_angle)

[Thermal_Runaway]

@Nebur

Ahhh, I see. But nope that was about x/y too…

No need to be flippant. I don’t think you need anything explained here.

@Nebur

Not sure what you mean by ‘factor’. The transformation only needs the physical scew angle of the x axis. So one constant, not several.

Please refer to skew correction on most FDM printers because I’m not talking about XY compensation. you are. Have a read Bed Skew Compensation | Marlin Firmware

@Nebur

Moving only x or y would be a shear transformation and mathematically wrong. For small angles the error is of course small. But why not do it correctly?

I am not suggesting that. If you can’t converse normally then we have nothing to discuss here. I don’t want to see the exaggerated angles of the square, I want to see the comparison of the error between the octagon and the square because everything so far has indicated that this difference is negligible

[Nebur]

Really? What was the problem now?
Let’s just agree to ignore each other. There is a button for that somewhere.
I have no desire to walk on egg shells with every response I write and I’m getting nothing from you anyway…

Edit: Also - attitude aside - your response makes 0.0 sense. You either don’t have the slightest idea what I’m talking about or what you are talking about. Zero compatibility…

[jason.t]

@Thermal_Runaway

Maybe we should apply large skew factors to our devices, print each model

Yes I agree. Like I did to confirm some of my findings you should test your method at extremes, anomalies will always be more visible that way.

@Thermal_Runaway

• all sides of an octagon are equal
• all internal angles of an octagon are equal

And of course these are not all true in reality, so the relation starts to fall apart. Is this your point?

In math yes, on a printer with a crooked Gantry no…

Correct, that gets to the nature of my point. This thread gets a little messy, but there are a couple observations I’ve been trying to express that are relevant (I’m sure these are things you may already be aware of)

• Regardless of what we might want/like M1005 skew comp to do - it doesnt do anything else than compensate for the physical angle the gantry sits at relative to the Y axis of the machine.
• The comp is only adjusting Y position relative to where the print head is in its X travel (there’s no axis scaling or coordinate rotation going on)
• This means that a square physically printed will most likely measure smaller in X than it will in Y (Becasue X travel is happening at an angle)

With that last point in mind, I’ve got another sketch to share that I think gets to the heart of what I’m trying to express about the difference in measuring method (measuring the “square” directly vs. measuring a Octagon and backfiguring the “square”). And the potential for error when the print isn’t at nominal dimensions.

Looking for a different way to visualize the error I started with a regular Octagon and the translated all the points up to a skewed version of shape as it would be physically printed, per the kinematics of the machine (all the X coordinates remain in the same place and only Y coordinates shift/move).

• In the example on the left I make the sides of the square equal length and everything works out. It retains the relationships you’d expect from an Octagon. Angles are 90 and diagonals of the square evenly bisect the sides of the octagon
• In the Example on the right I make the Y dimension of the skewed octagon (and thus the square too) slightly bigger and things get complicated. Angles stop being 90 and diagonals no longer evenly bisect the sides of the octagon.

Both skewed shapes are translated up from the normal shape the same way. The example on the right is just showing how things are more likely to be in the physical form.

I believe, how this relates to the method of doing the math, is that: Using the octagon to backfigure the square width doesn’t allow it to be anything other than a square. In physical form the measured diagonals are likely a going to be from a rectangle - so calculating the “squares” width and treating those diagonals like they came from a square (equal length sides) leads to an error.

Using the direct measurement of the square width for the math does allow for the possibility that the diagonal measurements were actually from a rectangle and still calculates accurately.

I understand the idea behind your efforts is ease of use and reducing error - but I really think that the foundation of the math should be bulletproof even if the difference in the error this makes is small, let the error come from the measurement rather than the math.

People can learn to use calipers correctly and measuring accurately with them isn’t hard once you spend some time and learn how, it’s just a skill that takes some practice and coaching (thumbwheels aren’t evil, and you learn to never put more pressure on those than you do up on the thumb rest - your thumb should be able to slide over both of them with a little drag when the caliper jaw stops). The people who use calipers are invested in getting an accurate print, and those who aren’t won’t bother in the first place, which is fine too.

EDIT: Sorry for deleted post below, was trying to redo with direct reply and then deleted wrong one (now can’t repost again to correct because its “too similar”)