Not the graph. Am referring to changes in either X or Y when the other one is constant.
Ie. Y=2 and X = 1.0, 1.1, 1.2, 1.3, …. Then look at the change in the skew angle should yield a predictable result from the previous numbers.
Given a linear set of inputs the output should be predictable and also linear.
The drift I posted above is linear. From this we can deduce they are not using trig functions.
This image. Column G.
It’s new value - previous value.
The function Bambu is using to calculate I from M1005 X Y is linear in the range I was looking at. Which was a skew of up to 0.5 degrees. You can increase the range and it’s nonlinear, but I don’t see a purpose in that. It’s no longer skew compensation
Also in response to your comment earlier, I am not anti-math. I think you might be imagining that 
The M1005 I form of the command overwrites the previously saved value, so the result of running these two sequences is the same:
M1005 I0.00025\nM500\nM1005 I0.00025\nM500
==
M1005 I0.00025\nM500\nM1005 I0\nM1005 I0.00025\nM500
It’s only M1005 X Y that adds the previous skew onto the new one.
I’m getting confused on signs and which quadrant the angle ends up in. I need to take a break.
He isn’t saying arcsin is a linear function. We are treating the range we’re looking at as linear. There is no debate as to whether trig functions are nonlinear.
The
M1005 Iform of the command overwrites the previously saved value, so the result of running these two sequences is the same:
Humor me. I just would like someone to truly verify that M1005 In does overwrite the value in the log files.
Mainly because I was looking at older posted log files and something didn’t look right.
Even with log output, it’s difficult to interpret. That’s why I went with the brute force approach.
Here is the result of publishing M1005 I0.0025 15 times in a row.
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00025}}
{"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00025}}
And just for good measure, I checked this too. These are also back to back log entries:
M1005 I0.0025: {"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.0025}}
M1005 I0.0025: {"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.0025}}
M1005 X119.1 Y120: {"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00919}}
M1005 X119.1 Y120: {"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00919}}
M1005 I0.0025: {"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.0025}}
M1005 I0.0025: {"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.0025}}
M1005 X119.2 Y120: {"command": "M1005", "param": {"skew": "new", "XY_comp_ang": 0.00835}}
M1005 X119.2 Y120: {"command": "M1005", "param": {"skew": "current", "XY_comp_ang": 0.00835}}
Thank you, that is much appreciated. I just wanted to be sure that it was being overwritten. Otherwise, a lot of this would have been for mute.
Good info!
I will have more to share about this in the next couple of days. These are the steps I’m following, and I just need a bit more time to collect the data from this.
I will share an update when I’ve done this a couple more times. I am not too crazy about this setup because it will likely be biased by the retensioning process, but it’ll at least give some insight on the matter.
@EdStreet What is your calculation in column I?
@EdStreet I would just like to point out that although Bambu express the angles to 5 decimal digits in syslog, the internal representation of the variables the microcontroller uses will be floats or doubles, 32 or 64 bit numbers with 7 or 15 decimal digits of precision respectively and it will actually be accumulating the values of new XY_comp_ang with these higher levels of precision.
@Thermal_Runaway 's spreadsheet calculations will be accurate to ~ 15 decimal digits of precision.
Your column G (new value - previous value of Test#3 results) will only be accurate to 5 decimal digits (because that’s the level of precision syslog outputs). Your column H (new value - previous value of @Thermal_Runaway 's calculations) will be accurate to 15 decimal digits, (even if you show all data points to 5 decimal places in the spreadsheet). So using column I as evidence of nonlinearity is incorrect. It’s the result of comparing values with different levels of precision.
Ok, column I is Test#3 skew - Calculated skew.
I uploaded an updated version yesterday because this worksheet is already a bit difficult to interpret. In the current version, “Test #3” is moved to a different sheet. I collected that data just to have proof that the calculation is the same regardless of which diagonal measurement is being varied.
That’s a great point about digits. If I look into this any further, I think I’d want to know if I’m misinterpreting their method for correcting skew since I’m using at a fixed step size to examine their methods. I just don’t see how this doesn’t cause massive overshoot regardless of how the data is simulated
these are all true what you stated. I was looking at the rate of change and noted the calculated value was changing at a faster rate than the bambu listing was. In the end it does not matter what the calculated number is but instead what the printer is using. The goal was to figure out what formula they are using. While @Thermal_Runaway was close there is still a drift and I think it is closer to the current layout.
However, I also suspect that formula to will change over the next few firmware rollouts. Likely what will help motivate that change this … this thread.
P.S. those columns is current - previous, i.e. (D4 - D3).
This is why there is that label and waring “DO NOT TRY THIS AT HOME” on things 
There is a reason it is called experimental.
I kinda feel like they probably didn’t intend on releasing this as a feature yet, and I really doubt they expected a 330 post thread of users back calculating their formula haha
I always see that label as a challenge 