search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.23k stars 19.22k forks source link

[BUG] G35 ASSISTED_TRAMMING does not result in a level bed. One or more corners lower than the rest. #23363

Closed Stephen-Bartel closed 2 years ago

Stephen-Bartel commented 2 years ago

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

I was issuing the G35 command from Pronterface. My intention was to level my bed using the bed knobs using my 3DTouch.

After the G35 command was made, Pronterface printed out the adjustments that I needed to make to 3 of the corners. I repeated this process of issuing the G35 command until the 3 corners were quite level. I determined it was level when the output of G35 indicated an output for each corner of 0.0 or around there, such as +/1 0.01, or +/- 0.02 at most.

After doing this, I created a mesh of my bed using G29. I then copy and pasted the Mesh values from Pronterface to a visualizer website (https://i.chillrain.com/index.php/3d-printer-auto-bed-leveling-mesh-visualizer/). This indicated that my bed was not level. More specifically the right side is lower than the left side.

I have tried changing the reference point. The reference point is the first point that is measured and all other points are compared to and adjusted according to this reference point. I have changed the point coordinates as well. I used the default. I also used the coordinates : (45,35), (190,35),(45,200),(190,200).

It is strange that G29 is able to indicate and measure that the right side of the bed is lower than the left. With the same probe and surface, and therefore, same measurements, I don't understand why G35 does not tell me to adjust properly. Because clearly, the firmware, G29, and 3DTouch are able to indicate that the right side is lower.

Bug Timeline

No response

Expected behavior

I expected the bed to be perfectly or acceptably level once the G35 command would indicate a value of 0.0 or close to it, at each corner.

Actual behavior

After the G35 command would should a value of 0.0 or close to it at each corner, the bed was not level and was slanted. newplot (4) PronterfaceOutput newplot (5)

Steps to Reproduce

  1. Connect Pronterface to printer
  2. Issue G35 command to start Assisted Tramming
  3. Adjust the bed knobs on the 3D printer based on the values and instructions provided by G35
  4. Repeat 2. and 3. until the output of G35 is exactly or close to 0.0

Version of Marlin Firmware

Marlin 2.0.9.2

Printer model

Creality Ender 3 V1

Electronics

Creality 4.2.2 board

Add-ons

3DTouch, Creality Glass Plate, Yellow bed springs

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

Pronterface

Additional information & file uploads

Configuration_Files.zip newplot (5)

My 3DTouch seems to be quite accurate. Here are the results of the M48 Probe Accuracy Test. RepeatabilityTest

borland1 commented 2 years ago

In your Configuration.h file, you have enabled an LCD menu to level the bed corners, with ...

#define LEVEL_BED_CORNERS

Use that Level Bed Corners LCD menu to manually adjust the bed corner leveling knobs so the four corners are the same distance between the the nozzle and the print surface.

You need to have the corners leveled first before setting up the probed mesh using automated bed leveling. The bed mesh probing will compensate for any warping of the bed.

Stephen-Bartel commented 2 years ago

In your Configuration.h file, you have enabled an LCD menu to level the bed corners, with ...

#define LEVEL_BED_CORNERS

Use that Level Bed Corners LCD menu to manually adjust the bed corner leveling knobs so the four corners are the same distance between the the nozzle and the print surface.

You need to have the corners leveled first before setting up the probed mesh using automated bed leveling. The bed mesh probing will compensate for any warping of the bed.

Thanks for replying.

Yes, that is what I am doing with G35 : to make the bed level with the X-axis gantry using the knobs. However, the feature that you are describing is giving inaccurate results. It says it is level, when it is not, as seen in my Mesh that I posted above.

What I am saying is that the probe and firmware are able to successfully detect that the bed is not level when using G29. It clearly detects that there are higher and lower points. So why is G35 and ASSISTED_TRAMMING not detecting it the same way and indicating the correct bed adjustments to make?

As you see in my mesh, the bed is not level, but G35 and ASSISTED_TRAMMING says that it is level. This is why I think it is a bug.

Please read through my post again and you will understand what I am saying.

borland1 commented 2 years ago

OK, Sorry if I didn't understand, but I have only used the Level Corners LCD menu on my printer with manual mesh bed leveling (no probe) using a paper sheet as gauge between the print bed and nozzle.

I would suggest you make sure your X-gantry is square with the printer frame. The Assisted Tramming feature cannot measure how square the X gantry is. You can't adjust the frame, but can adjust the X gantry aluminum extrusion where it is attached to the rollers on both sides. Use a carpenter's square or measure with a stainless steel ruler to do the measurement and to verify the adjustment. You may need to partially disassemble the printer to make this adjustment, at least that is the case with my Tronxy XY-2 Pro.

Once you have the X gantry square with the frame, then the Assisted Tramming feature should provide correct results. If not, then you have a better case for validating a firmware bug.

Stephen-Bartel commented 2 years ago

OK, Sorry if I didn't understand, but I have only used the Level Corners LCD menu on my printer with manual mesh bed leveling (no probe) using a paper sheet as gauge between the print bed and nozzle.

I would suggest you make sure your X-gantry is square with the printer frame. The Assisted Tramming feature cannot measure how square the X gantry is. You can't adjust the frame, but can adjust the X gantry aluminum extrusion where it is attached to the rollers on both sides. Use a carpenter's square or measure with a stainless steel ruler to do the measurement and to verify the adjustment. You may need to partially disassemble the printer to make this adjustment, at least that is the case with my Tronxy XY-2 Pro.

Once you have the X gantry square with the frame, then the Assisted Tramming feature should provide correct results. If not, then you have a better case for validating a firmware bug.

Thanks.

Yes I actually completely disassembled my printer and then fully reassembled it.

Others have said the same, which is to ensure that the x-axis gantry is square and level. Initially, it was off. That is, the left side of the gantry which has the lead screw was lower than the right side by about 1.89mm. I then adjusted the x-axis gantry. Now, the difference between the right and left side, according to my digital caliper, is 0.11mm. So the x-axis gantry is now very even and level. There is a very minor difference between the left and right side.

As I showed in my post, when I was done using G35, the G35 ASSISTED_TRAMMING was showing the front-right and back-right as being 0.01 mm within the points on the left side. However, the same probe indicates that it is significantly lower when using G29. It is definitely not within 0.01 mm.

To me, it seems very clear that this is a bug, because G29 is using the same probe but is providing different results than G35. They should be providing the exact same results. Why would they be different? It is the same probe, same frame, same bed measuring the exact same thing. The only reason in my mind, why G29 and G35 would be showing different results, is due to a bug.

This is why I have submitted this issue, because it seems to definitely be a bug. I can't see how there is any other explanation. I have tried many things and the problem is still there.

Stephen-Bartel commented 2 years ago

By the way, I have also talked with others, and they have also encountered the same problem I am describing.

borland1 commented 2 years ago

Did you try Assisted Tramming in both clockwise and counterclockwise modes to see if it reversed the errors and indicate lower bed on left side? That might give more weight to your bug conclusion and rule out a hardware problem.

Stephen-Bartel commented 2 years ago

Did you try Assisted Tramming in both clockwise and counterclockwise modes to see if it reversed the errors and indicate lower bed on left side? That might give more weight to your bug conclusion and rule out a hardware problem.

Thanks. Yes, the problem followed the side or corner that is the reference point. For example, if I set the reference point as a the left-front corner, than that corner would be lower than the rest. If I set the right-front corner as the reference point, than that corner would be lower.

This issue depends on the reference point that was set. I only tried the front two corners however.

Thanks for mentioning that because I actually forgot to mention how the issue is generally occurring in the quadrant that contains the reference point.

Stephen-Bartel commented 2 years ago

Any updates on this?

borland1 commented 2 years ago

In file G35.cpp, the code here looks fine to me. Assumes you have M3 threaded bed leveling screws, which can be set TRAMMING_SCREW_THREAD in Configuration_adv.h file. I didn't look at BL touch code that gets z_measured[i] value.

Marlin/Marlin/src/gcode/bedlevel/G35.cpp ...

starting at line 131

  if (!err_break) {
    const float threads_factor[] = { 0.5, 0.7, 0.8 };

    // Calculate adjusts
    LOOP_S_L_N(i, 1, G35_PROBE_COUNT) {
      const float diff = z_measured[0] - z_measured[i],
                  adjust = ABS(diff) < 0.001f ? 0 : diff / threads_factor[(screw_thread - 30) / 10];

      const int full_turns = trunc(adjust);
      const float decimal_part = adjust - float(full_turns);
      const int minutes = trunc(decimal_part * 60.0f);

      SERIAL_ECHOPGM("Turn ");
      SERIAL_ECHOPGM_P((char *)pgm_read_ptr(&tramming_point_name[i]));
      SERIAL_ECHOPGM(" ", (screw_thread & 1) == (adjust > 0) ? "CCW" : "CW", " by ", ABS(full_turns), " turns");
      if (minutes) SERIAL_ECHOPGM(" and ", ABS(minutes), " minutes");
      if (ENABLED(REPORT_TRAMMING_MM)) SERIAL_ECHOPGM(" (", -diff, "mm)");
      SERIAL_EOL();
    }
  }

Kind of strange that it expresses adjustment needed as number of full turns, plus fractional turns in analog clock hand "minutes".

Stephen-Bartel commented 2 years ago

Thanks. That looks correct to me as well.

Specifically, I am looking at this line: const float diff = z_measured[0] - z_measured[i]

It is evident that this computes the difference in height, as measured by the probe, between the first or reference point and the 3 other points.

However, again, this further emphasises how there must be an error. Somehow, the 'diff' variable is 0 or close to it when I am done with G35 tramming. However, when G29 measures the same diff, it is not 0.

The problem appears to be that the difference that is measured at a particular point, is different for G35 and G29.

Looking at my original post and the output of G29 (the red/blue bed), on the left-front side, there is a height of about -0.02. On the right-front side, there is a height of about -0.08. This corresponds to a difference of 0.06. But G35 says that the difference is 0.00 when it should recognise that the difference is in fact 0.06.

Due to this inaccuracy, the bed ends up slanted, as seen in my image, even though G35 thinks it is level.

This is why I am certain there is a bug.

Why else would G35 say there is a difference of 0.0, but G29 says there is actually a difference of 0.06?

And G29 is right, because the bed is not level when doing a test print after G35.

Is there an alternate explanation to this?

borland1 commented 2 years ago

Taking a quick guess here...

The code is using macros instead of standard C for loops. I'd need to search the Marlin repository to see how the LOOP macros are defined. Maybe the for loop macro is not collecting z_probed_height for z_measured[0] which looks to be initialized to array value of zero ..

line 110
// Probe all positions
LOOP_L_N(i, G35_PROBE_COUNT) {

instead of using this macro format...

LOOP_L_N(i, 0, G35_PROBE_COUNT) {

Stephen-Bartel commented 2 years ago

Okay, thank you.

Let me know if there is something that I can do to help.

As we already discussed, the issue follows the reference point. It is not tied to just my bed's right side.

thinkyhead commented 2 years ago

That'd have to be LOOP_S_L_N((i, 0, G35_PROBE_COUNT) but that is just equivalent to LOOP_L_N(i, G35_PROBE_COUNT).

borland1 commented 2 years ago

Stephen-Bartel,

To find any errors in the computation, you might want to try editing the G35.cpp file to have it print computational values to you PC's console.

You could do this by editing file G35.cpp on you PC to add additional code which will send them to be displayed on your console, values being used in the computation. Place them in the Calculate adjusts code section, just before the line SERIAL_EOL();

SERIAL_ECHOPGM(" z_measured[0]: ", z_measured[0], "mm, ");
SERIAL_ECHOPGM(" z_measured[0]: ", z_measured[i], "mm, ");
SERIAL_ECHOPGM(" diff: ", diff, "mm, ");
SERIAL_EOL();

Re-compile Marlin, upload, firmware to your printer, and then run the Assisted Tramming from G-code from your PC console.

Stephen-Bartel commented 2 years ago

Okay, so I have attached my modified G35.cpp file.

I then recompiled, updated my Ender 3, and ran G35 from Pronterface. Specifically, I ran G35 four times, and it produced similar results each time as shown below:

Run 1:

Turn Front-Left CCW by 0 turns and 7 minutes (0.06mm) z_measured[0]: -0.03mm,  z_measured[i]: 0.03mm,  diff: -0.06mm,
Turn Front-Right CCW by 0 turns and 9 minutes (0.08mm) z_measured[0]: -0.03mm,  z_measured[i]: 0.05mm,  diff: -0.08mm,
Turn Back-Right CW by 0 turns and 5 minutes (-0.04mm) z_measured[0]: -0.03mm,  z_measured[i]: -0.08mm,  diff: 0.04mm,

Run 2: 

Turn Front-Left CCW by 0 turns and 7 minutes (0.06mm) z_measured[0]: -0.03mm,  z_measured[i]: 0.02mm,  diff: -0.06mm,
Turn Front-Right CCW by 0 turns and 9 minutes (0.08mm) z_measured[0]: -0.03mm,  z_measured[i]: 0.05mm,  diff: -0.08mm,
Turn Back-Right CW by 0 turns and 5 minutes (-0.04mm) z_measured[0]: -0.03mm,  z_measured[i]: -0.08mm,  diff: 0.04mm,

Run 3: 

Turn Front-Left CCW by 0 turns and 6 minutes (0.06mm) z_measured[0]: -0.03mm,  z_measured[i]: 0.02mm,  diff: -0.06mm,
Turn Front-Right CCW by 0 turns and 9 minutes (0.08mm) z_measured[0]: -0.03mm,  z_measured[i]: 0.04mm,  diff: -0.08mm,
Turn Back-Right CW by 0 turns and 6 minutes (-0.06mm) z_measured[0]: -0.03mm,  z_measured[i]: -0.09mm,  diff: 0.06mm,

Run 4: 

Turn Front-Left CCW by 0 turns and 7 minutes (0.06mm) z_measured[0]: -0.04mm,  z_measured[i]: 0.02mm,  diff: -0.06mm,
Turn Front-Right CCW by 0 turns and 10 minutes (0.08mm) z_measured[0]: -0.04mm,  z_measured[i]: 0.05mm,  diff: -0.08mm,
Turn Back-Right CW by 0 turns and 5 minutes (-0.05mm) z_measured[0]: -0.04mm,  z_measured[i]: -0.08mm,  diff: 0.05mm,

It appears that everything is generally in order based on the values that are being evaluated with this printout. There are some slight inconsistencies when calculating the difference, but this is probably due to rounding.

The reference point that I am using in G35 is the back-left corner, as indicated in my Configuration_adv.h:

  #define TRAMMING_POINT_XY { { 20, 180 }, {  20, 20 }, { 180,  20 }, { 180, 180 } }

  // Define position names for probe points.
  #define TRAMMING_POINT_NAME_1 "Back-Left"
  #define TRAMMING_POINT_NAME_2 "Front-Left"
  #define TRAMMING_POINT_NAME_3 "Front-Right"
  #define TRAMMING_POINT_NAME_4 "Back-Right"

I then issued a G29 command to take a look at the differences that G29 is detecting. Here, we see that the back-left corner has a height of 0.03 approximately. This means that to compare the G29 values to G35, we must subtract the height of the back-left corner from the other corners. To that end, we have:

G29 :

Assumption : Clockwise or Counter-Clockwise is determined by looking at the knobs from the top, as if someone were standing over top of their Ender 3.

G35:

Analysis:

My current bed levelling that resulted in the above values. newplot

I then levelled my bed according to G35. Here is the output of G35 when I was done with levelling. Notice how all of the corners are reporting 0.00:

G35Result

Bed levelling mesh after completing the G35 process. Notice how now the left-front corner is no longer level. Here is the mesh:

newplot(1)

Here are the coordinates for the mesh: 

      0      1      2      3      4
 0 -0.059 -0.022 -0.047 +0.037 +0.051
 1 -0.109 -0.063 -0.073 +0.033 +0.066
 2 -0.035 -0.009 -0.054 +0.025 +0.034
 3 +0.053 +0.034 -0.049 -0.014 -0.063
 4 -0.038 +0.011 -0.018 +0.070 +0.094

Modified G35.cpp file:

G35.zip

Again, it appears that G35 is indicating that the bed is level, even though there is a difference. This time, it is the front-left corner. This is the problem : G35 is saying it is level, when now the front left corner is off.

More specifically, when considering the back-left to be the reference point, we have the following with the new levelling done with G35:

With G29:

With G35:

Analysis:

Stephen-Bartel commented 2 years ago

I have now changed the order of the G35 probing. Here is the current sequence. 

  // Define positions for probe points.
  #define TRAMMING_POINT_XY { { 180, 180 }, {  20, 20 }, { 20, 180 }, { 180,  20 } }

  // Define position names for probe points.
  #define TRAMMING_POINT_NAME_1 "Back-Right" 
  #define TRAMMING_POINT_NAME_2 "Front-Left"
  #define TRAMMING_POINT_NAME_3 "Back-Left"
  #define TRAMMING_POINT_NAME_4 "Front-Right"

As I described in my previous post, I have levelled my bed using G35. I then also included an image of the G29 bed mesh in the above post after finishing the G35 levelling. I wanted to see what the output of G35 would be if I defined the back-right corner to be the reference point, and switch up the order.

Here is the printout from Pronterface after probing the same bed with the updated probing positions. Notice how G35 still indicates that the bed is level by showing 0.00 at each of the other corners.

AnotherG35Output

I then ran G29 again, and as expected, it looks identical to the mesh I included in my previous post. Of course, the mesh is expected to be the same as the one in my previous post, since I did not modify the bed's levelling at all. Here is that mesh:

newplot(2)

Here are the coordinates for the mesh: 

      0      1      2      3      4
 0 -0.047 -0.020 -0.047 +0.039 +0.051
 1 -0.105 -0.062 -0.069 +0.041 +0.069
 2 -0.029 -0.008 -0.048 +0.025 +0.032
 3 +0.059 +0.035 -0.051 -0.012 -0.065
 4 -0.023 +0.012 -0.011 +0.076 +0.092

The purpose of this post was just to see if things are consistent when some of the coordinates are changed and if I re-run everything. And yes, it appears to be consistent. However, why is the left-front corner now lower than the rest?

Stephen-Bartel commented 2 years ago

@borland1

Did any of you have a chance to review the two posts I made above?

Is there anything else we can do, or is there a fix that can be implemented?

borland1 commented 2 years ago

Yes, I read your posts. Sorry, I don't know of a workaround yet.

Bug you're seeing might be with G29 reporting and inverted mesh utilization. Saw an interesting post on ( Bilinear Leveling Grid inverted on Y axis #23219 ) by wheelyjoe, he describes what appears to be same level problem as you're reporting.

I seem to be havign the same issue, though around the X axis, ie left-to-right inversion. It also seems to be compensating using the inverted grid, making my lows lower and my highs higher.

Was thinking you may want to try editing G29.cpp, to do similar console prints of variables.

Stephen-Bartel commented 2 years ago

Okay, thanks.

Where should I add the printout?

So, the 3DTouch or BLTouch use a reference point to measure the height at a point. That relative difference in the height is what is reported by G30, G35, G29, and other similar commands. Is there any chance there's an error there, with the reference point?

The reason I ask is because I also had a slanted bed when performing a manual levelling with G30. What G30 does is that it reports the height at a particular point (X, Y) provided in the command. To level the bed, I would run G30 at each of the corners of the bed and I would adjust the bed knobs until G30 read 0.00 at each corner of the bed. I would do many iterations and go in order through each corner, until the height was 0.00 at each corner according to G30.

Given that G30 is using the same reference point with each measurement, the bed should be perfectly level relative to the X-axis gantry (including the nozzle and 3DTouch) if each of the corners are reading 0.00 when measured by G30. However, similar to G35, when G30 read 0.00 at each corner, the bed was actually slanted to one side when viewing G29's mesh. It also resulted in inconsistent first layers, so G29 was right in saying the bed was off. For example, the left side would be higher and the right side would be lower.

Example result from this procedure manual G30 procedure:

G30_LevellingResult

I thought I would mention it, hoping that it could point us further to a solution. I would have expected my G30 procedure, like G35, to produce a level bed.

Edit

Had me thinking, would I need to do a G28 after each G30 so that I have the latest reference point? Does G28 provide the reference point for all subsequent measurements?

So perhaps I was running G30 on one corner, adjusted it, and now the reference point raised or lowered accordingly. I would need to run G28 before running G30 on the next corner, in order to update the reference point?

I thought that wouldn't be needed since again, it's all relative to a particular height, and as long as the reference point value is the same at all G30 measurements, I wouldn't see the need to run G28 after each G30 to get the latest reference point.

thinkyhead commented 2 years ago

A high side and a low side involving the X axis is a classic symptom of a twisted gantry, or something pulling the carriage out of alignment as it moves in X. Check the tightness of your belts and look very very closely at the orientation of the X carriage as it moves across the bed. You can try the new X_AXIS_TWIST_COMPENSATION feature to help determine if this is the issue.

borland1 commented 2 years ago

X_AXIS_TWIST_COMPENSATION appears to be only available for AUTO_BED_LEVELING_BILINEAR It might be interesting to see how switching to ULB or Linear Bed Leveling affects the same results.

Another consideration is how the mesh data format is presented to the Pronterface 3D Visualizer.

Stephen-Bartel commented 2 years ago

Yes. So actually, the right side of the x-axis gantry, which is the side without the Z-axis lead screw, was higher by about 2.0mm than the left side with the Z-axis lead screw.

I have since corrected the gantry tilt and it is very level (left/right within 0.2mm). I corrected it before I posted about the G35 issue. That mesh was done quite a while ago and so was that issue.

I don't want to change the topic of this post, which is about G35 not levelling the bed. I just thought I would mention it, because even if the x-axis gantry is slanted, when tramming the bed, the bed levelling should account for the slant to be parallel.

The point is that even with the uneven x-axis as indicated in the mesh, G30 is reading the same measurement with the probe, which was 0.0 at each corner. Clearly, it is not level, despite that.

If it is reading 0.0 at each corner, then the bed should be trammed in a way that it is perfectly parallel with the x-axis gantry, regardless of the imperfections in the x-axis gantry. That is what I was trying to say with the post.

Anyways, as you saw in my latest post, the left-front corner is lower than the rest even though G35 is saying it is level. I just thought these two might tie in to some extent and just wanted to mention it in case it would lead us closer to a solution.

But I would like to keep the topic on G35, which is producing uneven beds, even though it is supposed to produce a perfectly trammed bed.

edit

I think one useful observation is that the slant is opposite of what it should be. The slant that doing G30 produced, is exactly the opposite of what it should be. The high side should be on the right side, and the low side should be on the left side. Because as I mentioned, the right side was higher than the left.

thinkyhead commented 2 years ago

If you get a chance to follow the given suggestion, I would love to get a look at the results.

Stephen-Bartel commented 2 years ago

Okay, thank you for replying.

I have modified the relevant part of my firmware as follows: 

#if ENABLED(AUTO_BED_LEVELING_BILINEAR)
  // Add a calibration procedure in the Probe Offsets menu
  // to compensate for twist in the X-axis.
  #define X_AXIS_TWIST_COMPENSATION
  #if ENABLED(X_AXIS_TWIST_COMPENSATION)
    /**
     * Enable to init the Probe Z-Offset when starting the Wizard.
     * Use a height slightly above the estimated nozzle-to-probe Z offset.
     * For example, with an offset of -5, consider a starting height of -4.
     */
    #define XATC_START_Z 0.0
    #define XATC_MAX_POINTS 5             // Number of points to probe in the wizard
    #define XATC_Y_POSITION Y_CENTER      // (mm) Y position to probe
  #endif
#endif

I then went to Configuration -> Advanced Settings -> Probe Offsets -> X-Twist Wizard.

I also upgraded to 2.0.9.3 from 2.0.9.2

I made sure my bed was heated to 60C.

The height Z0 at the 5 points displayed by the wizard are as follows, going from the left (has the z-axis screw) to the right (does not have the z-axis screw).

  1. 1.53 (leftmost)
  2. 1.51
  3. 1.43
  4. 1.48
  5. 1.46 (rightmost)

Is that what you wanted to see?

thinkyhead commented 2 years ago

Is that what you wanted to see?

I wanted to see if that utility improved the results of G29 since that is evidently its purpose.

Stephen-Bartel commented 2 years ago

Okay, sounds good. Let me know if you need anything else. Thanks.

LMBernardo commented 2 years ago

This has been driving me absolutely crazy. I thought I was (and maybe I am) doing something wrong, but it's interesting that other people have this same problem. I may take some measurements later and see if I can work out what's happening here.

LMBernardo commented 2 years ago

I haven't really had time to do proper measurements, but anecdotally, I seem to be getting much better prints after tramming my bed (somewhat tediously) via repeated bed leveling and comparing the leveling meshes. I had been using Assisted Tramming. After "bed-level tramming," assisted tramming reported corner heights of 0.0, -0.2, 0.2, and 0.5 anti-clockwise from the front left corner of the bed, which was the origin. Meanwhile the leveling mesh reported roughly -0.1mm for all four corners (I think my bed is a bit warped up in the middle).

ghost commented 2 years ago

I have this exact same problem too. Bed is not level after using G35.

github-actions[bot] commented 2 years ago

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

github-actions[bot] commented 2 years ago

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.