XY angle compensation

[boelle]

From @MLWORKX on May 13, 2016 8:35

This is a re-opening as it was closed on an /Marlin MarlinFirmware/Marlin#3014

"Hi, even when the (cartesian) printer is calibrated very well there is no way of calibration the correct 90° angle of the XY plane: you have to do this on the hardware side via loosening the belt gears and hope you did it correctly. So like the bed compensation where the Z axis moves when X and Y are moving it would be a nice feature to have a XY calibration possibility as e.g. the M92 feature for the dimensioning. Just add a compensation angle (e.g. 0,2 degrees) when the angle between X and Y is not exactly 90° and no hassle with the belt anymore."

Copied from original issue: MarlinFirmware/MarlinDev#422

[boelle]

From @Roxy-3DPrintBoard on May 14, 2016 19:3

This can be done and would be fairly straight forward because the Auto Bed Leveling (Grid or 3-Point) maps a specified coordinate to a new location. But getting the X & Y square is not difficult on most machines. I'm struggling to see a benefit when the machine can just be adjusted to have X & Y normal to each other. And assuming the case can be made, it does add complexity for people that don't need this (which is the bulk of the users).

[boelle]

From @bdowling on May 15, 2016 3:24

Wouldn't it also likely result in non smooth veritcle sides of xy planar surfaces with all that micro stepping?

This seems like a physical fix is the better solution.

Is this request specific to gantry style machines?

On a rod/rail style printer your likely stressing the bearings and bit and not smooth as it could be.

[boelle]

From @MLWORKX on May 15, 2016 7:12

I'm struggling to see a benefit when the machine can just be adjusted to have X & Y normal to each other.

The thing is that there are several printers on the market where the rails, the belts and everything which slines linear tends to be in a very tiny space: so it's hard to adjust and to unlock a screw, push the rod in a direction and re-adjust the screw will NEVER be as accurate on printers which large build volume

And assuming the case can be made, it does add complexity for people that don't need this

Well it does, you're right. But adding a short comment in configuration.h to explain and set this compensation value to 0 would not add complexity to the system I guess - not more than all those PID, autolevel,... features

This seems like a physical fix is the better solution.

Yes it is: but there are machines where this is absolutely impossible as there is no space to adjust

Is this request specific to gantry style machines?

It's an xBot 155 printer and I'm struggling since weeks to print an accurate 90° angle.

From my point of view it would make machines much more precise if you just could add something in configuration.h (or do it via an M command) and I also do not think that it would make the system more complex. Those who want to fine-tune their machines -and mine do far better than every >30k Stratasys machine- it would make their parts a bit more accurate and perfect.

[MLWORKX]

Hmm - why was this closed without a reason?

[Roxy-3D]

@MLWORKX Do you know much about Matrix math and in particular Matrix Multiplication? The reason I'm asking is with the Grid Based Auto Bed Leveling system there is a 3x3 Correction matrix that is used to compensate for bed tilt.

Right now the matrix is symmetrical down the diagonal. I don't know this for a fact, but if we shift that matrix from being symmetrical I think we can handle the case where X & Y are not 90 degrees.

This is a very interesting topic, but I can't help on it right now. Once the Unified Bed Leveling is released I would be willing to to jump in. But maybe you can do some research and see if we can map into a non-linear space using the correction matrix. My guess is "Yes!" but I need to see the math to understand how we do the correction and get the matrix setup correctly.

[Blue-Marlin]

3014

If the matrix is not symmetrical any more we need a much more complex way to find the inverse. Currently the transposed matrix is the inverse.

[Roxy-3D]

@Blue-Marlin Can you help me understand why we need the inverse of the correction matrix? The reason I'm asking is we just multiply the correction matrix by the [x,y,z] coordinate to get the new coordinate. Is it because we need the inverse matrix inside of qr_solve() ?

It would be a slower process to obtain, but just as it is possible to perform an iterative solution to get the correction matrix right now (instead of using qr_solve() ). We could do a more complicated iterative solution that also converges on non-symmetric numbers for both the bed tilt and X/Y alignment. If that solution did converge (I think we could construct it so that it did), we would not need the inverse matrix, right?

[thinkyhead]

When correcting for a tilted bed, where the whole bed is treated as flat and tilted, I would think all you need is to reduce it all down to two slopes and a base Z offset. Then all you need for correction is to use the slope in X, the slope in Y, and the perpendicular slope in Z. Maybe I'm just re-stating how it already works, glossing over complexities…?

[Roxy-3D]

Yes. I think that is true. But I would word it differently.

There is a single vector (with an X & Y) component that describes the 'Normal' to the plane. That is what the 'Correction Matrix' represents. We already fully understand how to do that. Now.... If we can generate an appropriate matrix, I suspect we can also correct for the X & Y distortion at a fixed Z level. (I don't know this yet. I haven't spent the time to understand the math. But it seems reasonable given our current correction is done with a symmetrical matrix.)

I have an iterative solution that produces the same results as qr_solve() and saves 10KB of code for the tilted bed. It runs slower, but finishes its work in 5 or 10 seconds. We could make it also solve the X & Y shear angle as part of the calculation. At that point, there is no matrix math involved until we have zero'ed in on a correction matrix to let the planner use. (In this scenario, we wouldn't need an inverse matrix that might not even exist to calculate the matrix that we do need.)

But there are other issues to fully understand in the design. If it is possible to do the X & Y Shear angle correction using the matrix math, we still need to have a reliable way to measure (probe) the error. With the bed tilt (and for that matter, the uneven beds with Mesh leveling), we can measure the error with a Z-Probe. How do we measure the X / Y angle error? Without a way to probe and measure the error, we can't correct for it.

[Roxy-3D]

Found the code @Blue-Marlin was talking about:

  vector_3 Planner::adjusted_position() {
    vector_3 pos = vector_3(stepper.get_axis_position_mm(X_AXIS), stepper.get_axis_position_mm(Y_AXIS), stepper.get_axis_position_mm(Z_AXIS));
    //pos.debug("in Planner::adjusted_position");
    //bed_level_matrix.debug("in Planner::adjusted_position");
    matrix_3x3 inverse = matrix_3x3::transpose(bed_level_matrix);
    //inverse.debug("in Planner::inverse");
    pos.apply_rotation(inverse);
    //pos.debug("after rotation");
    return pos;

[thinkyhead]

Without a way to probe and measure the error, we can't correct for it.

XY twist angle would have to be handled manually, similar to manual mesh leveling, except you would be aligning XY at 4 corners. Of course this will "never" produce a perfect square. But you might average the angles of the 4 sides of the square to get the average twist angle.

[Roxy-3D]

XY angle would have to be handled manually, similar to manual mesh leveling, except you would be aligning XY at 4 corners. Of course this will "never" produce a perfect square.

If the person was able to move the nozzle to all four corners of an accurately measured square on the bed and those coordinates were locked into the firmware, we would have the information needed.

[MLWORKX]

If the person was able to move the nozzle to all four corners of an accurately measured square on the bed and those coordinates were locked into the firmware, we would have the information needed.

My intention when creating this feature request was that it should be very simple for users to solve an angle deviation like we already can when we have dimensional deviations by entering a user-defined M92 X Y Z__ value.

I usually print a large L shaped object so you can measure absoute and relative dimensional deviations and you also would have the information that one axis is e.g. 1° off (or let's say e.g. +-0,5mm on 150mm of this L shaped object). I personally would prefer to have t(h)e possibility to enter a value than to move the nozzle to 4 points on the printbed and save the values.

[boelle]

would be awesome.

I guess josef prusa does this by having dots on the bed where it just does not trigger and that these spots are know in advance so that you can search for the precise coordinates and figure the skew

so if josef would sell the beds seperate it would be an easy one

[rshayduk]

Dear colleagues,

I am building my own Cartesian 3d printer and have thought on the topic before. What I would really be interested to have in any printer software (Cartesian) is the option to calibrate the printer axes. By calibration I mean the determination of all three Printer's basis vectors a1,a2,a3 in terms of Cartesian basis vectors e1, e2, e3. For a perfectly-built Cartesian printer this would be a1=const1e1; a2=const2e2; a3=const3e3; In reality, each manufactured Cartesian printer has not-a-really-orthogonal axes, as this depends on how a particular unit was assembled. This a critical point when printers are built from kits by non-professionals. In real case, (a1,a2,a3)=M(e1,e2,e3) in which M is the transformation matrix that can be determined by firmware after printer calibration is done.

The calibration procedure should look, approximately, like this: Imagine we have a perfect CNC-machined steel coordinates system as a reference. For a 2d case discussed here, an engineering right angle corner can be used. When steps/mm are calibrated, one positions the printer nozzle into three points on a plane, one by one, and tell the software the real physical coordinates of these points. Definitely, you use motorized movement, from the printer menu, so that software knows motor positions. From this data it is possible to calculate the transformation matrix of a particular printer. A coordinated movements would be corrected by this matix, i.e. basically by multipling the XYZ vector bay the 3x3 matrix.

Orthogonality not very important if one prints arts, but is very important if one prints gears etc. any mechanical parts, especially, large ones.

Let me know, who is willing to implement/test such an option? Anyway, the math of the transformation I already have and would be happy to explain it to anyone. (By profession I am a physicist doing X-ray crystallography)

[MLWORKX]

In reality, each manufactured Cartesian printer has not-a-really-orthogonal axes, as this depends on how a particular unit was assembled.

I ended up re-designing the plastic part which hangs on the belt in the Y axis: I can adjust the position of the rod via 2 screws (there's a slot hole in it). As a second printer I own a Prusa i3 MK2 which has this fancy bed probe: works well but I personally would prefer my requested feature by adding a deviation angle: this 9 points also affects the XY axis angle...

[Blue-Marlin]

This FR is about the angle between X and Y because this is the only one not compensated by linear (matrix) bed levelling.

[rshayduk]

personally would prefer my requested feature by adding a deviation angle...

Yes, this is the same thing, in your case it is 2d, and things are simplified to a1=const1e1; a2=const2e2+const1e1tan(deviation). How do you measure the deviation angle?

[Blue-Marlin]

More thoughts about this in #4904, #3014, #5116

[rshayduk]

I see that everything have been discussed already. However, after reading the #5116 I have got a feeling that some people mix the bed leveling/orientation problem and the problem of a Cartesian printer axes orthogonality calibration, but may be I am wrong. Thank you for the shortcuts on the topic.

[boelle]

@thinkyhead

since josef prusa has done the work should we not include this in the 1.1.1 milestone?

https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/mesh_bed_calibration.cpp

[github-actions[bot]]

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.