Feature Request: X-Y-Axis Squaring Adjustment

[S3DCreations]

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

[Blue-Marlin]

Duplicate of #4904, #3014

[S3DCreations]

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

[clefranc]

@S3DCrations Can it be done in the slicer instead?

[S3DCreations]

@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.

[clefranc]

@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.

[Roxy-3D]

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!

[S3DCreations]

@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 :)

[clefranc]

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

[Blue-Marlin]

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

[S3DCreations]

@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

[thinkyhead]

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.

[gcormier]

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 :)

[thinkyhead]

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.

[Blue-Marlin]

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.

[thinkyhead]

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.

[S3DCreations]

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

[thinkyhead]

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.

[Blue-Marlin]

'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.

[thinkyhead]

@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.

[S3DCreations]

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

[Blue-Marlin]

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.

[Blue-Marlin]

@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?

[Blue-Marlin]

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.

[Blue-Marlin]

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.

[thinkyhead]

@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

[Blue-Marlin]

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 ;-))

[thinkyhead]

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.

[fiveangle]

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

[Blue-Marlin]

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

Here i disagree.

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.
   
   

[epatel]

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)

[Blue-Marlin]

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.

[epatel]

Nice sticks by the way :) though, they moved I guess

[epatel]

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)

[epatel]

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

[Blue-Marlin]

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

[boelle]

#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

[boelle]

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

[Blue-Marlin]

@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.

[boelle]

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

[Blue-Marlin]

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

[landodragon141]

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

[FHeilmann]

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

[thinkyhead]

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.

[landodragon141]

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

[github-actions]

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.

[github-actions]

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.

[github-actions]

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.