Fundamental maths issue, it does not get progressively more accurate

[VooDisss]

It does not get better, it needs some math's to take history into account i think, look at this, i printed 13 calistar already, and my printer is still not calibrated... :

It swings and over-compensates from one side to another and cannot calibrate, it need some math's based on how PID controllers work

My calistar.py settings: height = 2 chamferSize = 0.4 thickness = 3.2 fullWidth = 145 numMeasPoints = 3 diagWidth = 25 pa = 0.6 fightElephantFoot = True

slicer middle layer of the print:

[VooDisss]

Keep in mind that I measure without removing the print from my PEI sheet, I just got it removed and it seems the measurements are way closer to nominal ones. Now i will try doing several prints with removing the print from the PEI sheet (after it cools down) and look if situation improves.

[VooDisss]

After removing from the bed, the print got smaller substantially, these are the measurements: I think that removing from the bed is fundamental, i will try printing with new settings now and get back to you

[dirtdigger]

Skew cannot be iteratively fixed. Each time you print, the commands produced assume that there is no skew correction already being applied. If you've already got skew correction applied when you print the part, you'll likely make it worse.

Think of it like this: if your actual skew is 3 degrees, you correct for it once and reprint. It's probably still not perfect, so let's say post-calibration the residual skew is 0.2 degrees. The commands generated will adjust for that skew, but from your printer's non-corrected state. But when you enter that into your printer.cfg and reprint, and you're back to a 2.8 degree skew. So you adjust for that, re-print, get a small skew again, etc.

It's possible I could add a user-fillable current skew adjustment entry and adjust from that, but I'll need to work out what that looks like. In the meantime, I'll add some notes to the spreadsheet to prevent folks from thinking that iterative skew correction is possible.

If you're trying to calibrate a coreXY printer, your A/B motors are interlinked and need to be treated differently; given the fact that your x is calibrated by y is not, that likely explains the jumpiness you're seeing. The advice I've seen elsewhere is to average the two errors before applying. I'll add that note and an option to the spreadsheet.

[dirtdigger]

After removing from the bed, the print got smaller substantially, these are the measurements: I think that removing from the bed is fundamental, i will try printing with new settings now and get back to you

That's probably due to material shrinkage. I never tried leaving the print on the bed while measuring.

[VooDisss]

Yes, it would be very good if you wrote instruction on the best methodology to use this tool. Some recomendations like calibrating extrusion multiplier first according to this tutorial. Once we get it to a good working and easy to use state, this would get way more popular i think...

[VooDisss]

@dirtdigger Could you implement incremental skew correction by any chance? It would help, because with the current logic one has to print without skew correction, and if the correction is not within norms - he cannot adjust that incrementally anymore, just the XY steps and has to print another calistar without skew correction, then apply the new correction, so he can test the skew correction only every second print... right?

[VooDisss]

Just printed on calistar without skew correction (just applied the XY steps calibration), then got the skew value and printed another one with the skew and XY calibration settings and bullseye! it was right on spot regarding the skew value! Just gotta have that value not change and adjust XY steppers one more time

[dirtdigger]

Nice! FYI, I added a coreXY switch to the latest spreadsheet, I recommend updating to it if you haven't already and are using coreXY as opposed to cartesian (it simply averages out the corrections).

I've got a plan to add iterative skew correction capability, expect that coming up.

[VooDisss]

I figured that my ender 3 pro and other bed slingers have fundamental engineering trade-off sacrificing accuracy for budget... The belt carrier is of a poor design, also I noted from other klipper users that one should measure the X carriage movement only manually using calipers and not by measuring a print.

Assuming the esteps are calculated and X carriage components are of good quality (steppers/belt sprocket/X carriage) then one should apply only XY expansion coefficients to his print. Otherwise the accuracy on this ender 3 of mine largely depends where the printhead is (in the middle is the most accurate place, while on the left the Z height is most consistent due to no dual Z axis mod (yet).

This is said to be the proper way to route bedslinger belt: I will have to try this trick. @dirtdigger I suggest you read some of these links to maybe come up with another methodology to calibrate the printer, which would include measuring the X carriage physically for cheap ender 3 (or some other bedslinger with this flaw, there are tons of them) bedslingers. Just need a printable, to mount calipers on X extrusion and measure travel, only then continue adjustments... The links: https://klipper.discourse.group/t/correct-dimensional-accuracy/6093/9 https://klipper.discourse.group/t/correct-dimensional-accuracy/6093/10 https://klipper.discourse.group/t/correct-dimensional-accuracy/6093/7

This explains why my outer measurements were accurate, while the more i measure places on the calistar in the middle - the less accurate it gets - it's cause the X carriage movement is non-linear (maybe Y axis too, i dont know yet)

[VooDisss]

I suggest going at the extreme and on bedslinger measuring in 10mm increments the X carriage movement and comparing the real vs virtual values (virtual 10mm, real might be more or less) and write it into excel, and here comes the spreadsheet - you could include this into the spreadsheet for establishing a good baseline on what approach should be used before and during calibration using calistar Quote from here "After all, the error might not be because of weird Al-extrusion imperfections or POM-wheel eccentricities or whatnot, but it could be because your belt or your belt gear is slightly too thick or thin, and thus cause a systematic error, and this should be compensated for exactly in the steps configuration.

But yes, you should first figure out if your error is indeed systematic, by measuring at multiple points. If you get that X 0-20 is off one way and X 20-40 is off the other way, or if Y 0-150 is off by one value at one point, but later it’s off by a completely different value, then the error is indeed in something more or less unpredictable, so changing your steps config might not be helpful at all."

[dirtdigger]

I can add a note about your quotation to the README.md, but I'll be honest, I'm not really interested in adding scope to the spreadsheet. The intention is a companion calculator to the stl that is generated by calistar.py.

What you've found is valuable for Enders, but unfortunately I don't own one in order to do testing. I can't tailor the calculator for each possible variation of 3d printer. If a specific printer model needs special treatment, that's better suited to come from the subcommunity that forms around that model.

[dirtdigger]

Added notes to README.md (886a3b)