Pondering this and wanted to test a clarification from my last post
This sketch is the same scenario as before (as my last post) but with one added set of shapes and more dimensions shown for clarity/confirmation
Blue shapes = Everything nominal (inscribed square sides are equal length)
Green shapes = Representation of physical Print (inscribed sure sides are not equal, on skewed representation - same result as before angles not 90, sides not bisected evenly)
Red shapes = Diagonal dimensions from Green shape are put into inscribed square, on skewed representation, square is forced to have equal length sides and new width is updated as a result - 90 deg angles come back, sides are bisected but width of the octagon has changed)
I know my example is going backwards, to derive the octagon width from the diagonals, and that your method starts at the other end with direct measure of the octagon width - but its illustrating the same mismatch of the physical print (likely rectangular) and the nominal math when using other elements (the octagon, and related math counting on normal octagon shape) to solve for the squares width rather than the direct measurements of the squares width itself.
I think itās important that a method for skew correction should be user-friendly for users that donāt have a lot of experience using calipers. Measurement inaccuracy is perhaps more likely to cause errors than any differences in accuracy between using a square or an octagonal test print for the small levels of skew most users will experience. Iāve tried a lot of different test prints and from my experience so far @Thermal_Runaway 's octagon is the easiest and most consistent to use. Iād like to see his worksheet for calculating the skew factor from 3 diagonal measurements.
They can but it doesnāt mean they will. The wiki is where calculation details will be provided but the UI is going to be very much just āprint this shape, enter measurements, repeat until dimensional accuracy has improved. This is a feature that if used in the wrong way, the toolhead can attempt to self delete, so the default input method must be dumbed down because a subset of users will see āskew correctionā and mash buttons to enable it without reading any instructions. Our job isnāt to childlock every single feature but we do have some level of responsibility hereā¦the options are honestly forget the feature and let users do it themselves, or give users an interface for changing skew factor. Iām in favor of the latter. Anyone who doesnāt prefer the calculation method used can just input their own value?
Iām not saying Iāve decided on a model or method to use yet. I am going to base that decision off the results of testing. If anyone would like to contribute, I will use any and all data that compares my octagonal skew model with the square one. Please follow the scientific method and remember every time you cherry pick data, your social credit score takes a tumble (not directed at you Jason, just a warning to anyone reading.
As far as the calculation method goes, itās identical to the one you prefer, except one measurement is divided by 1.414. This is the Pythagorean theorem weāre talking about, and I really donāt see this as back calculating.
The skew calculation with the square makes assumptions too, one being the sides are all equal. This is never true in reality, so this method is also perceptible to the same error youāre describing.
I agree that there could be different things dome for ease of measurement, but this seems to come down to being able to measure over a whole number (octagon) vs measuring over a odd number with a decimal (square, if the diagonals are a whole number that is)ā¦ at the expense of doing the math in a way that ensures accuracy (again, not claiming that the base octagon math is wrong, just that thereās a difference in the physical world that needs to be accounted for). There are plenty of shapes that can be made, nested shapes, tiered shapes, stiffer shapes. etc. to improve the ability to measure accurately and comfortably
The math is the one thing that you can actually nail down and shouldnāt be disputable once youāve got it right. I donāt think any method should have a math error built in - even if its small and some are viewing it as insignificant - for the sake of easeā¦ I printed the shape I pictured in my first post (doubled, reinforced and larger version of bambuās test print) and nailed the diagonals within .01mm in just two prints using the straight forward calculation (the diagonals actually measure exactly the same, I just checked it again, but thatās the tolerance of the calipers). Why would I want to chase an unknown variable that I canāt control, thatās adding some random element to the process. It just takes more work and frustration and in the end you may not ultimately achieve the same accuracy because your chasing a moving target.
Listen, you have your own opinion and if you are taking this in a different direction - thatās up to you. But the truth is that there is a difference - and since I brought it up, the burden of proof was on me to demonstrate it. I think I have and I stand by it. Itās fine if thatās ultimately not going to be taken into consideration - my intention here in this thread was to clarify what physically is happening in relation to this command. Thatās important to put out front.
If you go back and look thatās not the case in my calculator, that was specifically shown in the screenshots showing the formulas.
I know you have a lot of people throwing a ton of ideas at you as soon as they know you are a Dev. thatās not the point of what I was trying to do myself. I spotted variable that I had a sense about and truly wanted to help. If you want to go back and review to consider thatās great, but I donāt want to lend to any of the argumentative aspect of the thread and probably donāt need to start repeating myself.
Using calipers properly would help; also, what helps is using the correct calipers, not all calipers are equal or good.
One thing that would be super super super good is a calibration build plate. It would have skew measurements, lengths and various other things that could be looked at and all it needs would be to scan the plate, run the numbers and you will immediately know what everything is, skew, extrusion length, bed skew to XY skew, etc.
I am not singling you out or trying to win an argument here.
And there is no burden of proof on anyone in this thread. I do not expect anything from you, but I assumed that since youāve printed and modeled a ton of these that you would continue doing so. My goal is to understand this better and if this results in me proving that your argument is the correct answer here then so be it. This feature is not for me anyway.
Side note though, Iāve printed 6 octagons now and at least 10 squares. I am having zero issue with the octagon measurements and I have not found itās any more or less accurate than the square. I am not going to share my data until I have compiled it all and done statistical analysis. I have a file full of raw data Iāll get to eventually
I have already promised to do a bunch of testing on this, but I am not around my printer until Wednesday.
If you have done a side by side comparison of my model with a square one and have statistics proving Iām being a stubborn ass, I will join your octagon hate campaign. I am pretty confident that there is no measurable benefit to using one of these geometries over the other.
Anyway what youāre saying is the issue is that the calculated value is a decimal? I can adjust the dimensions of my model to be proportional to sqrt(2) and that eliminates decimals here. I know this is not your point, but I donāt really understand how that poses an issue for micrometer measurements. It might be an issue when it comes to atomic force microscopy my x1 nozzle doesnāt probe at a high enough resolution for that to be the case.
I could see either codes on the bed itself being added for this or just a simple special build plate for calibration. optimal method would be included on the bed directly so no moving parts. known square and just calibrate to that.
Thatās not how I took it, but with the conversation going in so many directions itās hard to keep up and I see that.
My Idea was conceptual and needed someone else looking at it with a critical eye to spot what was going on. Iām ok with being wrong myself, but I like to know why and appreciate some detail to understand when thatās the case.
So hereās the kicker - I was wrong. I just spotted why and what lead me in that directionā¦
To contradict myself I, obviously canāt say I demonstrated this correctly in my past examples anymore but, I do stand by the idea of investigating this, and I had to share what I did in order to accomplish that.
I probably could have spotted the problem in my last post, but I was busy chasing a ghostā¦ It turns out that trying to draw the correct skewed representation of that Octagon has some pitfalls and the variance was from locking down the diagonals to be perpendicular to the 45ās of the octagon. Thatās only true in one conditionā¦ when the sides of the square are the same length (blue shapes). Once I started representing the square as a rectangle (green shapes) I shouldnāt have seen it as confirmation of a variance when I realized the perpendicular condition went away.
The overriding factor in this is that the X-position is the same no matter skewed or corrected (itās still physically going to travel along the crooked gantry the same distance without any scaling) - something I pointed out a couple times but lost track of here. It ends up not mattering if the skewed āsquareā is actually a ārectangleā - it just still doesnāt change its width, only the angle that the diagonals are in relation to the 45ās - and those donāt matter to any of the calculation.
In the end I see and agree that you can look at that squares width directly, as a ratio of the octagon width or using trig (which really still just results in a ratio) and the result should be the same with no mathematical variance regardless if the sides of the āsquareā equal length or notā¦
You arenāt seeing any problem in your prints because there isnāt one.
Sorry for the wandering path of getting here. Most of the time Iām also inclined to print a physical sample to confirm findings - but this was a weird one where The geometry seemed simple enough to sketch and test conditions in a CAD file and I pinned myself in a corner with it (its unfortunately not the first time)
@Nebur Perhaps itās no longer so relevant to the current direction of this thread but one result from the matrix transformation calculations is confusing me. See this diagram where I plot the results of the x yā transformations superimposed on each other:
Note point B (highlighted red) for the skewed plots. Why should that be less than Y100?
I used these equations: I think I applied them correctly:
xā = cos(alpha) * x - sin(alpha) * y
yā = sin(alpha) * x + cos(alpha) * y
By āscanā do you mean use the lidar, or did you have something else in mind? For sure, if the measurements could somehow be adequately done automatically without requiring tedious manual methods, that would be a huge benefit.
Glad to hear that we had the same goals in mind. I appreciate the attention to detail. You really had me second guessing whether I was overlooking something obvious, so I was a bit stumped myself trying to come up with a useful response. I am still planning on printing more octagons and squares in the next couple days, although your explanation does settle the matter. I always did this years ago back in school too where I had to finish an experiment or produce a physical result, so I can eliminate the possibility of confirmation bias, even if I already know the answer to the question Iām asking.
I do think it would be beneficial to adjust the dimensions of the model as per your suggestion, because I overlooked the fact that the current measurements are terrible for scaling the model in the slicer, and that could actually cause issues with accuracy. I think if I solve for the lengths of the measured segments backwards from the square side length I should be able to get all of the important segments as whole numbers
Hmm this could work but I think any calibration measurements taken from a build plate would probably be all over the place depending on the temp of the bed. Custom build plate markers are in the works now, so we may need an answer to this soon which is pretty cool
The achilles heel to 3d printers is the printer does not know where the head is at, it only knows where it thinks the head is at. If we impose a simple system to show the printer where it is at then we have introduced an entire new level of game play. Most all of the settings are derived from the home position be it bed mesh level or X/Y. A reality check if you will of physically showing the printer you are here in a multi-dimensional plane it can then auto correct itself in all dimensions and among those would include skew, length of travel, time of travel, quality of travel plus a slew of others.
Using several things like a bed marker, a wall marker, some type of head geo-position, lidar, camera, or even some type of sunset marker would work for this.
The lack of hard endstops on Bambu printers really limits what can be done (safely) in terms of controlling TH movements.
We could have custom markers across the surface of build plates but this creates a brand new set of issues that would just make the printer less reliableā¦ At that rate it would be a better and safer idea to build a new printer
Iām sure weāll find a good use for the toolhead cam still.
