Marlin: Feature Request: X-Y-Axis Squaring Adjustment

Created on 30 Oct 2016  Â·  106Comments  Â·  Source: MarlinFirmware/Marlin

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

Feature Request

Most helpful comment

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).
calibration_sheet_v1

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)

Calibration Sheet_v1.pdf

All 106 comments

Duplicate of #4904, #3014

Hi,

sorry, didnt know about these oher requests. My opinion to #4904 is that the Prusa MK2-Way ist too specific to the printing machine itself for the moment. Once heated beds with induction points will become more available this could be interessting.

At the moment I was wondering why "the easy way" like I discribebed above and in #3014 wasnt already implemented. I searched for this way to calibrate so I started this request.

Adjusting the software_max_endstops could be done with this little calculation also very easy. Perhaps its possible to deliver a standard stl-file for any user for the XY-calibration (I could design something easy to print an meassure). The big adavantage ist that this method can be used by every printer just by giving the offset angle to marlin and youre done...

Im not this deep in Marlin to implement it by myself so I'm hoping ther are possibilities to implement it on the clean way just througt the team.

best regards
S3D

@S3DCrations Can it be done in the slicer instead?

@clefranc I have not found any option in any slicer I know for doing something like manipulating every single coordinate...

But I think also its a calibration problem which depends on the printer itself and not to the stuff to print. Its just like the calibration of one single axis or the extruder. This time its the angle of X-Y.

Have attached the short calculation I made... sorry for the poor quality.
20161030_191248

@S3DCreations I did not want to imply that slicers can do it right now, but 8-bit processors are already overused, so then asking the slicers communities is perhaps another option. It's only a suggestion, I did not thought about it very deeply.

I did not want to imply that slicers can do it right now, but 8-bit processors are already overused, so then asking the slicers communities is perhaps another option. It's only a suggestion, I did not thought about it very deeply.

This is an interesting way to solve the problem. After all... The Slic3r's are running on a processor with almost infinite processing power compared to the 16 MHz AVR processor!

@clefranc This is a good point, but I it schould use much less calculation power as the transform process to delta coordinates for example which can also be done easily.

Perhaps its possible to change the GCode with a script, but I think this would only be one step more unnecessary in the printing routine. But if someone is able to write such a script I would be very interessted in testing it :)

@alexrj Is a skew correction a viable option in slicers?

Theoretically the correction can be made in every step from CAD over slicer to host and firmware, or as a pre or post processing step of each of them. Most sense it makes in the firmware, because the 'error' is part of the machine.

looks as if it would cost a lot of time, but it is not.
Because the angle is constant the sin/cos/tan can be precalculated. For angles below 2° the difference to 1 is less than 1/°°. If short on processing power this can be assumed as 1. What then remains is a multiplication and a subtraction per transformed coordinate.

(DELTA and SCARA do not have perpendicular x and y axes - they can not have this error.)

@Blue-Marlin That sounds very positive :) But keep in mind that theese corrections only make sense for angles below 2°, because for bigger angles we could calibrate the printer mechanical.

Indeed the X-Correction is always much less than the Y-Corretion... So for the X-coordinates taking cos(<2)=0,999=1 schould be not as noticeable as for the Y-coordinates -> tan(2)=0,035

Greetings
S3D

What then remains is a multiplication and a subtraction per transformed coordinate.

Currently the planner/stepper still works with an offset coordinate space (applied by M206 and G92), but I hope to make it so that they only work with the "raw" coordinates for 1.1.1. At that time it will be slightly less expensive to handle the skew — handled transparently at the planner level.

Because the angle is constant the sin/cos/tan can be precalculated.

Reminds me of the good ol days. SIN/COS lookup tables in 3D gaming engines to speed things up :)

Reminds me of the good ol days. SIN/COS lookup tables in 3D gaming engines to speed things up.

Indeed. Just like the good old days of programming OpenGL directly using transformation matrices.

Maybe transformations in Homogeneous coordinates are not a that bad idea. Scaling of too big or small values is easy then.

Looking up sin() & co. is overkill here - just calculate once with the normal function and store the result. The angle changes are rare.

just calculate once

Just like OpenGL transformation matrices. The reference point for applying the rotation factors has to be in the center of the coordinate space. The Prusa MK2 branch has us covered. We just need to adapt its code to the newer Marlin.

If the coordinates used in Marlin are absolute ones (like the GCode travel positions) the rotation factors should not depend on any position at all. Even for negative coordinates the result is correct (The difference in the Y-Calculation turns in a sum for negative X's).
The origin of my drawing above is the absolute position of X=0 and Y=0 for any Printer, no matter if this position ist the center of the printbed or the left front corner...

the rotation factors should not depend on any position at all

I know how to rotate a coordinate system, having written way too many graphics engines in my career. In the general and symmetrical case, the fulcrum should be the center. But in the case of bed rotation it can also be off-center or include a post-translation, depending on the calibration points. Check out Prusa's code.

'Turning' is wrong anyway.
We don't want to turn a rectangle. We want to modify a trapezoid to a rectangle or the other way around. So only one axis has to be modified to fight the "x/y-axis are not perpendicular to each other" error.

Suppose x and y to be perpendicular. Now bolt the bed at the midpoint to the y-cariage. Now turn the bed by some angle. Now a part of bed-size will not fit on to the bed anymore. That's what you fight with a rotation.

In the case we want to handle here, not perpendicular axes, you will get a turned trapezoid if turning both axis.
Edit:
Sorry replace all trapezoid with rhomboid.

@Blue-Marlin Yes, quite right. On a Prusa-style setup the X axis will still be cross-wise, while the Y axis will be slanted. I believe we still need to choose a reference point for where the slanted Y axis is centered, or at least apply some shift in X from a common reference point. Then there's the question of how to establish the amount of skew, whether by probing or manual input.

I believe we still need to choose a reference point for where the slanted Y axis is centered

Im not a software engineer but look at my post above. Mathematically a reference point should be obsolete. In any case there will be given a little(!) lost of room in Y-direction given by X_max * tan(alpha) due to the correction.

Then there's the question of how to establish the amount of skew, whether by probing or manual input.

Is it possible to give both ways of Input. Manual input will work on every machine out there.
For the probing variant and since the original Prusa MK2 Heatbed is not offered stand alone for this time, I'd really like an open source variant of an Heatbed with induction-points.

a little bit off-topic:

In the next month I try to engeneer an open soucre PCB Heatbed based on the induction-points method. Therefore I have to figure out how many and where is the optimal position for these points. Since I'm not to deep in programming I'd need a little help of what is the best way of routine the probing through marlin.

But one Problem I have with this method of this "Prusa-Way": Whats if the heatbed isnt perfectly square to the Y-axis itself. Doest the Prusa code algorithm stand this an will correct in "both ways"?

Greetings
S3D

Usually the entire bed is reachable by the nozzle. Because inductive sensors can not be integrated directly into the nozzle they have an offset to the nozzle. Ideally the spots are all reachable by the probe. That means they can not be very close to the edges of the bed. On the other hand, best accuracy is reached when the spots are as far apart as possible - big distances amplify the displacement for small angular errors. There is no simple way to fulfil both. You have to set a value. Maybe 40mm from the edges is a good value.

You can minimize the mess, when the probe offset is too larger, by having at least 9 spots. Regardless of how big and in witch direction the offset is, at least 4 spots are reachable. 3 is the minimum to determine the displacement and rotation angles. More is better because then you can average the measurements.

At the spots you can't heat. So minimizing the amount of spots is good for the heat distribution.
One point should be in the centre of the bed. In a skewed only (not bent) bed the point in the middle has automatically the average (middle) height.

The positioning of the spots is critical. Their positions are the reference for the measurements. The don't have to be symmetrical to something or each other, but their positions have to be known as exact as possible. 0.1mm error is for sure to much. Errors below one micro-steps length don't make sense. We can't measure the difference. The exactness of the outer shape of the bed is completely uncritical.

The size of the spots is unclear to me. With my M8 inductive probe i can find one of the iron m3 mounting bolts in my alu bed (the others are not reachable). But centering on this ~6mm diameter spot is hard till impossible. A bit larger would be helpful. The M6 probe arrived but has no mount jet - so it is untested. I don't know if it will make a difference. My guess is, with smaller probe diameters and bigger spots centering will be easier. 10 - 12mm diameter could be usable. On the other hand big spots disturb the heat distribution more than smaller ones.

The gap between the spots and the next heating traces should be as large as possible to get the maximum signal difference - but as small as possible to not produce cold places.

If money would not matter i'd experiment with multilayer heater boars. Spots on the top side, hater traces at the bottom. Or a additional layer, in solid copper, to distribute the heat better. (No clue if this disturbs the spot detection.)

Varying the heater trace density around the spots and the edges of the bed may make the heat distribution better - or worse.

A solid alu bed with isolated copper traces like the Mk3 is probably a bad idea.
Glas on the bed is probably a bad idea. The datasheet trigger distance for the M6 probes is only 2mm. 2mm glas will be a bit brittle.

The PEI covers for the Prusa bed have been available from Prusa when i looked them up the last time. But in theory i'd like it a bit more rigid (used to a solid alu beds (Dauerdruckplatte)).
Thickness of the FIR? No clue. More increases the mechanical rigidity but probably will give more thermal warp, when one side is hotter than the other.

Sorry i don't have a ready plan. But at least you should now know about most of the parameters to consider.

@clexpert
How is your experience with the MK42 (new Prusa bed)? Durability of the PEI? Adhesion? Does the levelling always work? Is the heat distribution as good as promised?

The algorithm for calculating the correction angles is about that:
Take two points that theoretically are on the same x. With the known distance of the spots and their x difference build a triangle with a right angle and calculate the difference angle to the ideal line (alpha).
Do the same for y and call it beta. If now alpha == beta we have a rotated only bed. If they are different, the difference is the error of the both axis to 90°.
For the complete correction turn x by alpha and y by beta. Or if you want to save some time and the common rotation does not matter, turn only one axis by the difference between alpha and beta.

If you have more spots calculate alpha and beta for all combinations and take the averages.

With the known distance between 2 spots and the measured distance between them you can also scale the steps/mm value.

For how to find the spots centres take a look at Prusa article (http://prusaprinters.org/first-printer-to-automatically-correct-geometry-in-all-axes/).

With the printed parts @epatel suggests you will find the difference between alpha and beta. The pure rotation is invisible.

If the bed is flat when unmounted there are only a few ways to bend it, if mounted near the edges. with 3 or 4 rigid mounting points.

Thermal expansion: If the bed is hotter on the upper side then on the lower side we get a convex bowl shape at the upper side.

Mechanical compression between the mounting points results usually in a roughly cylinder wall shape. The direction is undetermined. If the compression is in both directions the result can be bowl shaped, but usually does not, because the bow in the one direction is stabilising the other.

Load in z direction results in a roughly bowl shape. If convex or concave depends on if the load is applied between or outside the mounting points.

All the possible shapes have in common:
There is only one maximum or minimum.
They are steady. (else the bed is broken)
There is no turning point (f''(x,y) = 0)

Together that means the surface is relative good describable by 9 points.

A additional mounting point in the middle of the bed limits the max amplitude of the unflatnesses because the unsupported length are shorter, but makes the possible shapes much more complex. I guess you need about 25 points to get a rough description.

If the mid mount is the only rigid one, but the edge mounts are flexible in x/y direction the compression cases can not occur, but the possible shapes are not much simplified.

@S3DCreations @Blue-Marlin I presume we've all seen Prusa's video on the subject of bed skew compensation and mesh leveling. If not… https://www.youtube.com/watch?v=rYrLT5G-a9I

One day, when we have unlimited processing power, we should try to use splines to connect the measured spots. The steadiness (in f'(x,y)) of the surface would be much improved, compared to connected straight lines. More like the real worlds physics. No sharp folds anymore. (just to prevent patents - if not already invented ;-))

Skeptical myself about the MK42 HB, and Prusa MK2 in general, now having toyed with it for about a month, I can say I am thoroughly impressed how Josef has embraced the notion of the old hardware engineer adage, "we'll fix it in software."

The MK42 heated bed isn't even flat on delivery, and only marginally better once mounted onto the machined Y carriage frame. Yet with just nine induction points across a 250mm x 210mm surface, this thing prints a flatter and more accurate first later than my old Printrbot Simple Metal (aka, "the tank") with 1/4" thick Mic 6 machined aluminum 150mm x 150mm heated bed.

After assembly I had to take the XY Frame apart to replace something, and as a test ( or more a test of my patience), I put it back together purposely skewed about 2mm on each axis. The result was a nasty, "Axes severely skewed! Will compensate…" after calibration routine. This thing is skewed in every way except that the bed is square with the Y axis movement, and yet produces absolutely perfect prints indistinguishable from when it's assembled perfectly (which is only possible after eight hours of continuous fiddling).

Having assembled this i3 design, I don't see how he could've fixed it any other way: The design is crap; sure, it includes the ability to adjust every possible angle, but it also gives no fine control to do so. If you make one small adjustment to any of the grossly course threaded rods, every other angle is thrown off as well. It is nearly impossible to get it perfect without some kind of jig, or the aforementioned tenacity to keep trying until it's right.

I really have to hand it to him: he fixed his raprap design in the only way it could have been while still keeping with the spirit of the reprap community.

Of course this let me directly to disappointment, in that there's absolutely no way to run vanilla Marlin without a severe downgrade in print quality (my interest in LINEARADV is what brought me here).

In summary, automatic skew correction and mesh bed leveling is the magic bullet target everyone should strive to hit: it just works.

So how do it accomplish this. So everyone can benefit even those without inductive probes

no way to run vanilla Marlin without a severe downgrade in print quality

@fiveangle Of course, now we're incorporating aspects of MK2 into the main branch. The MK2 jerk and acceleration code enhancements have been adapted, for example.

The mesh-based AUTO_BED_LEVELING_BILINEAR now supports cartesians, whereas it used to be limited to deltas. The LIN_ADVANCE feature is much more solid than ever before.

I'd be interested to know how well RCBugFix (soon to be 1.1.0-RC8) works on the MK2. I have a self-sourced Prusa i3 myself, and am looking forward to trying the latest code on it when my travels are done.

The question apart from the software calibration process for me is: is there a need for an open source heatbed with induction points or not. I'm thinking here on other sizes (200x200, 200x300, 300x300) but it has to be open source and setting a standard for the induction probe method. Therefore should be given a method to define the type of "induction-spot-satndard" in firmware. Perhaps just like setting the right thermisor also setting the right probe-method (matrix for finding the points; or just "copy" the Prusa points?) for the heatbed. And that would be firmware related stuff.

I have a lot of ideas how to design such a pcb and how a standard could be established. If there ist enough interrest we should maybe start a subdiscussion which is related to this discussion.

Sorry for beeing off-topic again, but I think the devellopment of a heatbed has to go hand in hand with the calibration process at all.

Couldn't you get the probe points by finding the corners of the printbed? The distance from those points should be known.
EDIT: You could enter the bedsize in the configuration

the development of a heatbed

It would have limited utility due to the wide variety of bed sizes. But I guess that Prusa Research will probably be selling their custom PCB on its own without a printer, in which case we can at least add support for that specific arrangement of inductive traces. Then it can be generalized later if other PCB sizes appear on the market.

@thinkyhead therefore I said lets find a standard for the points... for example 9 points arranged in a square with known distances.

for example:
Bed 200x200: 5cm (point-to-piont)
Bed 300x300: 8cm (point-to-piont)
Prusa M42: ??cm

These standards could be added to firmware and just need to be defined through the user. Just like setting the right thermistor. Or even a matrix where the user can define the coordinats for the points by himself from center as reference...

This would open up the developping of these kind of new heatbed PCBs for the community and speed up developpment of 3D-printing technology... nearby making Marlin the first choice - even for the original Prusa MK2...

@S3DCreations I think it actually depends on the bed. A perfect flat bed doesn't need any mesh points at all. And I think its also a matter of _inconvenience_. The MK2 seem to do a probe cycle before every print but I use EEPROM with MBL to store the mesh so I maybe do a probe sequence once a month. More points takes longer time etc.

My usage, a RigidBot BIG, bed 300x400, probing 4x5 points (I consider the bed being very bad)

@epatel inconvenience could be a reason for some users. For me its a way of fine-tunig the squaring process for getting the maxium out of the printer when adjusting by hand is no more possible. Just like the Z-correction bedlevelling.

Anyway... inconvenience or not... it should help making the prints more exact while adding a "self-test" for the printer and that would help the technology to spread out in the low-cost segment... And nobody has to use it if not wanted, just like Z-probing...

And finaly... isnt it cool if my printer can say: "Hey, my Printbed is a little bit off since the last 15 prints... please check me!"? ;)

Could it be a removable board with special dots on it, you lay it on top of your print bed.. clip it down to your glass and do a measurement, then remove when no longer needed..

I assume you wouldnt need to do this very often.
and this way many people can easily add it to their machine

Piece of glass with Screenprinted metal dots?

"Skew Calibration Plate" :)

Could it be a removable board with special dots on it, you lay it on top of your print bed.. clip it down to your glass and do a measurement, then remove when no longer needed..

Interessting idea of a surface just for calibration... but we want the this procedure to get the maximum accuracy. If positioned such a Plat manually to the bed we have again the human factor and its imperfections... in other words: you would have to calibrate the calibration plate on the heatbed even better as your axis...

but as i said: nobody has to use this... and you can tell the firmware by hand to calibrate in the printers menu or in an intervall of serveral prints - dont have to use it every time.

if you square up two edges of the calibration plate with the glass bed
it "should" be accurate enough..,

couldnt you do the same with just a carpenters metal Square
put it on the two edges and have a prox probe detect the edge. and see how square it is??

These standards could be added to firmware and just need to be defined through the user.

Surely. When I do the integration that feature from the Prusa MK2 code I will follow the usual procedure – make it a more general feature and make it fully configurable.

if you square up two edges of the calibration plate with the glass bed
it "should" be accurate enough..,

the question is what is "enough" when software can do a way more exactly for the last 1/10 degrees...

couldnt you do the same with just a carpenters metal Square
put it on the two edges and have a prox probe detect the edge. and see how square it is??

Of course you can... and you should! Get the maximum by hand and let the software do the rest wich you cant...

I wasn't really talking about do what you can by hand to make the machine as Square as possible even though you should but I meant is put something down on the bed that is square and then have the machine read how Square it is to compare to its own movement

@adamfilip Okay, now I got your point... Let me just think about it:

Since rotation of the heatbed and therefore also the rotation of the "Calibration Plate" is not relevant for the calibration process itself we should be able to meassure the squareness of this plate even if it is rotated... So if there is meassured a rhombus we could calculate the offset-angle for the printer...

is this the idea?

If so we only need an algorythm for finding the first induction spot, then do a circular search (since we know the spots distance) around this spot for finding the next two ones and so on...

Could it be a removable board with special dots on it, you lay it on top of your print bed.. clip it down to your glass and do a measurement, then remove when no longer needed..

I think this is a good idea! Because if the calibration plate can be removed, the standard heat beds can still be used and the heat distribution won't be affected. And I'm all for automated probing, but it would seem a machine without a probe could still be calibrated this way. You would just very carefully move the nozzle to each calibration point and say "Its there!"

Wouldn't it be nice if you could just print the "Calibration Plate" on your Paper Printer and tape it to the bed to get your machine's numbers? You do it once, and just lock the numbers into the firmware for future use.

Yeah, thinking about this the last half an hour I'm also on this way to go... especally because all kinds of printsurfaces would be possible...

and it can nearly be fully automated... Just put this plate near (not exact) to the middle of the heatbed. The Printer serarches for the predefined points on the calibration plate... calculates out the rotation if needed and gets the angle of the rhombus... thats it...

The plate has to be a flat (therefore little bit thicker against bending over time) PCB with etched-in induction points... only problem here is the z-offset for the thickness of this PCB, but there schould be a secured offset parameter just for the probing to be figured out...

The printer can also remind you to do the calibration probe after a defined numer of prints, to keep his his offset angle in firmware up to date....

I use roland wide format vinyl printers/cutters at my work and these use optical sensors to detect printed ink black dots. It measures 4 of these dots to do a skew/scale correction. I'm not sure exactly what these sensors are. Seems like a very crude device that can see contrast. Doesn't look like a camera

Meassuring a printed sheet of paper would be fantasic... but i have a little bit of fear of optical sensors...

-how acurrate are they?
-how will the ambient light affect the meassuring?
-need for an extra sensor on the prinhead.

I will have to get aound of the possiblilties of optical sensoring ;)

Measuring a printed sheet of paper would be fantastic... but i have a little bit of fear of optical sensors...

All valid concerns... But what this would do is enable even the very lowest level machines to have their skew corrected if the owner was willing to print (on paper) a calibration sheet and run the nozzle tip around the bed to 'sample' points. It really would be great to have a solution that handles the entire spectrum of machines.

Aligning the nozzle over 4 points on a printed pieces of paper that is taped down to the bed. After aligning one side of it. Can be tricky perhaps if it was a pin or something very sharp. It can make it easier to do very precise positioning

In the crude, very primitive case... Even taping a toothpick to the nozzle would probably work. (You could not let the taped toothpick touch the bed because it would shift its position!) And regardless of how the 'Calibration Plate' was taped to the bed, it would seem the algorithm should come up with the same correction numbers for the skew.

Perhaps it would be better to do this manually... manual find the spots with the nozzle and let the printer collect the coordinats by pressing a button... or type the coordinats of the dots directly into the firmware...

so there is no need for a automated search for the paper method...

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?

xyfan

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).
calibration_sheet_v1

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)

Calibration Sheet_v1.pdf

Just cleaned up the excel sheet for everyone... You can try it on your printer and do the calculation with Excel if you like...
excel_calc_v2

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"...
skarmavbild 2016-11-04 kl 02 24 45
and severe Y/Z skew from the "side" (messy drawing but I hope you get the point)
skarmavbild 2016-11-04 kl 02 36 21
...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)
skarmavbild 2016-11-04 kl 02 41 22

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.
20161104-131954

XZ not othogonal, Bed not tilted, ABL does same compensation as above but result is a tilted model.
20161104-131954 2

and for completeness, XZ not othogonal, Bed tilted so ABL is not needed (earlier example). Result is a tilted model.
20161104-133843

...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:
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):
Vernier scale to read

-=dave

XZ not othogonal, Bed not tilted, ABL does same compensation as above but result is a tilted model.
218a8f5c-a292-11e6-96fc-d0e5325f2602

Here i disagree.
x_not_horizontal

  1. x axis is tilt by alpha. probe system sees low height an the left and high at the right.
  2. Levelling system assumes a horizontal x axis and interprets the probe data as a bed tilt by alpha.
  3. All is well.
    x_not_horizontal_stick_2
    x_not_horizontal_stick_1

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.

feature_request__x-y-axis_squaring_adjustment_ _issue__5116_ _marlinfirmware_marlin

feature_request__x-y-axis_squaring_adjustment_ _issue__5116_ _marlinfirmware_marlin
(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)

parrallel_but tilt
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

_1__feature_request__x-y-axis_squaring_adjustment_ _issue__5116_ _marlinfirmware_marlin

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:
picture 3
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

There are NO universal solutions! The world is not that simple.
Obviously we need at least two z-spindles her. Otherwise you can't have this problem.
The lead of the thread has to be small enough to produce enough clamp force to lock the countered nuts otherwise you have to use clamp rings instead of 2 countered nuts.
If the pitch of the threads is to fine you will 'lock' the carriages on the two nuts - or worse, only one of them. You will need something to help with the separation when lowering the axis again. (Springs, Teflon washers, ...)
...

Just as an interjection here IR sensors are in many ways superior to inductive. They don't require a special surface and they even work on clear glass. My $0.02

You need to differentiate which ir sensor. There's reflective ones and phase difference ones.
The reflective ones are utter garbage and don't work on black or near black surfaces.

Differential Ir sensors don't work on reflective surfaces such as aluminum because it over saturates the sensor.

So while they work well on some surfaces inductive and capacitive probes still have their place

We got a submission #8159 but it was targeted to the wrong branch. Hopefully the author will re-submit. If not, someone will try to repackage it for the latest codebase.

This should be closed as the skew code has been added.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings