Skew compensation in the Bambu X1C Firmware

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

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

1 Like

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

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.

3 Likes

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

Pullley alignment

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

3 Likes

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.

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.

1 Like

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

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

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

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.

2 Likes

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

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

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

1 Like

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.

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”)

Definitely agree, this structure and how bambu engineered the layout is definitely new to the market. The fact of the skew comp being brought up over a year ago with no head way or further acknowledgement from BL isn’t the greatest feeling as a business that uses their products.

Honestly a feature within the slicer or firmware should’ve been added by now but were getting a lot of filler add ons I find redundant versus features that allow for fine tuning of the printer itself. I mean they even stated a solution and mentioned R&D working on it but idk… lots of other things seem to be on their priority list but I’d like to think that there’s a huge majority that are unaware of this whole thing like general consumers.

My newest X1C wasn’t terrible and it’ll be nice to compare a year from now to see if it shifts itself but compared to a year old X1C (not sure where it stood before though as a standard) was pretty bad by the values I had to adjust…

All in all I thought we get what we pay for but if its something you’re not looking for or are aware of then its simply not a problem :man_shrugging:

Maybe now that BBL is pushing for MakerWorld to succeed, perhaps skew and other aspects of accuracy will be of elevated importance? Only rarely are those printable objects accompanied by a CAD file that would allow you to adjust for differences, and so for tight tolerance prints it seems you’re at the mercy of both the designer’s printer and your printer being in pretty close agreement for your print to come out like the designer’s print. Right? One could make an argument that some kind of basic calibration standards should be met and adhered to. That would have seemed heavy handed back in the day when people were sharing out of pure generosity, but now that people are getting paid for their designs, it no longer seems so unreasonable. And on the consumer end of things, those standards would be there for your own protection, so that you don’t waste printing filament on something from makerworld that won’t fit together. The timing seems right for this to get more attention.

2 Likes

Also here because I missed the section of the correction not being saved on reboots…

So do we leave the value at the bottom of the [Start Gcode]? I’m only using the [M1005] [Ixxx] line versus the [y] method.

Another question is leaving the value there, does it add the comp to itself over and over generating a large skew value when starting prints over and over? If so does that call for adding the [M1005] [I0] to the [End Gcode] scripts?
Thanks in advance!

I printed your hexagonal test print. I really like it for consistent measurement. I added a 0.4mm chamfer on the base for elephant’s foot and a small indented chamfer on the ledge so the caliper jaws don’t rest in a corner.

image

2 Likes

Leave the M1005 [In] command in the start gcode to have it reapplied after a power cycle. You can put it at the start or end of the start gcode. It doesn’t add the comp to itself over and over like the [Xn] [Yn] method does.

1 Like

Thank you, great work on everything you’ve contributed to this along with everyone btw.

1 Like

Yes leave the M1005 line in the start print section … for now.

Second question, does it add to it. It could once it is fixed, we will have to keep an eye on the release info and find out when it is fixed.

Second part, until we know exactly how xy_comp is being calculated in it really does NOT matter if you use XY or I. What DOES matter is how the print functions at the end of the print.

1 Like