@D3SOL4TE Hi. This might be a useful solution for users with P1 and A1 printers. Thanks.
Edit: GoSkew only supports skewing linear moves (G0 & G1). If your gcode contains arcs (G2 & G3), they will be left unskewed.
Nice work on this progress everyone! Hopefully we can see the R&D team @BambuLab hard work in the near future with this finally being addressed and solved in a manner of making the edit seamless for all users.
This is the power of the community
I received my X1C on July 25th. Out of the box using the tool below, the difference between the X&Y is .01mm. Is this satisfactory?
So far I am finding where the settings are in the slicer. As far as the machine is concerned, I am quite pleased. After using FlashForge, this is a huge upgrade.
My two cents ā¦
In a CoreXY system, the relative belt tension is the ONLY thing that sets and maintains X/Y squareness.
All other factors such as rigidity and sloppiness in bearings etc are in fact mechanical over-constraints, which will fight whatever the belts are dictating.
Thatās why one side of the mechanical X gantry SHOULD float in the Y direction, constrained mechanically only in X and Z. If not, then binding can occur when slight variations in belt linearity or bearing / rail variance come into conflict with the relative X/Y belt tensions, thus resulting in print defects ā in theory.
Bambu have this right. All other CoreXY printers I have seen do not ā in theory. The latter get away with it because the belts tend to be good enough, the linear bearings do have some slop and the gantries have enough flex, which all adds up to it being OK enough in practice.
IMO, having the belt tensions responsible for X/Y square rigidity is a major plus over trying with brute force mechanical rigidity, because it tends to keep things in alignment with otherwise light weight, relatively non-rigid mechanical components ā so long as the belts are of decent quality, that is.
The obvious downside is that belts can wear and stretch unevenly or in the worst case be low quality with non-linear tooth to length variance over their length, right from the factory. Idler wheel also need to very spot on concentric and highly circular. Many cheap Chinese idlers and drive pinions, sadly, are simply not.
I have read through this long thread from 1-466 it is very interesting. I would love to try skew compensation on my X1C, but frankly I am frightened to try it. I found a good guide early in the thread on the procedure, but nothing towards the end of the thread. The thread stops in July, and I read that Bambu may introduce their own solution. So should I just wait for Bambu?
2 Likes
After I printed the model, measured, and ran the numbers through the spreadsheet, I added this start code to the end of my normal printer preset in early June:
;==========Skew correction=============================
M1005 I-0.00042; correction factor
; to reset use
;M1005 I0
;to write to EEPROM use
;M500
Most of that is just reminders for me.
Printer has been working perfectly, but it was OK before the change. So, it has not changed my life, but my prints do seem to be a bit more accurate. And it is reversible.
2 Likes
Thanks, you made me feel a bit more relaxed about trying it. My interest in skew calibration started when I designed a gearwheel with axle. The gearwheel is 65mm OD and the axle 8mm OD. The dimensions when printed were not accurate. I had already calibrated the filament using Orcaslicer. I played with Orcaās precision settings, scaling factor etc. But failed to simultaneously get both dimensions accurate. Of course, I could get one correct, then adjust the other in Fusion 360. So anyway, I will try the skew compensation and see if that helps, or not. It is ironic that on my old Flsun was more accurate than my X1C. But Iām optimistic and will persist 
I assume that I will have to do several runs of the Skew Cal. Thank you for your post.
This has been an incredibly informative, if long read. I went through the trouble of making my own skew model and printing it out so it would be as big as my calipers could measure, but Iām already getting pretty consistent results, and AC/BD are only different by 0.05mm, giving me roughly I-0.00035 (an error of 0.02Ā°). Seems to me like thereās no point adding this to my start G-code since the range is within the margin of error for my calipers and expected variances with measuring, printing, etc. Am I correct in this assumption? Thatās only a 0.09mm error over the span of the entire print bed.
Regardless, useful to know for the future. I did manually tune my belts with spacers to get them to roughly equal tension at 70HzĀ±2.5 by checking their frequencies when plucked with a spectral analyzer, so that probably helps.
1 Like
Yes.
Reconsider if your needs or your prints change.
1 Like
Good to know. I was seeing people entering in skew values of 0.0004-something and wondering why they were even bothering, and was wondering if I was going crazy or something.
I am about to try this. Somewhere earlier in this thread someone said that they had to insert the skew correction at the very beginning of the āMachine start G-codeā to make it āstickā is it critical where the Skew code is inserted? also, is there a way to see that itās being implemented? Thanks
I put the correction at the end of my start g-code based on this post. My print results tell me that it worked.
I donāt think there is another way to check without using X1Plus and SSH to access the system logs. Iāve done that, but then Iām nearly out of my depth and it can take several attempts to find what Iām looking for.
Thanks, Iām probably being overly cautious. I was going to play with it this afternoon. But I forgot we were looking after our sonās 6 year old daughter. I ended printing various heart shaped objects for her. They printed nicely, but blew my own plans.
@lkraus Just a final āThank Youā. I used the calibration square in the link below. But increased its size by 150%, and reduced its thickness from 4.5mm thick to 3mm to speed up the printing time.
I then used the calibration spreadsheet here:-
Finally, inserted the G-code as per your instructions into the G-code start section inside the Nozzle section
;==========Skew correction=============================
M1005 I0.000668 ; correction factor
; to reset use
;M1005 I0
;to write to EEPROM use
M500
Got it pretty much correct the first time.
Before skew correction the skew was -0.038264 degrees and after correction -0.004781 degrees. When I measure the calibration square now, I can say itās pretty much perfect.
AC 119.847, BD 119.850, AD 84.651 mm
I post the info grouped together here, because it took a while to find the pieces
3 Likes
2 posts were merged into an existing topic: Welcome to Bambu Lab Forum - Read Me!
Got the same issue and designed and uploaded the tool. I resolved the problem in just few minutes
1 Like
i can seem to get this process to work at all ive followed the guide exactly and still my prints are 0.1 out of skew can anyone help???
I have some good news for P1-owners! I got the skew compensation to work on my P1S, firmware 01.06.01.00, by adding M1005 S1 before setting the skew with M1005 I[...] at the end of the start gcode. To me, this implies that skew compensation is disabled by default? Just to be sure, Iāve also added M1005 S0 at the top of the start gcode, although I donāt think itās needed unless Iām saving the settings with M500.
One thing to note: during testing, I was using 20Ā° of skew (M1005 I0.34907) to quickly see if skew compensation is working. With the above method, the print head ran into the glass door at the end of the purge line, so be careful when using large skew values! No issues so far for me (-0.17Ā°, i.e. M1005 I-0.002967).
Lastly, I was using the Califlower Mk2 with the accompanying spread sheet for calibration, which reported -0.17Ā° of skew. Setting -skew in radians as a correction, i.e. M1005 I0.002967, and retesting showed an increased skew of -0.30Ā°, while using the skew directly in radians, i.e. M1005 I-0.002967, gives me close to 0 skew. Not sure if I misunderstood something, or how interesting this is to others; this is mainly for me to remember the procedure for next time 
If I find the time, I may retest with the calibration square and the XY Skew calculator linked above and compare.
2 Likes
I see that your solution makes use of the M1005 X[nnn] Y[nnn] command and then M500 saves the values.
Earlier in this X1 topic it was found that using the X Y form of the M1005 command makes a change relative to the previously saved value, so the compensation will be changed every time the command is run. Placed in the Start gcode, the compensation will increase with every print.
Using the M1005 I[nnn] form of the command (where [nnn] here is the correction in radians) makes an absolute change, one not modified further by repeating the command.
Your A1 may handle the M1005 command differently than my X1C, but further testing might be advisable.
1 Like
Effectively as i wrote in the modelās page I am not sure that the M500 command would store the value indefinately (it could be ignored after an off/on of the printer) and , moreover, it was my intention to say to modify the start GCODE just for the tests than eliminate the code once obtained the perfect zero skew but i forgot to specify!!! (a poor mindā¦a rotten brain lol)
So i thank you enormously and i will add this to the page.
But it still remains the problem to know if the on/off will maintain the skew or not ā¦
(ps: The ones you see in the pics says A1mini anyway i did the procedures on my x1c )