@jason.t That’s a great summary of where we are with skew compensation and the factors involved. I agree that the M1005 [In] method is best. I think Bambu’s M1005 [Xn] [Yn] method makes some assumptions about the length AD (which is reasonable for convenience in so far as a small inaccuracy in AD doesn’t have a very significant influence on the accuracy of the compensation factor) but the iterative nature of M1005 [Xn] [Yn] is problematic in practice. M1005 [In] also has the advantage that it can be left in the Machine start G-code (because it’s not iterative) so the compensation factor will be applied after the printer is power cycled. This is a practical solution until Bambu Lab fix things (hopefully in the next firmware version).
@jason.t Your test prints demonstrate that the printer’s Y-Axis is the reference. I’d assumed it was the X-Axis (as illustrated under Bed Skew Compensation in Marlin’s configuration file):
Your Calculator takes the lengths of the diagonals AC and BD and the width (AX on your diagram) as inputs. The method used in my Calculator (again derived from Marlin’s configuration file) takes the lengths of the diagonals AC and BD and the length of AD as inputs. Both interpretations (and maths) seem to give the same correction factor to apply but your interpretation from your test prints is the correct one which is a very useful insight.
@klomar I agree, I really haven’t done anything new - the end result we both get from our respective calculations is identical. (I wouldn’t have just naturally guessed that with the different representations - in fact, I didnt completely trust my math until I verified it against a parametric sketch, in a CAD file, to test variables and see that I got the same numbers my spreadsheet gave.)
Thanks for sharing all the information you have and your original work on this. That’s what gave me the initial understanding to dig a little deeper and do some physical testing to confirm the output/effect (I share the opinion that it might be useful information in some future troubleshooting/conversations).
I wasn’t aware of the M1005 In implementation; thanks for sharing the info.
Besides not requiring an iterative process, are there any further advantages?
@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…
But I never dealt with skew compensation in firmware. My approach on other machines has always been to square all axis physically as with any other type of machine tool.
@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.
Not so sure. You would normally just implement a matrix transformation to rotate one axis accordingly - basic vector algebra. There shouldn’t be much of an ‘algorithm’ going on. Seems very strange to me.
Btw. wouldn’t it be fabulous if BL actually chimed in instead of playing …?
Edit: To be more clear - they seem to only transform (x,y) to (x,y’) instead of (x’,y’)
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 …?
There is no difference in using x or y as the reference regarding the end result. Just forget about the test print for a second - you just rotate one axis ‘back’ in to being physically orthogonal with the other:
In terms of the mechanics the X axis is of course much more prone to being flexed by the belts out of squarness, so it makes sense to take Y as a reference.
Yeahhh… still algorithm sounds mighty complicated when we are just talking about some multiplying and additions with sin and cos. My point is, that I don’t see 10 lines of code with ifs and elses and edge cases.
Edit: Or rather my point is, that I don’t see how they would do it ‘right’ for normal scew angles and defer to something ‘else’ (to not call it simply wrong) for exaggerated angles like in jason.t’s test prints.
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.
I guess I misunderstood you then. But obviously that’s what would need to happen, otherwise the skew correction would screw up the x axis scaling and others had success with it. Like I said… very strange.
Sorry for my bad handwriting :D. And no, I wasn’t trying to explain the math, just that scew correction is very fundamentally just rotating one or the other axis around the coordinate system origin to archive squareness.
I just threw ‘vector rotation’ into google and a nice short video showed up that explains it better than I could:
…?
My point is, that I don’t see 10 lines of code with ifs and elses and edge cases.
