Yeah - basically what I was trying to say in a more general way. The whole octagon idea works only for the M1005 X[n] Y[n] variant of the command unless you scrap the marlin formula and do your own trigonometry…
1 Like
Maybe this will help…
ABCD octagon measuring: M1005 I[n] calculations.
XY octagon measuring: M1005 X[n] Y[n] iterative.
But if I’m wrong… I’m wrong.
Yep, I’m wrong. I had to look at it from a distance and go to extremes to see that it won’t work.
1 Like
Nooooope! 
Assuming no skew AD would be fine but AC and BD would be ‘short’ for a lack of better words.
Just compare the octagon side by side with the corresponding vertices of the original instructions:
Y
^ B-------C
| / /
| / /
| A-------D
+-------------->X
Yep - that works.
Maybe this will help…
No, you don’t have the surfaces on your octagon to measure AD
AD on this octagon would be 70.71
I admit it. I was wrong! Took me just a few seconds in CAD to do a quick sketch to see the issue.
I forgot one of the fundamentals of engineering. ALWAYS check for extreme situations.
1 Like
I’ve been following this conversation and it seems like a good time to chime in and say that we might want to update our example of skew.
I did some exaggerated testing for myself to see the effects of the compensation and its worth noting that the machines Y-Axis is the reference component of whats straight on the machine - the compensation racks the top and bottom of the parallelogram like this…
Top is +20º comp, middle is none, bottom is -20º
(Using the M1005 I0 method, +/- 0.349066 Rad as the “I” value)
I made a calculator also, mainly to see if I understood the calculations and if they gave the same results when the parallelogram was represented skewing a different way (the way it physically does on the machine). In the process I realized that I like/trust the M1005 I0 method best. I believe that when you use the M1005 XY method you may not get a 100% predictable result because its using some kind of internal constant to represent the width that you also need to measure (in other words the two diagonal measurements aren’t enough information to do the math - a third dimension needs to be known, if you don’t give it one its using some nominal value that might not match what you physically printed).
I copied this over to a google doc to share if interested (it probably needs tweaks, I have notes in it for my own reference as I worked through it - also I was printing and measuring a 100mm shape I made to be stiffer than the Bambu Support provided shape - picture at bottom for an example. I made that shape 100mm and added the extra legs because I also measure across X&Y to use as my shrinkage factor in Orca Slicer)
5 Likes
@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).
Nice test print!
1 Like
@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):
Y
^ B-------C
| / /
| / /
| A-------D
+-------------->X
XY_SKEW_FACTOR
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.
1 Like
@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).
2 Likes
Hi,
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.
1 Like
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.
3 Likes
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.
1 Like
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.
Thanks @klomar.
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?
2 Likes
@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…
What confuses me is that the distance on x stays (seems to stay?) constant regardless of the skew value. I didn’t expect that.
Crappy illustration of what I mean:
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.
1 Like
@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.
1 Like
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’)