XY angle compensation

[MLWORKX]

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.

[Blue-Marlin]

I see what you mean. Interesting concept.
Even x- an y-twist can be compensated with the matrix.
The more problematic part is finding usable parameters.
X-Y_angle error is not detectable by a z-probe. That's a parameter you have to measure and send to the machine.
I'll think about it.

[MLWORKX]

It's no must to enter a compensation angle, for non-experienced users (in Math ;-) ) it could also be like the following:
"When printing an 100mm L shaped object: how large is the light gap when measuring the 90° and is it on the corner or on the outer side?"

From my personal point of view I really don't understand why there is no way to compensate this via two bolts on only one carriage on the X or Y axis at every printer - so it has to be done via software/firmware.

[Blue-Marlin]

I'm the luck owner of an Prusa i3 lookalike - 2 nuts.

[jfpion]

the same with my prusa 2, 4 nuts to adjust to make the z travel perpendicular to the X.
but anyway , could be a nice feature for the no tunable one

[MLWORKX]

I own a Prusa i2 and two other pritners: easy whit Prusa but a nightmare with other printers: therefore a nice to have if you need to have accurate prints

[Blue-Marlin]

In the simplest case, just configurable by the Configuration_adv.h, it could look like:

@@ -125,10 +125,13 @@

 // @section extras

 //#define Z_LATE_ENABLE // Enable Z the last moment. Needed if your Z driver overheats.

+// XY_SHEAR corrects an error when the angle between x- and y- axis is not exactly 90°
+// Does not work for DELTA or SCARA
+//#define XY_SHEAR_ERROR_DEG 0.1
+
 // A single Z stepper driver is usually used to drive 2 stepper motors.
 // Uncomment this define to utilize a separate stepper driver for each Z axis motor.
 // Only a few motherboards support this, like RAMPS, which have dual extruder support (the 2nd, often unused, extruder driver is used
 // to control the 2nd Z axis stepper motor). The pins are currently only defined for a RAMPS motherboards.
 // On a RAMPS (or other 5 driver) motherboard, using this feature will limit you to using 1 extruder.

Planner.cpp

@@ -484,10 +484,15 @@ float junction_deviation = 0.1;
   void plan_buffer_line(float x, float y, float z, const float& e, float feed_rate, const uint8_t extruder)
 #else
   void plan_buffer_line(const float& x, const float& y, const float& z, const float& e, float feed_rate, const uint8_t extruder)
 #endif  // AUTO_BED_LEVELING_FEATURE
 {
+  // Apply XY_SHEAR
+  #if (XY_SHEAR_ERROR_DEG != 0) && DISABLED(DELTA) && DISABLED(SCARA)
+    static float xy_shear_factor = _sin(XY_SHEAR_ERROR_DEG * M_PI/180.0);
+    x += y * xy_shear_factor;
+  #endif
   // Calculate the buffer head after we push this byte
   int next_buffer_head = next_block_index(block_buffer_head);

   // If the buffer is full: good! That means we are well ahead of the robot.
   // Rest here until there is room in the buffer.

[Blue-Marlin]

A real implementation would additionally need:
A g-gode to change.
EEPROM support.
A right shift of [0,0,0] by max(abs(y_min*xy_shear_factor) , abs(y_max*xy_shear_factor)).
A correction of software end-stopps.
...

[thinkyhead]

If you print a single-layer grid, are the resulting grid lines visibly warped? (If you don't have a single-layer grid, I can post the OpenSCAD code here for you.)

[MLWORKX]

If you print a single-layer grid, are the resulting grid lines visibly warped?

Nope, perfecty straight: it's just an (e.g.) 90,5° angle between X and Y not a bent rod where the axis is sliding along. But thank you anyway!

[Blue-Marlin]

// Does not work for DELTA or SCARA

Why should it do that? We define endpoints of a line. The line is done by the Bresnham, based on the end points.

[jbrazio]

I do find this idea interesting, specially because it can improve print fidelity when people can't easily compensate for mechanical flaws affecting the XY plane but unfortunately this task is far out of my current knowledge of the Marlin source code so I can just upvote it. :-)

PS: IMO the mantra shall always be: try to fix mechanically and if not possible do it in software.

[MLWORKX]

IMO the mantra shall always be: try to fix mechanically and if not possible do it in software.

Definitely!
This is easy when having a machine with a pretty easy structure as on the Prusa: loosen 4 screws and it's done. But it's damn hard with all those "ready to print" printers as you have to loosen a gear and hope that you did it right. In the end also this will not solve everything and that's the reason I had the idea with compensating it via a G code at the header if you have a SLIGHT deviation on your XY angle.

[jbrazio]

I do not fancy using a special G-Code for the compensation, it will be like "black magic" hidden from most and known only by few. We should consider the XY skew a machine characteristic thus, if implemented, it shall be defined in Configuration.h or in Configuration_adv.h and be commented by default even in the example configurations.

[Blue-Marlin]

It would work also for DELTAs but adjusting other parameters, like tower angles, rod length, ... would make more sense there. I don't know enough about SCARA to make a qualified guess.

EDITED:
DELTA and SCARA do not have perpendicular x/y-axes. This error can not occur.

[jbrazio]

Thank you for your interest making Marlin better.
You should re-open this topic on MarlinFirmware/MarlinDev for proper followup from the development team. We suggest you to use the MarlinFirmware/Marlin#<topic id> markdown to link back to this original topic.

[scalez]

@jbrazio @Blue-Marlin I'd like to reopen this issue.

Take a look at: https://www.youtube.com/watch?v=rYrLT5G-a9I

Unfortunately Prusa Research hasn't been generating commits and it is forked from a very old version of Marlin (Erik Zalm days): https://github.com/prusa3d/Prusa-Firmware/releases

[MLWORKX]

Take a look at...

Wow: nice!
What we would need is an easy solution to just add a value via a M code for all the printers out there which do not have this fancy heated bed...

[thinkyhead]

@josefprusa is pretty busy these days with publicity and The Next Thing™, but supposedly we'll be coordinating some effort to get this and other improvements into Marlin in the next release, 1.1.1.

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