Skew Correction doesn't work with UBL

[PolloPequeno]

I've been testing out the Skew correction update and cannot get any noticeable correction when I use the M852 SX.XX command. The Z correction is turned off. I tried it a bunch of different ways without any meaningful change.

On a side note, the big fixes since the beginning of Nov made a noticeable improvement to how my printer is running. Thanks!

---

Bug Report

• Description: M582 doesn't have any effect
• Expected behaviour: By changing the value of M582 SX.XX I should arrive at a value that corrects for the XY skew on my machine (i.e. the measurements of AD and BC should be the "same")
• Actual behaviour:

For my testing I used the thingiverse file, mentioned in the config file. After trying it out with my calculated skew value of -.01 and not seeing any change, I switched to -.05 for further testing. Playing around with the inputs, a correction factor of -.05 is roughly a correction factor for +8mm length on the BD diagonal compared to the AC one. Certainly a large enough "correction" to detect a change. My printer is naturally skewed as the graphic in the config illustrates.

All the tests below show no meaningful change compared to the test print prior to using M852.

• Setting it via Simplify3d's machine control panel (on a side note if I enter an extreme value say S1.0, then G28, it homes X then moves very near to the end of the other side and completes the Y and Z homing, if I again issue a G28, it homes as normal.)

• Reversing the sign of the correction factor (say from -.05 to .05). Just to check if for some reason that would have an effect,

• Adding the M852 to the gcode file, before homing/after homing/After M420 S1. Normally at the beginning of my gocde file I have:
  G28
  M420 S1

• I tried it once via config file by giving it the AD, BC, and AD dimensions, it didn't appear to work, but given the iterative nature of tuning a 3DP, I wanted to avoid the time intensive process of updating the config file, uploading it, getting the hotend and bed up to temp, rerunning UBL, and so on. I did set AB,BC,AD all to 0 in the config once I decided to do my testing with the M852 command.

Let me know if there are any additional variations you would like me to test.

Thank you!

Configuration.zip

[thinkyhead]

The problem is that this feature isn't compatible with Unified Bed Leveling in its standard mode. When we move more of UBL's leveling logic into the Planner with the other leveling code then it will work.

But there is a workaround. In the latest bugfix-1.1.x configuration files there is an option SEGMENT_LEVELED_MOVES that should make UBL call the Planner for leveling. Add this to your configuration and skew should start to work.

  #if ENABLED(MESH_BED_LEVELING) || ENABLED(AUTO_BED_LEVELING_BILINEAR) || ENABLED(AUTO_BED_LEVELING_UBL)
    // Gradually reduce leveling correction until a set height is reached,
    // at which point movement will be level to the machine's XY plane.
    // The height can be set with M420 Z<height>
    #define ENABLE_LEVELING_FADE_HEIGHT

+   // For Cartesian machines, instead of dividing moves on mesh boundaries,
+   // split up moves into short segments like a Delta.
+   #define SEGMENT_LEVELED_MOVES
+   #define LEVELED_SEGMENT_LENGTH 5.0 // (mm) Length of all segments (except the last one)
+
    /**
     * Enable the G26 Mesh Validation Pattern tool.
     */
    //#define G26_MESH_VALIDATION   // Enable G26 mesh validation
    #if ENABLED(G26_MESH_VALIDATION)
      #define MESH_TEST_NOZZLE_SIZE     0.4   // (mm) Diameter of primary nozzle.
      #define MESH_TEST_LAYER_HEIGHT    0.2   // (mm) Default layer height for the G26 Mesh Validation Tool.
      #define MESH_TEST_HOTEND_TEMP   205.0   // (°C) Default nozzle temperature for the G26 Mesh Validation Tool.
      #define MESH_TEST_BED_TEMP       60.0   // (°C) Default bed temperature for the G26 Mesh Validation Tool.
    #endif

  #endif

[PolloPequeno]

Something very weird is happening now. Please see #8638.

On a side note, I did try using #define SEGMENT_LEVELED_MOVES with the code I pulled from Dec 2 and the Skew correction did not appear to work, although I only got one test print in before I tried the Dec 3rd updates and had the problem I described in the linked issue.

Let me know if there is anything I can do to help out with this.

[PolloPequeno]

I did some more testing and Skew doesn't work even if SEGMENT_LEVELED_MOVES is enabled. I looked back through the commits and it didn't look like the split moves revert should have effected this, as I see it various files. But I could be wrong about that. Please let me know.

Thank you and good luck with those split move gremlins!

[thinkyhead]

I think we might have gotten those gremlins. So we should take another look at the skew behavior.

So, you don't see any skew compensation at all, even with leveling off? Even with leveling off the Planner::apply_leveling function should do this much:

#if ENABLED(SKEW_CORRECTION)
  if (WITHIN(rx, X_MIN_POS + 1, X_MAX_POS) && WITHIN(ry, Y_MIN_POS + 1, Y_MAX_POS)) {
    const float tempry = ry - (rz * planner.yz_skew_factor),
                temprx = rx - (ry * planner.xy_skew_factor) - (rz * (planner.xz_skew_factor - (planner.xy_skew_factor * planner.yz_skew_factor)));
    if (WITHIN(temprx, X_MIN_POS, X_MAX_POS) && WITHIN(tempry, Y_MIN_POS, Y_MAX_POS)) {
      rx = temprx;
      ry = tempry;
    }
    else
      SERIAL_ECHOLN(MSG_SKEW_WARN);
  }
#endif

You might try sticking an #error "Hey!" line after #if ENABLED(SKEW_CORRECTION) to make sure that code is definitely being included. Meanwhile, I will test with your configurations. Are they still the same as when you first posted?

[PolloPequeno]

I think we might have gotten those gremlins.

Happy to hear to hear that

I haven't tried it with UBL turned off. Let me fire up the printer and I'll get back to you. Thanks!

The configs I posted haven't changed, except for the segment line option.

[PolloPequeno]

Confirmed that code is being included via #error "Hey!"

[PolloPequeno]

Marlin won't compile with Skew turned on and UBL off, so I used M420 S0 to turn it off and did some test prints.

Unfortunately, no change. I did notice that if I gave a large skew value (e.g. -.1) the whole print was shifted on the x axis, but the actual print itself measured no difference compared to skew being off. Maybe there's an issue with it not reading the Y position?

Let me know if there are other print variations I should try.

[thinkyhead]

I've fixed Marlin so it can compile skew without any form of leveling enabled. I'll do some testing tonight and see what's going on.

[PolloPequeno]

I did some testing with leveling disabled and I'm happy to report skew correction is working.

[thinkyhead]

Good to hear it! I thought it might be working today, as my latest tests showed it to be so.