btw the script I shared above will save your xy_comp_ang data to /tmp/x1plus_data.log
It’s the same data from syslog without sifting through 20k lines of spam.
1 Like
for my big listing above i did grep M1005 /tmp/syslog.
There is another way of doing this. I can visualize being in one of my old college courses (physics or math) and being shown how to geometry, trigonometry by another method. I want to say polar coordinates, vectors, triangulation keeps rattling around in my old head.
One of the conditionals was that you had to start at (0,0), and one side always had to be on an axis (x, or y). It was a far quicker method for doing certain things.
What reminded me of this was when I experimented in Fusion that if you build a parallelogram with opposite sides constrained as being equal and parallel with on side fixed to the x or y axis, and just enter the length diagonals it will construct it properly, and you can just measure the angles and sides. But once you take the constraint of one of the sides off the x or y axis, it doesn’t work anymore.
1 Like
It’s clear Bambu’s skew calculation method has a fairly significant amount of error compared to the calculations in @klomar 's worksheet, but if we really want to know the best solution will be to email them.
Since it’s an experimental feature that alters toolhead positioning, I think it’s important to scrutinize, but the important thing is we get info about whether there are any potential issues with saving a skew value before running prints. This disclaimer from Klipper’s docs caught my eye:
Due to the nature of skew correction it is recommended to configure skew in your start gcode, after homing and any kind of movement that travels near the edge of the print area such as a purge or nozzle wipe. You may use use the
SET_SKEWorSKEW_PROFILEgcodes to accomplish this. It is also recommended to issue aSET_SKEW CLEAR=1in your end gcode.
Keep in mind that it is possible for
[skew_correction]to generate a correction that moves the tool beyond the printer’s boundaries on the X and/or Y axes. It is recommended to arrange parts away from the edges when using[skew_correction].
1 Like
Copilot:
Copilots and Nebur’s results differ by a factor of 10.
That’s a diff of 0.0005 radians which would be 0.05mm over a 100mm print. We could measure that.
1 Like
After it’s all said and done, I hope one or more of you will memorialize it in a wiki entry. I read somewhere that BBL was looking to make an award for a top contribution of original content. It would be no contest: I think you’d win hands down. 
2 Likes
we can see what value is saved by the printer so there’s no need for this. M1005 I replaces whatever skew value is set. Running the same M1005 X Y command twice gives you the same value so nothing is “accumulating”
Also it’s much simpler to estimate the value not being measured here. if you think of the square, you can estimate the side length from the length of the diagonals like so:
AB = CD = nominal diameter
AD = AB*cos(Math.radians(45))
skew (deg) = 45-Math.degrees(asin(AD/max(AB,CD)))
This can be used to compare the estimated length of AD vs. the measured length too
Here’s what Bambu Lab say in the their instructions for using the M1005 X Y command:
‘delete the added gcode from the start Gcode before sending the new print task. Otherwise, it will compensate a little each time, and it will be more and more biased’
oh, that’s what “accumulating” refers to. If you enter X and Y values that produce a skew that’s less than the current skew applied, nothing changes. If you enter values with a skew that’s greater than the current one, it does modify the current value. That’s what I noticed from trial and error. So there’s only a change if it thinks the skew is becoming larger.
I’d like to hear more from bambu about it
Well, it’s in the same order of magnitude as Bambu’s response. Is Bambu deranged too?
wanted to give copilot a try, been testing it out for various things. there are 3 settings, more creative, balanced, more precise. The above I used balanced, while the more precise told me i need the measurement of a side to calculate things. I am able to get the ‘more precise’ to give the correct answer but have to do about 4 replies to get that.
I use it mostly for formatting and spellchecking code but unless copilot has been upgraded, you’re better off with an OpenAI api key and using librechat. And gpt4.
If IDE integration is important to you then consider copilot, but I use VSCode for every language. I’m considering using Qt Creator so I can use the qml live coding thing but otherwise VS has everything I need
I’m starting to think that Bambu isn’t using a correct formula. I revisited how to derive the angle just by knowing the diagonals just by trig and algebra. I don’t get the same values as Bambu. Same as other people get, but not Bambu.
Here is my work:
P.S. I did confirm my algebra via Mathway | Algebra Problem Solver
and b=a because we print a square
edit:
I used the formulas from Parallelogram. Formulas and Properties of a Parallelogram
I just noticed that it might be hard to ready my handwriting so here is the final formula
1 Like
I figured out what calculation they’re using. Need to plot my data and then I’ll share. It’s simpler than we thought.
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
It does produce the expected 2.5e-4
And I was wrong about you being out by an order of magnitude 
, (no need to call Sam).
There was a current XY_comp_ang of -0.00225 already set before the M1005 X119.63 Y119.66 command in @EdStreet 's syslog extract, which resulted in a new XY_comp_ang of -0.00200 (instead of 0.00025):
I figured it was simpler. Speaking of simpler. The excel formula looked funky so I took a closer look at it. It can be simplified to the following.
=90-DEGREES(ACOS((1-(B2/B3)^2)/(1+(B2/B3)^2)))
Where B2 and B3 are the diagonal numbers.
2 Likes
Saying I need to rerun those with I0 between each set?
No, just before the first one, as @Nebur suggested.
So the current XY_comp_ang = 0.00000 before M1005 Xn Yn is called.
I just kept iterating it because I wanted to check what @Thermal_Runaway said here about ‘accumulating’.
I installed x1plus. Lots of great features 
There was a problem with the installation.
I found this: https://github.com/X1Plus/X1Plus/issues/226
It’s a new issue raised yesterday. I downloaded Bambu’s firmware v1.07.03.00 and copied it to SD, which allowed me to complete the x1plus installation.
1 Like
I did a little test and it was pretty informative.
published M1005 X Y with one value fixed and the other incremented from 119 to 121. I got one data set without publishing M1005 I0 in between each data point and another data set where I cleared skew with M1005 I0 in between.
I was able to figure out the equation they use to calculate skew. but not what the iterative component of the calculation is. whatever correction they’re applying when a skew factor is applied on top of another skew factor makes this nonlinear. So I don’t have it worked out how the correction calculation works.
I included the code I used for each test in notes in the excel file. If you want the full scripts I’m happy to share.
1 Like