@JayZay With one set of accurate measurements it gives you the angular skew in your printer’s geometry (in radians which you could convert to degrees by multplying by 180/pi).
You can use that angle to calculate how inaccurate your print will be over any distance on your print bed and whether it is practical to try to correct it. If that inaccuracy is a small fraction of a millimeter over the width of your print bed then trying to correct it is probably testing the repeatable accuracy of your printer and your ability to accuately measure on the uneven surfaces of the test print.
You simply apply the -ve of the angular skew as the correction factor with M1005 [In]. Until Bambu Lab fix their firmware (so that M500 saves the correction factor) you can leave your M1005 [In] command in the Machine start G-code so that the correction factor is applied again after the printer is power cycled.
The disadvantage of M1005 [In] is that you need trigonometry to calculate the skew angle but the spreadsheets that @jason.t and I have posted online will do that for you.
Also, FYI, it appears that Bambu is converting everything to M1005:current XY_comp_ang and saving that. So honestly its more about what is practical to list it and be user friendly.
Many thanks for the clarification.
I am comfortable with math, and since I have the iterative process implemented in Python, it was easier to add your equations. I used @jason.t (TY) for comparison and helpful notes.
Is there a reason for the y-axis being the reference? Any workaround? Isn’t this a limitation? I.e., improving skewness may affect accuracy.
I think the reason that the Y-axis is the reference might be because it’s the more rigid axis with the guide rods attached to the frame and the X-axis carbon rods ride on the Y-axis rather than vice-versa. I don’t see it being a limitation or that correcting skew may degrade accuracy. I started trying to find ways to correct the skew in the geometry of my printer because it created significant inaccuracy in my prints.
When I found the Reddit thread, I tested it. Luckily, I didn’t need correction, but to ensure it worked, I followed the M1005 X Y methodology (didnt know the I0 at the time). After three iterations, the difference between AC and BD diagonal lengths was within 0.01 to 0.02mm. The improvement over the iterative process was noticeable, and I conclude it works well.
I understand that measurements are prone to errors at this scale. I consider the average values from each iteration and average the diagonal length of 10 measurements (8 with a cheap digital calliper and 2 with a precise mechanical Mitutoyo).
The only issue relates to the changes in the most accurate value (x-axis) instead of y-axis. After reading @jason.t notes, I realized it makes sense.
Let’s consider an example that happens in a most prone case, e.g.
first test results: AC = 120.01mm BD = 119. 89 mm;
Independent of the skewed corrections method, this correction will move the AC value towards the BD, with a decrease in accuracy. Or did I misunderstand the process?
@JayZay With your example a perfect skew correction would give AC = BD = 119.95. Why is that a decrease in accuracy? Assuming the test print was designed with 120mm diagonals, doesn’t the test result just imply you have to correct for shrinkage as well as skew?
When you change the skew in a parallelogram the lengths of both diagonals will change with one increasing and the other decreasing (and the lengths of the sides will not change).
The only issue relates to the changes in the most accurate value (x-axis) instead of y-axis. After reading @jason.t notes, I realized it makes sense.
I’m not sure what you mean. @jason.t test results show that the y-axis is the reference axis, the axis who’s orientation won’t change as skew compensation is applied. I don’t think it says anything about accuracy.
EDIT: Looking again at @jason.t photos of the skewed prints I think what I said above is wrong…
@Nebur Yes, that’s what I saw in @jason.t photos that made me realize that my reply to @JayZay was wrong.
But I still think that correcting the skew will not create inaccuracy.
I think it’s significant that to create the skewed prints in @jason.t photo he’s giving false information to the skew correction algorithm. The false information is that the printer’s geometry is extremely skewed, when it’s not.
When a printer with skewed geometry tries to print a square with 100mm sides it will print a parallelogram with 100mm sides (AB=BC=CD=DA=100). I don’t know exactly how Bambu’s correction algorithm works but here’s what it needs to do to correct the skew:
Referring to @jason.t diagram it should print line AB along the y-axis for 100mm. As it prints line BC along the (skewed) x-axis it should be retracting the y-axis so that BC will be printed perpendicular to AB and it also needs to print line BC for more than 100mm along the (skewed) x-axis so that the (now perpendicular) line BC will end up 100mm long. The same process for lines CD and DA: print CD for 100mm along the y-axis then print DA perpendicular to CD by advancing the y-axis as it’s printing CD along the (skewed) x-axis, again for more than 100mm so that DA ends up 100mm long.
So, skew correction should not result in inaccuracy. From a parallelogram with 100mm sides we should end up with a square with 100mm sides.
But when false information is given to the algorithm (ie that it’s skewed when it’s not), without detailing all the steps again, I think it will print parallelograms where the lengths of the sides are not all equal to 100mm, as in @jason.t photo where BC and DA are longer than AB and CD.
algorithm: a procedure used for solving a problem or performing a computation
You may well be right about them using a matrix transformation. I was just describing how the axes need to move to correct the skew. I need to revise some basic vector algebra to understand how a matrix transformation works
Btw. wouldn’t it be fabulous if BL actually chimed in instead of playing …?
I wasn’t meaning to imply that it would do something else for ‘exaggerated’ skew angles than it would do for ‘normal’ skew angles. I assume that it would follow the same process.
Can you show the formula(s) it would use for a matrix transformation? You might already have done so in the photo you attached but I can’t make out some of the characters or numbers you’ve written.
Skew correction should change accuracy but it should make it better. If you have some compensation for accuracy then do skew it could easily throw off that compensation and that should be revisited after you do skew. Even from that 5mm is 5mm regardless if it is skewed or not. The measuring before could have been measuring both ends to get the length which is less than it should be, post skewed it will be a different value.
Here is my example of how skew will affect accuracy. If you are expecting 5mm and you have a skew you will not be measuring 5mm but in this case 4.9029mm.
If you have a scale factor you set to compensate and made that 4.9029mm become 5mm and then set the skew your compensation factor will be WRONG.
@klomar and @Nebur, many thanks for all the details.
I am in the same boat; e.g. I still own an S1 Pro, and it took me over 12 hours to square the cheap aluminium profile frame. Despite not being perfect, Klipper made its magic and never needed skewness correction.
I use the 3D printer for functional prints, and the X1C has been great; yet, I opt to slow down printing (at least the outer wall) and calibrate the filament with accuracy and tolerance in mind, many times to the detriment of aesthetics.
So, when I found out about the BL option for skewness correction, I tried it. The measured deviation was slight, so I cannot confirm my observation. However, after reading this thread, I questioned if my experience was a consequence of using the y-axis as a reference and if the I0 method could somehow improve results.
Printing speed and acceleration (outer and inner wall 60/160 mm/s and 5000/2500 mm/s^2) - others also lower than regular profiles but not significantly.
Nomenclature: RL and LR are right to left and left to right axis, i.e. RL=AC and LR=BD.
I only noticed changes in the AC diagonal, which deviated from the expected value; I thought the accuracy dropped.
Again, many thanks for all the details. Many make sense, but I prefer to reread and rewatch before commenting.
Interesting ideas, I don’t know what to make of some of this, but after thinking on it for a while I believe you have to step back and view the machine and its kinematics as it relates to the “skew”.
Technically, manipulating a trapezoid wouldn’t change the lengths of its sides but I dont think thats whats really being corrected - the machine control isn’t correcting skew for the geometric shape, its just correcting the skew of that one axis. The compensation for X being Skewed is applied solely via the machines Y-Axis and that’s why the width (in the X-Axis direction) stays constant. There’s no axis scaling or coordinate rotation going on, just the internal math that turns that angle into a compensation - as the machine travels in X a small steady comp move in Y is applied, like a ratio (eg: for every 100mm of X travel the machine also travels +/-1mm in Y. With skew compensation the machine would make a diagonal XY move although you’ve programmed an X only move).
To me this makes sense, particularly if you look at how the machine is built. Consider the image below. This is extreme, but its how our printers are physically built. That X gantry is crooked to the Y rails in all these machines to varying degrees (an I’ve come to realize slightly sloppy, its fixed semi-rigid to the left rail and floats on the right, the orientation only comes from one side and isn’t super rigid or precise - this allows it rock more than it should, I have some loose thought’s about this and how it relates to other issues as well - its somethin I’m still looking into and need more time with).
My opinion is that the Skew comp is doing exactly what it needs to do because its relative to what’s physically off on the machine (That’s why my calculator is set up the way it is - In my mind I’m looking at that bottom A-X-D triangle as the most relevant piece of info - its got the angle the gantry is off, and shows a linear value of how much comp the machine applies over the shapes width [Leg X-D]). Skew comp may have its limitations - but I think what would really be needed would be for Bambu to also give us some kind of independant X & Y axis scaling to balance them out (after the gantry skew is comped for). For what its worth I don’t necessarily think it should be all rolled into one.
If it only applies compensation via the y-axis then the print will be orthogonal, but the width along the x-axis will be short. It needs to move further along the x-axis to be the correct width because that axis is skewed. A movement of 100mm along a skewed x-axis will not give you a print that is 100mm wide. It may be doing what you describe but it’s not really ‘exactly what it needs to do’.
I see that in your data, but it’s across a very small range because your printer isn’t very skewed. I understand you measured very carefully but did you do more than one set of test prints? Did only AC change in another set? If you look at the photo where @jason.t changes the skew compensation with M1005 [In] you can see that both diagonals change.
Using the info from this thread I created a skew calibration procedure that will eventually be a feature in X1Plus. So thanks everyone
I have some changes I can share now. First, I find an octagon to be far superior to a square. It’s not only easier to measure, but this allows you to use 3 measurements of “diameter” instead of 2 diagonals and 1 side of a square. The only modification to the calculation method is that one of the 3 octagon measurements must be divided by sqrt(2).
For x1plus users, I have a script that automates calculation and entry of values.
For everyone else, I’ll have a worksheet up soon for you. You can check whether your printer has a skew value saved by publishing M1005 without arguments via MQTT.
As someone else here pointed out, M1005 X Y is very prone to overshoot so I recommend everyone uses M1005 I
…?
