Closed S3DCreations closed 6 years ago
so there is no need for a automated search for the paper method...
Agreed... And in fact, without a probe... The printer really can't do an automated search. The whole idea with taping a toothpick or needle to the nozzle was aimed at still letting the user be very precise because they could see exactly where the 'indicator' was pointing.
By the way... manually or automated... why we dont calculate correction facors for travel ways of X and Y at the same time within the squaring calculation?
This sounds great. Lets get the Manual Skew correction working first with paper and then once the guts of the code is done. then we can revisit automating it with a probe or optical or whatever
How about this? Print a number of lines in a "fan" way, and then entering which line that lines up best from the edges of a piece of paper? Measure while the pattern is on the bed. Maybe first print a fan with a higher "tilt" per line, measure and then print a new pattern with a smaller tilt until one is done? UBL can print patterns?
Maybe first print a fan with a higher "tilt" per line, measure and then print a new pattern with a smaller tilt until one is done? UBL can print patterns?
Yup! UBL can print patterns. This is very 'do-able'.
If one starts with 7 lines as above and have a 2˚ spread per line the first fan would cover ±6˚. Then the next pattern could cover ±2˚ (0.6666667˚ spread per line) etc. The middle line and pattern should be adjusted from the previous "round". Not sure how many times would be good, but until one can't tell them apart I guess.
For 1° spread per line on a 200mm x 200mm bed, you get: cos(89°)= .01745 and sin(89°)= .9998477
.01745 * 200m = .349mm We could print 'dashed' lines and stagger the dashes so they don't merge and interfere with each other.
though I think 0.01745 * 200mm is 3.49mm (thats a lot so maybe sufficient to start there with a ±1˚fan, 0.33333˚ spread per line)
Doing the line method seems like it would be more steps. Do you believe this would be more accurate then the paper/toothpick method?
@adamfilip Sure it might be more steps, but it is less "fiddly" I imagine. The pattern should print very quickly and be easy to remove. Maybe more "robust" as one narrow in on a satisfactory skew. Well, just my opinion.
Print the pattern, move a paper over the pattern, select best line, remove pattern, print a new pattern, repeat until satisfied.
though I think 0.01745 * 200mm is 3.49mm (thats a lot so maybe sufficient to start there ±1°?)
Ooooops! Off by one decimal place. That will kill you! I think we could start with ±1° lines.
Doing the line method seems like it would be more steps. Do you believe this would be more accurate then the paper/toothpick method?
I think the math works out the same. And all the support code to actually store and implement the results would be the same. I'm not opposed to doing it both ways and let the users choose what makes sense for them.
I think it is true the line method would be 'more steps'. But the thing about it is it would be a lot easier for the user to tell their printer to print the lines, and then just lay a sheet of paper on the lines to see which one is 'square' with the edges.
@epatel If you want to jump in, in the G26_Mesh_Validation.cpp file (in the devel_ubl branch) there is this function:
// print_line_from_here_to_there() takes two cartesian coordinates and draws a line from one
// to the other. But there are really three sets of coordinates involved. The first coordinate
// is the present location of the nozzle. We don't necessarily want to print from this location.
// We first need to move the nozzle to the start of line segment where we want to print. Once
// there, we can use the two coordinates supplied to draw the line.
//
// Note: Although we assume the first set of coordinates is the start of the line and the second
// set of coordinates is the end of the line, it does not always work out that way. This function
// optimizes the movement to minimize the travel distance before it can start printing. This saves
// a lot of time and eliminates a lot of nonsensical movement of the nozzle. However, it does
// cause a lot of very little short retracement of the nozzle when it draws the very first line
// segment of a 'circle'. The time this requires is very short and is easily saved by the other
// cases where the optimization comes into play.
void print_line_from_here_to_there( float sx, float sy, float sz, float ex, float ey, float ez ) {
You can just define an extra option to cause the printing of the skew lines and call this function to do the work! There is already support to handle different filament sizes, nozzle sizes, bed temperatures and nozzle temperatures!
Hey there,
I'm sorry but I have to say that the line-method seems to be not really user friendly to me. I just created a Calibration Sheet based on four points to print out. Just lay it on to the printbed (tape it down) and try to tip the points with the nozzle and note the x-y coordinates. Add these coordinates to the firmware an youre done... no double printing sheets... you dont have to care either about the rotaion of the calibration sheet nor an other position...
For the math: wtih theese points firmware could correct the X-Y-skew, and calibrate boths X and Y axis steps per unit to match exact lenght of the travel ways...
Have done an excel sheet for testing my calculations with an hand-ruler-drawed square and a rhombus and then remeassured and it just works fine... Will try the printed sheet also on my printer (and do the excel calculation and see how much my X-Y-skew is).
Attached an PDF for better illustration and the excel-file (sorry its not very clear how the excel sheet works, but wanted to make a quick test)
Just cleaned up the excel sheet for everyone... You can try it on your printer and do the calculation with Excel if you like...
Calibration_Sheet_clean_v2.xlsx Excel-sheet has been updated due to an calculation error!
Requiring any user to "eyeball" sub-mm accuracy without repeatable mechanical aids (such as precision measuring equipment, or use of math and physics, such as printed vernier scales) is doomed to be an also-ran to whatever everyone has already been doing, with okay, but marginal success.
For any cartesian style mechanics, the method of printing orthogonal prints with integrated vernier scales diagonally across the bed, then having the user enter the resulting value (measured visually using vernier method to mechanically increase resolution), as suggested by @epatel in #4904 seems a much better and repeatable method for determining XY axis skew, as it moves user judgement into the realm of noise compared to the measurement.
The axis to use as the origin access (the axis assumed to be correct, against which the other axes will be aligned to) will need to be considered for the various printer types. For moving-bed printers such as Prusa i3, I believe it would be the axis the bed is attached to. This method needs to be explored/vetted more for the different printer types but I think this method should resolve the XY skew problem.
Beyond that, I don't see how this same vernier scale comparison method couldn't also be extended to the Z axis but may be more problematic (and much more time consuming, since it would require a full-volume print rather than just 2 small linear prints on the bed).
The math to do all this already exists in the Prusa i3 MK2 branch (and in other contributor branches in various capacities) and is proven to work well. The challenge is to take the automated method used with the MK42 as the input and augment it with a manual method for use by all other printers that do not have a mechanism to detect absolute coordinates on the bed. Starting with the method suggested by @epatel, I think XY skew adjustment would not be too difficult.
Requiring any user to "eyeball" sub-mm accuracy without repeatable mechanical aids (such as precision measuring equipment, or use of math and physics, such as printed vernier scales) is doomed to be an also-ran to whatever everyone has already been doing, with okay, but marginal success.
Yes. But in the case of a 'low end' setup where there may not even be a probe. It maybe possible to do multiple iterations to get closer and closer. We might be able to do a first pass and get numbers to partially correct the skew. And then do a second pass to further refine the needed correction.
The math to do all this already exists in the Prusa i3 MK2 branch and is proven to work well. The challenge is to augment the automated method used with the MK42 as the input method, with a manual method for use by all other printers that do not have a mechanism to detect absolute coordinates on the bed.
AGREED!!!!
I didnt say its the perfect and accuratest way... not really. But its a starting point for the low cost segment to get better accuracy... even with eyeballing...
It only costs a sheet of paper, four values to type in Marlin and perhaps 10 minutes of time...
No need for a special Heatbed, no probes... for Printers matching the hardware there should clearly be an other way...
Yes. But in the case of a 'low end' setup where there may not even be a probe. It may be possible to do multiple iterations to get closer and closer. We might be able to do a first pass and get numbers to partially correct the skew. And then do a second pass to further refine the needed correction.
But any printer can, by definition, print, so any printer can use @epatel 's method of printing orthogonal calibration "sticks" (proposed and demonstrated in #4904) with vernier scales and comparing one length (calibration diagonal 2) against the reference ( calibration diagonal 1), with great precision.
If the goal others have with the paper method is to find the summation of the XY-skew + Y-bedEdge skew (in the case of the i3), I ask why bother ? The printer will be constrained by its own mechanics, so if a bed edge is not parallel to the origin access, why do we care ? Adjusting to make it parallel won't make the printer capable of printing into the farthest edge of the bed; it will still be constrained by the available movement on the other axes to compensate for the skew in printer consruction.
In short, wouldn't it be better to view the bed as an infinitely-large plane and the calibration process (whether via an inductive sensor, or manual method, as yet determined), along with the mechanical limits of the printer, dictate the printable area of the bed ?
After bed-leveling (by either manual method or automated method), the print head movement axis can be assumed to be parallel to the plane of the bed when at layer 1. Once that is known, printing @epatel 's calibration sticks, and determining the delta between the diagonals using the printed vernier scales on the sticks gives us the inputs to the XY-skew adjustment algorithm.
Or have I had too much coffee this afternoon ? I missing something ?
@fiveangle No, youre not missing anything... This afternoon I tried the paper method... finding the spots by eyeballing was not that difficult... I made this procedure tree times and calculated the offset angles with different rotations and slightly other positions on the heatbed... The calculated offset angles were nearly the same. Differences in the 2/10 degrees...
By all my merssurements of the machine to calibrate before this I wasnt even close to theese values. just fiddling around how to meassure one axis versus another with differend styles of rulers and so on... This turns the printer itself to the meassuring tool.
So, this is just why I think we should give this a try. Its very very easy compared to the values you get...
....Wish to type in my offset angle and try a print...
One should not be required to obtain an accurate 2D printer in order to calibrate their 3D printer ;)
By all my merssurements of the machine to calibrate before this I wasnt even close to theese values. just fiddling around how to meassure one axis versus another with differend styles of rulers and so on... This turns the printer itself to the meassuring tool.
@S3DCreations, I think I've figured out that you might be missing purpose of @epatel 's suggestion, in that it is using the vernier method to measure the distance, and very truly "turns the printer itself into the measuring device":
https://en.wikipedia.org/wiki/Vernier_scale
Go ahead and print out @epatel 's models and see for yourself if you get an accurate measurement of the skew: https://github.com/MarlinFirmware/Marlin/files/503908/skew-ruler.zip
I think the final model should probably print with a locking groove on one end that mates with the other calibration stick (to ensure they are aligned, without squish of the first layer affecting the start point) and the other having "teeth" that are just slight overhang wiggles in the 2nd or 3rd layer of the test print (and not entire beads printed on the second layer as in his first proof-of-concept design above)
One should not be required to obtain an accurate vernier caliper in order to calibrate their 3D printer
J/K :)
@fiveangle, I think it is safe to assume most consumer 2D printers are square. It is also safe to assume most 3D printers are not. :)
@S3DCreations, this printable calibration template thing is a great idea. Even without firmware compensation, I can already use this to see the problem in my hardware and fix it.
@Fulg Thanks a lot. Nice that it helped you already even without the firmware correction. :)
@fiveangle I know what a vernier scale is and how to use it ;) And just because of this I see a Problem... If I’m completely wrong, please correct me, but here are my thoughts:
A vernier scale works because there are two scales lined up together with a predefined difference in lengths. This difference is for example a factor of 9/10 (accuracy up to 0,1 of a unit), 19/20 (0,05) or 49/50 (0,02).
So the difference of the two scales has to be an exactly known factor. If we print two scales squared against each other, rotated by 45 degrees we get (if the printer is not squared) two different scales which to compare to each other... one with a 10/10 and one with 9/10. So far so good.
BUT: because of the skew the difference factor as above described is not known at all... we get something like (9+-x)/10 or (19+-x)/20 or (49+-x)/50 and so on... and this x is given by the difference in length we try to measure... So the problem is obvious: we try to measure a value with an venier scale that exactly need this value to work... Mathematical this is not an exact vernier.
Don’t want to blame the idea of the printed scale method... really not... I think this method is great... just not as easy for the user I think as the paper method. but mathematical it does not stand 100%... If I miss something - please tell me. What was done in #4904 is printing a vernier scale which isn’t a real one, because it could not be printed exact because of the skew. Want to say the failure that the skew generates influences the measurement, even its only a tiny bit...
Probably this could be solved by a lot of iterations. But wanted this to say just to be correct. Is this a real drawback – I think its not… the only question is how easy the method works compared to the paper method. Is it more accurate as the paper method? Yes it could, but keep in mind: A working vernier scale has to be done very exact to do any exact measurement. I really don’t know how we can print this even if we just know the "x" above with exact comparable marks on it... only one mark + or - we get +-0.1mm plus the x failure... Sometimes its difficult to read on a "perfect" caliper...
@S3DCreations The goal of the "vernier scale" method is to get to a state where both pieces come out with the same scale/length. Not that they have to be of a certain length, relative length before absolute.
There are a number of things that can be wrong with the printer, but frankly, if we for the moment only focus on the XY skew I believe this method can find a piece to the solution that can be applied in one of the steps to calibrate the printer. The scales/lines on the pieces, the vernier lines, is just an old way to figure out a sub-mm distance. It can be hard to measure an absolute length over a certain distance but with this method we can get a sub-mm relative distance pretty easily, I think. As long as the steps-per-mm for X and Y is reasonably accurate I believe a cross-comparison also reveals a value that is above the double side shift length for the same distance, which actually doubles the measuring accuracy possible (meaning if we use our eyes as the "sensor").
If you read my comments you could notice that I actually think my printer is within the margin (before compensation) that the MK2 is spec'ed to be able to calibrate to (its not actually very accurate which I can imagine comes from its a rough method to try to find the center of a metallic patch on the heatbed by passing over it several times). And with the pieces I showed I get my printer dead-on (or in numbers I believe about <0.05 mm skew over 100mm). Well, that's what I have to say. I have tried to put forward a couple of ideas. I have tested one and shared my results. Feel free to use them if you want.
The skew formulae isn't particularly difficult, MK2 is not unique in that way. If you saw this https://reprappro.com/documentation/ormerod/axis-compensation/#Orthogonal_Axis_Compensation the RepRap firmware has had it quite a while and they actually handle skew for the two other "planes", X/Z and Y/Z too...and their transformation is applied in these lines for those interested. https://github.com/reprappro/RepRapFirmware/blob/46ced15c5f6d1195545f2736b8090f14b2c0242b/Move.cpp#L1026-L1030 ...and we are only talking about XY here...
...and we are only talking about XY here...
Because x/z and y/z is what 3-point and (planar) grid levelling is supposed to do.
@Blue-Marlin Y/Z would happen if the Z stabilisation rods are tilting forward or backwards, and X/Z would happen if they are tilting left or right. I don't see how ABL or MBL compensate for that. Maybe I should draw a picture.
@Blue-Marlin ...and it actually gets very interesting if the Z rods tilts in opposite directions, i.e. one forward and one backward :-o which would cause a slight turn up though the Z axis.
Usually you have that (and a probe with y-offset) when you measure a saddle shaped bed. MBL and delta levelling are not compensating for tilt.
@Blue-Marlin Saddle? not sure I follow you, the twisted example? MBL, yeah no tilt. But ABL is only compensating the bed tilt compared to the Y movement (or the X movement over the bed). The Z movement is not compensated in ABL (it compensates the tilt relative the Y&X movement yes but not the Z movement). Feels like I really need to draw a picture.
@Blue-Marlin severe X/Z skew from "front"...
and severe Y/Z skew from the "side" (messy drawing but I hope you get the point)
...and while I am at it, I think this (from the "side") illustrate one case when ABL actually compensate the tilt (no skew, axis are orthogonal but bed is tilted)
The matrix-based bed levellings try to build perpendicular to the bed. They are not only correcting z but also x and y. Tilling the rods or the bed is equivalent.
https://github.com/MarlinFirmware/Marlin/blob/RC/Marlin/vector_3.cpp#L75-L82
Bending one z-rod to +y and the other to -y will result in a twist when the x carriage is moving. Amplified by the y-offset of the probe this will result in different height measurements depending on if we are at +x or -x. Twist in y is much harder to calculate, but you can achieve it by raising diagonal feet of the y rails.
If you combine the rotations you'll get the saddle. Two high corners at one diagonal and two low at he other.
Twist depending on the x position (around x) is especially interesting when the nozzle is on one side of the rotations centre an the probe on the other. Then our probe sees the opposite from what the nozzle sees. Bed levelling then compensates in the wrong direction.
But ABL is only compensating the bed tilt
That applies to 3POINT
and PLANAR
ABL. However BILINEAR
ABL duplicates what MBL does.
Yes, I know ABL will try add a tilt. I am not talking about that. Let's try this mental experiment. Imagine a perfect printer. All axises perfectly orthogonal to each other. Now raise the bed on the right side (X max side) 10 mm, and at the same time raise the X carriage equivalent on the right side. You say ABL would find this tilt and compensate for it? I do not think it will. Sure you can argue the sensor nozzle offset do, I would say it would just see a small piece maybe (what if the offset is 0 in X?)
That's the rare case where two errors compensate each other. Or, compensate so far that the probe system can't see the error. It works as long you have only one error - ether in the bed or in the x axis. As long as the errors are not of identical size the system at least tries to minimize the difference.
Ok, this then. Again, imagine a perfect printer (with ABL enabled). Imagine raising the X carriage on the left side (X max side) so the nozzle is several mm above the bed. You probe with ABL (not bilinear) and ABL is actively compensating while printing. Will the print tilt now or not? (you have not changed bed or Z or Y axis or anything else)
XZ orthogonal, Bed tilted, ABL works as intended.
XZ not othogonal, Bed not tilted, ABL does same compensation as above but result is a tilted model.
and for completeness, XZ not othogonal, Bed tilted so ABL is not needed (earlier example). Result is a tilted model.
...the XZ skew is a result of XZ not being orthogonal. Should we or shouldn't we be able to compensate for that? I still do not believe ABL do compensate for it.
XZ not orthogonal
Unfortunately this is not detectable automatically, and really I would prefer to encourage machines to be well-made and calibrated enough so that their Z is reliably perpendicular to XY.
Knock yourselves out guys: http://www.thingiverse.com/thing:1873549
By my print, my Original Prusa i3 MK2 which was purposely thrown together unsquared the last time and had approx 2mm XY bed skew was auto-corrected by the Prusa Marlin branch to -0.2mm total XY diagonal bed skew (which is in fact far better than the specs claimed by Prusa Research).
I'm heading out for the rest of the weekend, but have some changes I'll try soon (so released as v0.9.0 in typical hack fashion ;)
Human-proof alignment method:
Vernier scale to read (scad source has been updated from picture to show only +/- 10 measures on the 0.9 vernier scale calibration strip):
-=dave
XZ not othogonal, Bed not tilted, ABL does same compensation as above but result is a tilted model.
Here i disagree.
Ok, lets see if I can explain.
a < b
in both setup, this will cause a slight X movement to the right when Z increases.
(not to scale just want to point out the skew to right, Z upward should not move left or right thus no compensation needed/wanted in X only Z)
Here the current levelling system minimizes the 'difference' angle. between bed and x. If parallel a z-probe can't see a difference. Ether an other probe (if we have a correct reference surface) or a manually measured value will help.
If we need that? At least for me the priority is low. Levelling the x-axis with stoppers on a i3 is too easy.
Nice sticks by the way :) though, they moved I guess
I think the rules here are...with ABL (tilt) X and Z should be perfect 90˚ but for MBL bed and Z should be perfect 90˚ (as long as we do not have a good compensation method)
@Blue-Marlin Actually I think your sticks show what I mean. They will produce the same ABL matrix, but in the first pic where X (carriage) is 90˚ to Z we see a tilt which results in a X movement is needed. In the second pic the bed is 90˚ to Z and we do not want a X movement (would cause a skew).
I see. You are right. My error was to believe in alpha is fix to the tilt x-axis. But it is not. Alpha is fix to the (theoretically vertical) z-beams.
I think the rules here are...with ABL (tilt) X and Z should be perfect 90˚ but for MBL bed and Z should be perfect 90˚ (as long as we do not have a good compensation method)
I agree. With the rotation matrix based methods we fight tilt. With the mesh based - unevenness. With a unified method we could fight both.
Presuming the axis of the motion system are perpendicular: Probe the points. Determine tilt of the bed. Set up the matrix. Turn the probe data by the matrix. Use the matrix for movement. Use the turned mesh data for z correction up to the fade hight. Never stop to using the matrix In a unified bed levelling
https://github.com/MarlinFirmware/Marlin/issues/5189
I was thinking (dont kill me), would a first step not be to get the X axis parallel to the bed?
On a mendel90 the 2 back corners are a fixed height so you could use those 2 to meassure if X is parallel to the bed and adjust by that. This would only require that you have individual Z stepper drivers.
For X/Y skew.... its a bit harder for me to figure how we can do that without it being special... inductive probe points... or points where an inductive probe would not trigger would be to special... thou it will be more precise as you know beforehand where the points are and you just have to search for them
hmm... with an inductive probe... if its given that it can go so much beside the bed that it will not trigger if it can move that much extra in both X and Y direction it should be able to slowly crawl along the edge and scan it at some set points?
same with an touch probe, thou it might be more tricky to do
@boelle In the last few weeks we wrote a lot about this. Please take the time to read and try to understand what we already discussed. To ensure to have x/z at 90°, Prusa i3 V2 uses a very simple method. They trust in the angularity of their frame and the exactness of their printed parts. All the have to done than, is driving z upwards until both z-steppers stall. A similar adjustable solution is: on both z-spindels. Only one stepper driver needed. Only one endstop needed. No software needed.
ahh.... yes, we could do the same...
Never thought of that.
it would be a one time setup for us and then yes just drive both Z up antil they stall
but would that work for all printers? ie owner must make sure there is clearance enough for the nuts
Hi Folks,
at first sorry for my poor english - but I will try my best. I'm completly new here but have several experience in 3D printing and building up my own cartesian maschines. So here ist my request:
Due to the fact, that a real 100 percentage squaring of the X and Y axis could not be really done by hand I thought it would be really practical to have a kind of an Angle Offset Parameter to be cahangable in Firmware. This parameter could be calibrated just like the steps per units parameters in Marlin by doing some messurements.
Doing a little math, this could easily achieved by generating new coordinates for X and Y from the GCode feedet to the printer:
X_new = X / cos(alpha) Y_new = Y - X * tan(alpha)
alpha is the angle the Y-Axis versus X-Axis differ in positive movement direction (could be perfectly messured with a 90 dregree testprint). For example:
The angle between Y and X ist 92 degrees --> alpha = 2
Or
The angle between Y and X ist 89 degrees --> alpha = -1
I think it would be much helpful to define this Offset-Angle (alpha) in firmware for doing a fine calibration of squaring the Y-X-Axis. If alpha = 0 there would be no changes to the coordinates at all.
Hoping for resonations in any form and have a nice day S3D