For the lazy:
X = length of diagonal 1 (measured)
Y = length of diagonal 2 (measured)
s = side length of square = cos(radians(45)*X
skew = radians(45 - degrees(asin(s/X))
s is calculated from X, not a measured value.
But shouldn’t the skew be calculated using the length of the longer diagonal in the denominator? I can’t tell if this is an error or not. In that case the value of s would be calculated from the longer diagonal too.
Side note: I put a trendline on the nonlinear data, and it really just appears to be some kind of quadratic correction. to be continued. I’m having a hard time understanding why there is a quadratic term at all. someone please make sense of this for me
Alright guys I’ve had this post on [watch] and consistently getting notifications. At this point what are we solving? Am I missing anything in terms of the equations being “skewed” 
Aerospace machinist here so I can help with trig and GD&T mathematics.
I just briefly skim the convos and see more and more math lol so trying to see what were solving or trying to accomplish thanks guys for the hard work!
We’ve been trying to determine what calculation is used when the command
M1005 X Y is published.
We already have a similar calculation method that uses 3 measurements instead of two to calculate skew in radians. And we apply this using M1005 I rather than the other form of the command.
Really the only point in figuring this out is to determine if Bambu’s calculation method was wrong. It is not wrong, but the correction factor makes it less correct. See the excel sheet above
The conclusion is still to avoid using M1005 X Y 
On a different note, has anyone adjusted their belt tension after doing skew compensation?
I ask because the skew changes considerably after belts are retensioned, meaning the calibration print may need to be reprinted to determine a new skew value every time belts tension is adjusted. I haven’t had a chance to test this any further so I’m not sure if this is completely true yet, but I’m hoping someone else can check too
Great explanation above and it’ll all boil down to what exact formula is being triggered to [action] when the Miscellaneous code is read. The devs are able to create that so it’s probably not in their interest to expose what exactly they have within their proprietary system.
Looking over everything I mean all calculations are correct in terms of the [degrees] - [radians] some of this is refreshing to me also since it’s mostly [minute/s of a degree] in aerospace.
Speaking on your belt tension scenario, I recently went and had to do so with our P1’s and then discovered this thread. So hard to say what the results were beforehand but I can say that the improvement was more vast than that of the X1’s. I still have [1] more X1C to do and can replicate the instance if needed.
I mainly just want to know if the skew value changes enough each time belts are retensioned that it’s necessary to recalibrate skew. I’m thinking it probably takes a few belt adjustments before there’s a need to recalibrate. I have a fresh skew calibration model printing right now and I’m going to adjust my belts and print it once more and compare measurements.
I’m working on a future feature for x1plus related to skew. If there’s a consistent maintenance cycle to keep parts accurate over time that will be useful info. Maintenance reminders about recalibrating skew would be quite nice I think.
hmm it still looks pretty linear to me. Rounding errors maybe?
@Thermal_Runaway Xn Yn is simply adding the new skew angle to the current XY_comp_ang:
EDIT: removed the data from the last entries in Test#1 and #2, which appear to be discontiguous.
rearranged columns for clarity.
as in this data where the same correction is repeatedly applied:
Yes, rounding or truncation
if you installed x1plus and want that same data from your printer, we got the skew logging PR approved yesterday. you can still get it from syslog but this is easier
- Download PR 218
- Overwrite script on the printer with this one. Reboot.
- Now every time you publish
M1005alone or with arguments, it reports current and new skew to /tmp/x1plus_data.log
May 1 05:23:46 info forward[1029]: [MCU][BMC]M1005:M1005 I0
May 1 05:23:46 info forward[1029]: [MCU][BMC]M1005:current XY_comp_ang = 0.00000
May 1 05:23:46 info forward[1029]: [MCU][BMC]M1005:new XY_comp_ang = 0.00000
May 1 05:24:18 info forward[1029]: [MCU][BMC]M1005:M1005 X119.63 Y119.66
May 1 05:24:18 info forward[1029]: [MCU][BMC]M1005:current XY_comp_ang = 0.00000
May 1 05:24:18 info forward[1029]: [MCU][BMC]M1005:new XY_comp_ang = 0.00025
May 1 05:24:32 info forward[1029]: [MCU][BMC]M1005:M1005 X119.63 Y119.66
May 1 05:24:32 info forward[1029]: [MCU][BMC]M1005:current XY_comp_ang = 0.00025
May 1 05:24:32 info forward[1029]: [MCU][BMC]M1005:new XY_comp_ang = 0.00050
May 1 05:24:47 info forward[1029]: [MCU][BMC]M1005:M1005 X119.63 Y119.66
May 1 05:24:47 info forward[1029]: [MCU][BMC]M1005:current XY_comp_ang = 0.00050
May 1 05:24:47 info forward[1029]: [MCU][BMC]M1005:new XY_comp_ang = 0.00075
Ok, now try this series:
M1005 I0
M1005 I0.0.00025
M1005 I0.0.00025
M1005 I0.0.00025
M1005 I0.0.00025
M1005 I0
Should reply and say your writing style is that of a doctor. 
also FYI I had many errors with the copilot results that I posted above.
I added three columns to your sheet. First two is to show the difference from the old value to the new value, first is bambu and second is calculated. the last column shows the ‘drift’ comparing the bambu and calculated.
Looks like it is close but there is a non-linear drift in the calculated formula. Oh I also put all data points to 5 decimal places to make it even steven.
Note how the last column it is close when it’s 0 and starts to drift when it’s on the ends?
It isn’t as nice as it used to be. I had a math teacher that forced us to work out one, really long problem, every week, in INK, on a BLANK piece of paper, with the rule of “all equal signs need to be vertical and lined up”, and “penmanship counts”.
(Sorry but I have a pet peeve about mixing units. ie. degrees-radians)
You got me!! That is what I was aiming for.
Oh crud… I just realized there might be something wrong. The formulas were derived with the one condition: X>Y. I have to think how this affects the issue at hand.
I don’t have a direct answer for you testing wise, and in the end this may be separate but related for your purposes but I made a reference above to what I think is the root cause of that change in skew when you change tension on the belts.
I gravitate towards confirming whats physical and I’ve done a little looking into the mechanics of the gantry as it relates to its alignment. There’s design compromises in this area, and it’s worth saying they are probably not unreasonable and likely for manufacturing at scale / ease of serviceability - but not great for repeatability (and most likely impact precision and also manifest other print quality issues). I’m currently scrutinizing it to see just how intensive I would have to get to make a worthy change in the precision and stability of this alignment (stability being what you’re noticing).
I hope to have more to share on the subject, but don’t have a ton of time at the moment and my thoughts are still evolving (also have commitments on things to print, so can’t exactly be tearing my machine apart). The bottom line for now though is that I believe your sense is good to be asking this question - this alignment is going to change by nature of how the printer is built.
I’ve got more thoughts, but a simple illustration is the picture above (from bambu’s gantry replacement vid) - if those Y rails are fixed (they are) and that width is constant (it should be), then how do you turn a rectangle (like the gantry is - its length x its width) diagonal inside of it?.. There’s known clearance built into that system in order to do so (yes Y rails probably flex a little in this particular example, but that’s not the full story).
If anyone else is curious to go looking into this - to expand a little on what I’ve said previously: The left Y-Axis rail seems to be the reference of alignment for the gantry. The reason is a difference in the steel end plates that are screwed on to the ends of X when the gantry is installed. The plate on the Left seems to make hard contact with the linear bearing on that rail whereas the plate on the Right has an extra spring plate inside to simply keep tension against the linear bearing on that side. It allows the right side to suck up the extra clearance but unfortunately accommodates movement, AKA skew (this is likely the primary reason you can influence the gantry as much as you can with belt tension - secondary reasons are that the bearing locates directly on a set of molded plastic ribs and that the end plates seem fairly weak/flexible in terms of how much clamping force they can maintain on that bearing to hold its alignment). The X gantry itself seems sufficiently rigid, its just being allowed to tip. (its a design choice, the assumption must be that the belts will do the real work of maintaining the alignment by virtue of them being equally tight and synchronized in movement)
@Nebur I believe you ment:
Ok. I need to setup an excel sheet and use these formulas and an array of input for X and Y and check the drift over a range of inputs. It should be linear but it seems that many of these are not yielding linear results.
