Mesh Bed Leveling is creating inconsistent Meshs until restore to Default

[Sersch97]

Description

Mesh Leveling is inconsistent. Sometimes - not always when Mesh is created, it is completely random leading to incorrect first layer.

If i then, go to control and restore to default and then create a new mesh, i get a correct one that i can then reproduce with a new mesh.

I know that the bed isn't leveled good. But i wanted to just mention that bug.

Steps to Reproduce

1. [First Step]: I don't know what is causing that bug, but i have the feeling its happening if the printer is turned on for a long time doing nothing and after hours just gets a printjob - or after a long printjob starting the next with meshbedleveling.
2. [Second Step]: Check the meshbedlevelviewer and see if the mesh is hugely different or extremely random.
3. [and so on...]: Restore Defaults and try again. The Mesh should now be correct or atleast less random and repeating creating mesh results in the same or close to same mesh.

Expected behavior: [What you expect to happen] Getting in 2 mesh creating procedures, one after the other directly, the same results.

Actual behavior: [What actually happens] Getting everytime completetly different results and even so hard random ones that aren't possible at all. like nearly 2mm difference between one box to the next one.

Additional Information

Additional information that i checked to see if it is not hardware:

tested z probing /homing several times and getting (from the feeling atleast) everytime the same space to the bed. --> i think i tested if the BLT measures always about the same values when probing and not random ones.

I checked the cables for the BLT

I also used an older firmware from you where i didn't have that bug, but the menu for the leveling was more simple aswell.

[Jyers]

My best guess would be a hardware issue of some kind. Mostly due to the fact that there is nothing in the firmware that could lead to such randomness, it handles leveling the same as any other marlin based firmware. You could try the probe repeatability test from the probe menu to see if that helps, and make sure there is no play in your y axis rollers.

[Sersch97]

Everything is thight and stable. The thing is, that i switched out the BLT from my printer with your newest firmware with a printer that has older firmware. (both had one). And now the "faulty" BLT works properly on the printer with the older firmware and the BLT that was doing fine on the older printer seems to have the same issues now as the other one. that is one more points for me that it might me something firmware related. Also as i said, i checked, as i do before every long print, the belts and the rollers. Also the z axsis is moving fine and is not losing any steps or is dropping down if you consider that. If i just restore everything to default i can then recreate the same mesh over and over again, but after a longer print when starting a new one, it then suddenly creates a weird mesh and that everytime random. so no "wrong" mesh is the same as the previous one.

i really dont know how to deliver you more information. I just want to help you if someone might have the same issue that you might think auf this case here and then you could tell them to try out older firmware from you maybe? I will try to downgrade the firmware to the older one on the "faulty" printer and will then write an update if that solved the issue for me.

if you know what information to ask for, do that. i will try to give it to you then :)

[Jyers]

Okay, now that's definitely interesting. For sure get back to me about how it performs on an older firmware version. If it turns out to be firmware related the only thing I can do would be to pull the latest Marlin source in the case it's been fixed upstream. Because as I said, leveling is handled just on the marlin side, I don't do anything to modify it.

[MichaelSMVogel]

There might be something else going on - Sersch97 is switching BLTouch probes between printers. So the Error is not in the Probe but might be in the printer itself via the grounding issue some but not all ender3v2s experience. Noisy signals could explain that better than firmware. To refute it, he would have to flash the old firmware to the printer that currently misbehaves.

[Sersch97]

i actually have grounded my printers properly before already. i will flash the old firmware as soon as possible but until the end of this week i have to study for an examen. Next week i'll give a proper update guys

[smooreace]

I don't have another printer to compare against, but I'm kinda seeing a similar situation. I was having a hell of a time getting my close to level after beefing it up to 400x400x500. No matter what I did I couldn't get expected results from consecutive runs. For example, my first mesh would show 0,400 to be 1mm high. I would tighten the back left adjustment half a turn and test again. Now magically my back right corner would show .5mm lower than the prior test, and 0,400 would now be 1.2mm low.

That means that the right went DOWN by lowering the left. And the left somehow dropped a whopping 2.2mm from half a turn! Test again because that is clearly not possible and now the 0,0 position is half a mm lower... without touching anything.

The only way I could get results that made any sense at all was to power cycle the printer, heat it back up, reset the memory, and test.... adjust, and repeat

[araziforum]

Mesh bed leveling not active after update. I try to active it and store settings than power off, after power on mesh bed leveling check clearing again. What can I do

[smooreace]

The check box youre talking about has no effect on what you're wanting. Add the M420 S1 line to the end of you start gcode in Cure or whatever you use and you're in business. You will still have to verify that your z-offset is set properly though

On Fri, Jun 25, 2021 at 4:13 PM araziforum @.***> wrote:

Mesh bed leveling not active after update. I try to active it and store settings than power off, after power on mesh bed leveling check clearing again. What can I do

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Jyers/Marlin/issues/1036#issuecomment-868836453, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4QZ7QHOROZHVN7TR7HDTUTWQFANCNFSM47AFRPXQ .

[Sersch97]

Okay so i did a downgrade in firmware on the 3d printer and the issue has been solved that way. this leads me to say that it has to be firmware related. as i dont want to restore all my settings every second print i am going to stick with that version of marlin for now. To sum up: I checked if everything was tight but not too much i checkd if everything was grounded correctly i checked if the BLT is faulty or the cable from it is still good/sitting correct i swapped the BLT between printers and only the printer with the newer firmware had the issue i downgraded the firmware back to my older one and it worked then as is should without issues. i guess thats it.

[araziforum]

The check box youre talking about has no effect on what you're wanting. Add the M420 S1 line to the end of you start gcode in Cure or whatever you use and you're in business. You will still have to verify that your z-offset is set properly though … On Fri, Jun 25, 2021 at 4:13 PM araziforum @.***> wrote: Mesh bed leveling not active after update. I try to active it and store settings than power off, after power on mesh bed leveling check clearing again. What can I do — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1036 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIPE4QZ7QHOROZHVN7TR7HDTUTWQFANCNFSM47AFRPXQ .

I'm using 3x3 manual mesh firmware. which code is suitable for manual mesh? M420 S1 or G29

[Jyers]

@araziforum M420 S1 is what you want from Manual Mesh

[Jyers]

@Sersch97 What firmware version did you downgrade to? I'll look into the differences to see if there is anything I can decipher

[smooreace]

I mentioned M420 S1 2 days ago

[Jyers]

@smooreace I know, I was just answering @araziforum's question

[Sersch97]

@Jyers it says 1.2.2 in the name. i hope thats what you want to know ^^

[grilparto]

Just to add another datapoint here. I'm encountering a similar (same?) issue although I can't seem to figure out how I managed to make it occur. In my case I'm using ABL Bilinear and generating a 3x3 mesh. The FW version is slightly modified for my printer, but based on 1.3.4. I also compiled in the updates being worked on for probe assisted tramming.

In my case, the first time I flashed it, I noticed that the right side of my mesh was insanely low (squishing into the bed) with negative z values. Spent a great deal of time leveling manually and whatnot. I ended up thinking it could be related to my PROBING_MARGIN (default I had 10, I set it to 20 now). Also had some issues with my BLTouch flashing red (this isn't new) and found from other discussions on here that it might be better to plug that in to the plug for the Z end stop instead (and enable #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN). Point is, I recompiled and re-flashed the firmware and for added bonus, I Reset to Defaults this time after flashing. Did my tramming, created a mesh. All that looked pretty good. I had positive z-values too at this point, but figured it was just due to the tramming adjustments. Test print came out shitty though, but I that's only because I forgot to add in the proper steps (again) for my new BMG extruder into the firmware. No biggie. Set all that. Seemed like the print went ok but my Z-offset needed to come down -0.1mm...which is odd because it really shouldn't change. Took care of that.

Now at some point between making those adjustments (I wasn't paying 100% attention here, can't recall if I'd done anything else) I did another test print, which re-probed the mesh (G29 is in my starting GCode). I'd added an M420 V to my Gcode so I could see the mesh output after G29 finished. Suddenly the 3 mesh points on the right were negative again and the test print mashed those areas into the bed. Re-probed the mesh. Same thing. Tried to see if there were any adjustments I ought to make, re-probed, re-probed again, same mesh came up (give or take a couple 0.001mm). I tried to test the areas manually and they were, as you'd expect, too low.

Well after figuratively bashing my head and blowing my 3D printed Aztec Death Whistle a few times, I came across this bug and gave it a shot. Before doing anything, I re-probed the mesh. Still came out with negative values for the 3 points on the right side. I Reset to Defaults and re-probed the mesh. Lone behold, the negative values now became positive values.

Re-probe before Reset to Defaults

Re-probe after Reset to Defaults

Regarding the "bad mesh", it almost feels like the problem is that the firmware took the "good mesh" and said hey, subtract something like 0.2 or 0.24 from each of the right-hand probing points. @Sersch97's mesh doesn't entirely seem to exhibit that same problem. Their right-hand side seems off by about 0.2 but the other points on the mesh are clearly off whereas mine stayed pretty close. I'm using a 3x3 though, so maybe that could've factored into it.

[grilparto]

Well damn if it didn't just happen again as I started a print. Different behavior this time though (instead of just the right-side of the mesh being impacted).

For reference, I have my starting G-Code like this for troubleshooting right now: M420 V G28 ; home all axes M420 V G29 M420 V

So it should report the mesh before homing, after homing, and after a new round of probing. Essentially: what it was, what it is after homing (sanity check, it should be exactly the same), and what it is after probing (should be roughly the same). Here are the only steps I performed between my last post and this post. I immediately wrote up my previous message after resetting to defaults and re-probing so we're talking 10-15 minutes tops that the printer sat there while I wrote all that up. Here are the only other steps I took before running over to write up that last post:

• After re-probing the mesh successfully:
• I issued went to Control > Motion > Steps/mm and did:
• X=82 Z=409 and Extruder=413.5 (this is specific for my printer given the BMG extruder and some adjustments based on dial gauge measurements).
• Saved Settings.
• Came over to my PC to write my last post.

After submitting the post, I started a calibration print and the mesh went to hell. Here's the terminal output.

The first M420 is issued:

Send: N9 M420 V90 Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.030 -0.000 +0.043 Recv: 1 -0.045 +0.002 +0.033 Recv: 2 +0.071 +0.103 +0.111 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok Send: N10 G2834 [...] Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly [...] G28 Homing performed Recv: X:155.00 Y:119.30 Z:12.81 E:0.00 Count X:12710 Y:9544 Z:5239 Recv: ok Send: N11 M73 P0103 Recv: ok Send: N12 M113 S282 Recv: ok

Second M420 (after homing)

Send: N13 M420 V*97 Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.030 -0.000 +0.043 Recv: 1 -0.045 +0.002 +0.033 Recv: 2 +0.071 +0.103 +0.111 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok

G29 performed

Send: N14 G29*39 [...] Recv: //action:notification Printing... [...]

This is just the output after G29 was done. Note the unusual change in the mesh.

Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 +0.066 +0.225 +0.158 Recv: 1 +0.755 +0.642 +0.296 Recv: 2 +1.043 +1.241 +1.178 Recv: Recv: X:230.00 Y:214.30 Z:12.81 E:0.00 Count X:18860 Y:17144 Z:5239 Recv: ok

The third M420 is issued, showing the same mesh that was output by G29.

Send: N15 M420 V*103 Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 +0.066 +0.225 +0.158 Recv: 1 +0.755 +0.642 +0.296 Recv: 2 +1.043 +1.241 +1.178 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok

Wondering if this just has to do with saving to the EEPROM after making the mesh or something.

EDIT: In spite of the positive Z offsets the mesh had there, for some reason the dang thing gouged the heck out of my bed. No idea what that's about. That's a new one.

[chrisneal]

I’m having a similar issue (1.3.4). I have to reset the EPROM pretty much before every print. My starting GCODE is:

G28 G29 L0 G29 J

I have a feeling for me it’s something to do with the auto tilt.

[Tuncay-Ayhan]

Just to be sure… Are you heating your bed to print temperature when you are creating the mesh?

Op di 29 jun. 2021 om 21:42 schreef grilparto @.***>

Well damn if it didn't just happen again as I started a print. Different behavior this time though (instead of just the right-side of the mesh being impacted).

For reference, I have my starting G-Code like this for troubleshooting right now: M420 V G28 ; home all axes M420 V G29 M420 V

So it should report the mesh before homing, after homing, and after a new round of probing. Essentially: what it was, what it is after homing (sanity check, it should be exactly the same), and what it is after probing (should be roughly the same). Here are the only steps I performed between my last post and this post. I immediately wrote up my previous message after resetting to defaults and re-probing so we're talking 10-15 minutes tops that the printer sat there while I wrote all that up. Here are the only other steps I took before running over to write up that last post:

• After re-probing the mesh successfully, I issued M92 E413.5, M92 X82, and M92 Z409.
• I issued M500 to save the changes to EEPROM.
• Came over to my PC to write my last post.

After submitting the post, I started a calibration print and the mesh went to hell. Here's the terminal output.

The first M420 is issued:

Send: N9 M420 V

90 Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.030 -0.000 +0.043 Recv: 1 -0.045 +0.002 +0.033 Recv: 2 +0.071 +0.103 +0.111 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok Send: N10 G28 34 [...] Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly [...] G28 Homing performed Recv: X:155.00 Y:119.30 Z:12.81 E:0.00 Count X:12710 Y:9544 Z:5239 Recv: ok Send: N11 M73 P0

103 Recv: ok Send: N12 M113 S282 Recv: ok

Second M420 (after homing)

Send: N13 M420 V*97 Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 -0.030 -0.000 +0.043 Recv: 1 -0.045 +0.002 +0.033 Recv: 2 +0.071 +0.103 +0.111 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok

G29 performed

Send: N14 G29*39 [...] Recv: //action:notification Printing... [...]

This is just the output after G29 was done. Note the unusual change in the mesh.

Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 +0.066 +0.225 +0.158 Recv: 1 +0.755 +0.642 +0.296 Recv: 2 +1.043 +1.241 +1.178 Recv: Recv: X:230.00 Y:214.30 Z:12.81 E:0.00 Count X:18860 Y:17144 Z:5239 Recv: ok

The third M420 is issued, showing the same mesh that was output by G29.

Send: N15 M420 V*103 Recv: Bilinear Leveling Grid: Recv: 0 1 2 Recv: 0 +0.066 +0.225 +0.158 Recv: 1 +0.755 +0.642 +0.296 Recv: 2 +1.043 +1.241 +1.178 Recv: Recv: echo:Bed Leveling ON Recv: echo:Fade Height 10.00 Recv: ok

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Jyers/Marlin/issues/1036#issuecomment-870865265, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGXIODIHCUFPZ25473HKTT3TVIO3LANCNFSM47AFRPXQ .

[grilparto]

Just to be sure… Are you heating your bed to print temperature when you are creating the mesh? Op di 29 jun. 2021 om 21:42 schreef grilparto @.***>

I am. I've also enabled #define PREHEAT_BEFORE_PROBING with a nozzle temp of 160C and bed temp of 60C so it'll pre-heat the bed before homing, probing, etc without me needing to remember.

[grilparto]

Did some additional testing this afternoon. The following seemed to create a wrong mesh after re-probing:

• From the LCD, adjusting the X, Y, Z or E steps (storing the settings was not necessary).
• From the terminal (OctoPrint), M92 on X, Y, Z, or E (no M500 required).
• From the terminal, M841 Z-2 (changing Z offset, no M500 required). That actually seemed to have a massive impact.

This command did not seem to have an impact:

• From the terminal, M900 K0.66 (no M500 required).

I stopped testing settings changes at this point. Something seriously wrong here if I can't change the offset or step settings without it screwing up the probing. I'll try to figure out if I can track it down to a release or something I added to a release, but I have a lot more variables to go through than someone using the compiled BLTouch 3x3 HS firmware (I have linear advance, and I tossed in the commits for the probe tramming too).

[chaos4eva]

Unsure if this will help but after a week of pulling my hair out regarding mesh and it changing to something inconsistent when running prints once tilt probing has completed I worked out that after homing all axis I was setting that as home position which was the center of the bed. Go figure when the menu said home all axis I assumed once it did its things selecting the set home was correct. I worked out something was weird when I tried manual levelling and selecting center ended up moving head to top right and bottom some random place in the middle. I think this freaked the mesh out as the location of the head was not where it was expecting it so mesh compensation was all over the place.

So from the print menu I ensured to home X and Y axis so the head is at the bottom left of the bed and then selected set home position.

Re did all the create mesh again at the appropriate bed temps and jobs a good one.

Hopefully this will be of some help.

[grilparto]

Alright, adding some clarity here. Think I mentioned before I was on 1.3.4 with some added commits. To be specific let's say I'm working from compiling this commit: https://github.com/Jyers/Marlin/tree/33cc526e7f69c1f00710df8cd206aba792bc1f0e . There are some modifications in there that need to happen for the Voxelab Aquila, but nothing ground breaking beyond one or two things in the Configuration.h. Also enabled Linear Advance.

To begin my walk backwards, I reverted to the commit for 1.3.4 w/ the configs needed for the Aquila and Linear Advance enabled. So essentially, I rolled back the commits for fixing the Mesh Slot issue and the added probe assisted tramming. Had the same issue. I'll try 1.3.3 later.

[grilparto]

Moving back to 1.3.3 didn't work out (same issue). Tried to go back to 1.3.1 but failed to compile. I haven't been able to sort out why but I'm also working on another theory. I was previously using 1.3.4 with a UBL 15x15 mesh. I'm curious if the EEPROM still has that mesh saved in it, and if it's possibly the culprit here. I think the idea would be to re-flash the UBL firmware I was working with and then wipe out the mesh, load up the 3x3 ABL Bilinear firmware again, and see what happens.

EDIT:

And weak, that didn't work out either. Loaded up the 15x15 UBL firmware, loaded the mesh (it was still in EEPROM), cleared it, saved it, flashed the 3x3 ABL Bilinear firmware I was working with again and no such luck. Problem persists. Think I've about had it tonight. Didn't have the issue with UBL, so I might play with a 3x3 UBL grid tonight to see if I get the same issues. Beyond that, I don't know. I guess I could try walking back the Linear Advance mod I made. Has to be something with my system or somehow I performed a magic series of steps that put my system into a state where this is a problem. Otherwise you'd think everyone using this firmware would be having BLTouch issues with Bilinear.

[chaos4eva]

Select Home X and Home Y and click Set Home Position then redo mesh. Don't do home all like I did as that what made my mesh change all over when tilt probing was completed.

That's what worked for me.

[Jyers]

@chaos4eva You don't need to use set home position at all, that option is only really useful for laser users. All you need to do is select home all, then you're machine will be homed correctly

[chaos4eva]

As I said above if you do my mistake of selecting Home All and then select Set Home Position it sets to centre of the bed. This for example then makes Manual Level bed positions totally out of place, ie Bottom Left moves head to Centre and so on, coincidence or not this skewed my bed mesh when tilt probe was made.

[grilparto]

Man, this just gets worse. I'm having the same problems with UBL too apparently. Not sure I would've noticed it with the 15x15 gird I was using in the past but it's exactly the same behavior using a 3x3 grid. Seems like doing anything M92 or M851 related messes up the mesh next time you probe it. Here's what I tried with a 3x3 UBL today:

• Created a mesh (came out fairly accurate).
• At the LCD, I changed the X steps/mm from 82 to 80.
• At the LCD, I changed the Z-offset from -2.79 to -2.5.
• Created the mesh again.

Came up with a different mesh that was totally not accurate.

EDIT: Hey @alexqzd, I might need an Aquila buddy to help confirm that I'm not crazy here (or maybe to see if this is Aquila specific). I just tried your v.1.3.4 firmware to remove my configuration/compiling from the equation and still encountered the problem we're describing here. For reference I tried BLTouch-3x3-HS.bin. Same steps in this post essentially. Probed the bed, made changes to the steps and/or the Z-offset, re-probed the bed, came up with entirely different results. Just to be clear if I make NO changes to the steps or Z-offset I can re-probe the bed just fine. If I Reset to Defaults, I can re-probe the bed just fine.

[grilparto]

As I said above if you do my mistake of selecting Home All and then select Set Home Position it sets to centre of the bed. This for example then makes Manual Level bed positions totally out of place, ie Bottom Left moves head to Centre and so on, coincidence or not this skewed my bed mesh when tilt probe was made.

Just for reference, I think you may be describing a separate problem that I haven't encountered. If I try to manually adjust the mesh, the nozzle positions are where I expect them to be. All the same, I did try another series of steps (same as my previous post) where I did a Home X and Home Y, followed by a "Set Home Position" prior to trying to create the mesh again. It didn't change the outcome, still came up with a bad mesh.

[grilparto]

Sorry for all the added replies on this with the added testing. Using a 10x10 UBL configuration now. Tried to see if there was an impact on autotilt and discovered changing the steps/mm for the x,y,z tripped up the autotilt in a similar fashion. Restoring defaults, loading the mesh, and tilting it gave consistent results again. Maybe that's something that should be expected since you're changing characteristics of the motion.

The behavior though is making me question what I thought I saw in one of my previous replies. When trying to goof up the autotilt, I wasn't able to cause a problem when adjusting the Extruder steps/mm or the Z-Offset. I'll probably go back and re-test tomorrow, but I want to print some stuff.

I also noticed I'd said:

• From the terminal, M841 Z-2 (changing Z offset, no M500 required). That actually seemed to have a massive impact.

I probably meant M851. Don't think M841 does anything at all.

My workaround for now would be to compile the firmware with any steps/mm calibrations and the necessary z-offset and just Restore Defaults if a change is accidentally made to those values or if another adjustment is found to trip it up.

[Tw0bit]

I appear to have the same issue on 1.3.2 and test 1.3.4 (10x10 UBL) on a Ender 3 V2 4.2.2 board. If I reprobe directly afterwards the mesh varies.

I have striped and rebuilt several times, everything is correct even the Z steps checked over several meters of movement. X Gantry is level, Y-axis/carriage is level.

I have tried to also: manually levelled the bed with the paper (5 locations), then probed the bed, adjusted the mesh using the paper method, did a bed level print, it auto tilts (3 points) and not level AND tried to reprobe and not tilt

[Tw0bit]

I cannot pin it down, but the mesh appears to be acting weird. I though a mechanical issue and even swapped the BLTouch probe.

Before doing anything Reset to Defaults.

1. Create a new mesh - done
2. View the mesh/take a picture of it for reference - done 2a. Repeated the Mesh 3 times - identical (within 0.01) meshes 3 times 3.Change the steps/mm of one of the axis under Configure -> Motion -> Steps/mm. - I changed E=88.5 and Z=401.5. I also set Z-offset to -3.00 3a. Create a new mesh again - I got the same identical mesh as in 2 3b. Repeated the Mesh 3 times - again identical all three times, which were identical to the 2a.

When I went to print though, the mesh is reprobed (G29) and then it didnt look the same (the trigger points 5mm+Zoffset) and printed wrong.

The bed was not leveled but the worse was -0.14 and +0.11 in my testing. I have the 1.3.4 BLTouch 3x3 HS firmware.

[dwery]

The need to change steps/mm on the Z axis might be an indication of issues with the gantry/alignment. The gear ratio is fixed, there should be no need to change it.

[Tw0bit]

The need to change steps/mm on the Z axis might be an indication of issues with the gantry/alignment. The gear ratio is fixed, there should be no need to change it.

I only edited it to test a change to the steps. My machine runs defaults.

[Jyers]

I'm going to close this for now as it doesn't seem to be linked to this fork specifically. If someone does make an issue upstream regarding this feel free to link this so be can pass on any information gathered.