[BUG] auto bed leveling issue

[gokulvenkat]

hi i am using marlin as firmware for my core x y (hbot) with no issue on frame such as unparallel frame (300300300 printer)
my issue is only one side of the mesh is taken wrongly near to orgin during auto homing i tried 4-8 matrix but still starting edge of the matrix is wrong i cant print the first layer only on that edge,i am using proximity sensor for probing

here is my configuration files

My Configurations

Configuration_adv.zip

[stratodream]

Same issue from my side.
Ender 3
Skr e3 mini 1.2
Marlin bugfix 2.0.x last commit.

Z movements are not compensated.
Manual bed levelling Is necessary to have a good print.

[tatusah]

The bug description is vague and conflicting. The configs you have uploaded @gokulvenkat are for Marlin 1.1.9 with 3 point auto leveling but you mention 4-8 matrix.

Have you tried with either latest bugfix-2.0.x or Marlin 2.0.1 release? What leveling method were you actually trying to use?

[stratodream]

I have last committed bugfix- 2.0.x, skr e3 mini, originale bl touch. The z positions are not compensated. Anyway in issue #13512 there are a lot of people reporting the same issue. Could i provide more Infos? Il gio 2 gen 2020, 17:41 Tatu <[email protected]> ha scritto:

…

The bug description is vague and conflicting. The configs you have uploaded @gokulvenkat <https://github.com/gokulvenkat> are for Marlin 1.1.9 with 3 point auto leveling but you mention 4-8 matrix. Have you tried with either latest bugfix-2.0.x or Marlin 2.0.1 release? What leveling method were you actually trying to use? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4AWHXTN2UBI5SMEK37TQ3YKLBA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH6YVHY#issuecomment-570264223>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4AQNWJ5442PWV64GDGLQ3YKLBANCNFSM4KBVHC6Q> .

[tatusah]

I use also SKR e3 mini v1.2 with Ender 3 + org. BLTouch. UBL leveling with 9x9 grid has been working fine using 512K memory mod after the EEPROM related issues were corrected a while ago. Currently using firmware updated last time today with all the recent bugfix commits. Ender 3 isn't corexy printer though. However, if the actual probing works for corexy printers in the right positions then it's quite likely that also leveling would work.

For others to actually confirm that there is a bug one should upload correct configurations that were used when the problem occurred and detailed explanation how the problem can be reproduced.

If not using an active leveleving method that's done after homing and before printing then it should be made sure that the leveling is actually activated by having it activated in print start gcode and/or enabling RESTORE_LEVELING_AFTER_G28. Also if using UBL care needs to be taken that the mesh is actually created correctly. Depending on the probe offset, probe edge setting and mesh inset there is possibility that after probing is multiple rows/lines of missing probe points. For that there might be need to run smart fill G29 P3 several times and it makes sense to use G29 T to check that actually all mesh points are filled. By following the instructions and documentation online it's not that hard to set the things working but when taking into consideration the hardware, firmware and the print file there is clearly many points where one can also go wrong. If the problem is actually caused by wrong configuration then help is best found from appropriate Facebook forums or Marlin Discord.

[reloxx13]

can confirm, probing starts at z homing position + edge instead of 0,0+edge in lates 2.0.x bugfix

video of probing:
https://www.dropbox.com/s/o7cv4rh2eai0o5n/vlc-record-2020-01-03-02h02m14s-Webcam1-.avi?dl=0

reloxx13_Configuration.zip
ender3 skr mini e3 v1 tmc2209 bltouch v3.1

M190 S60 ;wait for bed heat
M155 S30 ;lower temp reports
M107 ;disable fans
G28 ;home
G29 T ;ABL
G1 X0 Y0 Z150 F3000
M140 S0 ;stop heating
M500 ;save mesh
M501 ;load mesh
M155 S3 ;default temp report

[tpruvot]

+1, ABL (bilinear) not like it should... or like it was in september

UBL well... made need some config adjustments to match NOZZLE_TO_PROBE_OFFSET... but unsure 100% its correctly compensating

• #define MESH_MIN_X _MAX(MIN_PROBE_EDGE, MESH_INSET)
• #define MESH_MIN_Y _MAX(MIN_PROBE_EDGE, MESH_INSET)
• #define MESH_MAX_X X_BED_SIZE - 35 // NOZZLE_TO_PROBE_OFFSET
• #define MESH_MAX_Y Y_BED_SIZE - _MAX(MESH_INSET, MIN_PROBE_EDGE)

[reloxx13]

i reverted this and the x,y start position is fine again now.
1c9ccce#r36649413

Working old code:

      else {
        probe_position_lf.set(
          parser.seenval('L') ? (int)RAW_X_POSITION(parser.value_linear_units()) : _MAX(X_CENTER - (X_BED_SIZE) / 2,      x_min),
          parser.seenval('F') ? (int)RAW_Y_POSITION(parser.value_linear_units()) : _MAX(Y_CENTER - (Y_BED_SIZE) / 2,      y_min)
        );
        probe_position_rb.set(
          parser.seenval('R') ? (int)RAW_X_POSITION(parser.value_linear_units()) : _MIN(probe_position_lf.x + X_BED_SIZE, x_max),
          parser.seenval('B') ? (int)RAW_Y_POSITION(parser.value_linear_units()) : _MIN(probe_position_lf.y + Y_BED_SIZE, y_max)
        );
      }

[stratodream]

Could you please stare tu sw you're using so that i can try it ? Il ven 3 gen 2020, 12:51 reloxx13 <[email protected]> ha scritto:

…

i reverted this and the x,y tart position is fine again now. 1c9ccce#r36649413 <1c9ccce#r36649413> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4AU67DP3L6FOAZVKPDDQ34REFA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIA64MY#issuecomment-570551859>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4ARWQ2GT77HRQX6GDSDQ34REFANCNFSM4KBVHC6Q> .

[stratodream]

I think that in #13512 informations were shared enough. I think that this issue should be taken into account as It Is no raised from few people, i see that many of us have the same issue. Il gio 2 gen 2020, 19:07 Tatu <[email protected]> ha scritto:

…

I use also SKR e3 mini v1.2 with Ender 3 + org. BLTouch. UBL leveling with 9x9 grid has been working fine using 512K memory mod after the EEPROM related issues were corrected a while ago. Currently using firmware updated last time today with all the recent bugfix commits. Ender 3 isn't corexy printer though. However, if the actual probing works for corexy printers in the right positions then it's quite likely that also leveling would work. For others to actually confirm that there is a bug one should upload correct configurations that were used when the problem occurred and detailed explanation how the problem can be reproduced. If not using an active leveleving method that's done after homing and before printing then it should be made sure that the leveling is actually activated by having it activated in print start gcode and/or enabling RESTORE_LEVELING_AFTER_G28. Also if using UBL care needs to be taken that the mesh is actually created correctly. Depending on the probe offset, probe edge setting and mesh inset there is possibility that after probing is multiple rows/lines of missing probe points. For that there might be need to run smart fill G29 P3 several times and it makes sense to use G29 T to check that actually all mesh points are filled. By following the instructions and documentation online it's not that hard to set the things working but when taking into consideration the hardware, firmware and the print file there is clearly many points where one can also go wrong. If the problem is actually caused by wrong configuration then help is best found from appropriate Facebook forums or Marlin Discord. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4AVTSBZ3OUKUJGYDYODQ3YUMHA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH67BHI#issuecomment-570290333>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4ARZIXXWI6BCK55HUY3Q3YUMHANCNFSM4KBVHC6Q> .

[tatusah]

Was about to mention the same that there is already known thing about the probe edge margins doubling at least with ABL leveling which narrows down the probed area #16367 but this shouldn't prevent the leveling from working completely. It would make the leveling less accurate in the areas which wasn't reached. Temporary fix for that is using half of the probe edge value you are normally using or copying the changes from that pull request as it hasn't been merged to the bugfix branch at the time of writing this.

As the probe offset typically isn't symmetrical between x and y axis I have preferred using individually set probe edge values for each side of the bed instead of the global value. Been using this type of configuration with UBL. The doubling of the probe edge values hasn't affected this configuration.

Did you @stratodream have also the problem that the margin you have specified for probing (min_probe_edge) wasn't correct or were you not seeing the compensation working at all? I remember your posts in the other issue thread about problems which was before the code that caused probe edge was merged to the Marlin. So the problems you were having then are probably different from this one.

What I was after with the previous message was to understand which of the different leveling methods was the problem with the original issue author and what the problem was. And if others don't have the exact same issue then it makes sense to separate those issues into other threads to better handle them.

[stratodream]

I'm complaining about the compensation Is not working as It did in Marlin 1.1.9. I have the same configurations, switching to the new Marlin 2.0 I cared about taking inside the old configurations. After automatico bed leveling i see that the first layer is very bad and It is ok only after the manual bed leveling. Il ven 3 gen 2020, 13:36 Tatu <[email protected]> ha scritto:

…

Was about to mention the same that there is already known thing about the probe edge margins doubling at least with ABL leveling which narrows down the probed area #16367 <#16367> but this shouldn't prevent the leveling from working completely. It would make the leveling less accurate in the areas which wasn't reached. Temporary fix for that is using half of the probe edge value you are normally using or copying the changes from that pull request as it hasn't been merged to the bugfix branch at the time of writing this. As the probe offset typically isn't symmetrical between x and y axis I have preferred using individually set probe edge values for each side of the bed instead of the global value. Been using this type of configuration with UBL. The doubling of the probe edge values hasn't affected this configuration. Did you @stratodream <https://github.com/stratodream> have also the problem that the margin you have specified for probing (min_probe_edge) wasn't correct or were you not seeing the compensation working at all? I remember your posts in the other issue thread about problems which was before the code that caused probe edge was merged to the Marlin. So the problems you were having then are probably different from this one. What I was after with the previous message was to understand which of the different leveling methods was the problem with the original issue author and what the problem was. And if others don't have the exact same issue then it makes sense to separate those issues into other threads to better handle them. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4AV5Q2XD3XQI5STCXF3Q34WMPA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBBDNY#issuecomment-570560951>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4ARTWYP7OVLF4XPG5A3Q34WMPANCNFSM4KBVHC6Q> .

[tatusah]

Good, it's probably something else than this edge thing as you mentioned your problems 20 days ago and this doubling was caused by a commit 10 days ago. I can check your configurations (configuration.h and the adv) if you upload them @stratodream

[stratodream]

Give me few data, i will upload them. Il ven 3 gen 2020, 13:55 Tatu <[email protected]> ha scritto:

…

Good, it's probably something else than this edge thing as you mentioned your problems 20 days ago and this doubling was caused by a commit 10 days ago. I can check your configurations (configuration.h and the adv) if you upload them @stratodream <https://github.com/stratodream> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4AS2Y564BUW35K4RUF3Q34YVJA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBCBII#issuecomment-570564769>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4AURUC6TSORGIVNASZLQ34YVJANCNFSM4KBVHC6Q> .

[gokulvenkat]

The bug description is vague and conflicting. The configs you have uploaded @gokulvenkat are for Marlin 1.1.9 with 3 point auto leveling but you mention 4-8 matrix.

Have you tried with either latest bugfix-2.0.x or Marlin 2.0.1 release? What leveling method were you actually trying to use?

I TRIED other methods autobed leveling linear and bilinear and with 4 to 8 matrix but dint worked as expected finally three point bed leveling can only manage to print first layer so i kept it as 3 point bed leveling

[Aurawin]

Guys... The kinematics have indeed recently changed. The sensor is now the relativity of the homing, G34, and G29 commands.

I'm going to give this thought, but it appears that the programmer shifted logic and is making all probes from point of view of the probe and no longer the nozzle.

[stratodream]

Sorry, i do not understand, could you please vive us more clarity? Il ven 3 gen 2020, 14:22 Aurawin <[email protected]> ha scritto:

…

Guys... The kinematics have indeed recently changed. The sensor is now the relativity of the homing, G34, and G29 commands. I'm going to give this thought, but it appears that the programmer shifted logic and is making all probes from point of view of the probe and no longer the nozzle. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4ASD4LAWXIR5Z4J2CBTQ343ZVA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBDNAA#issuecomment-570570368>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4AXF7KS6CWDLVZJWLIDQ343ZVANCNFSM4KBVHC6Q> .

[tatusah]

Do you @gokulvenkat have something actionable to try reproducing your problems? I would at least do the probe repeatability test with M48 for which you should enable that feature in configuration.h. For BLTouch v3.1 I get reported around 0.0015-0.002 standard deviation. If the reported deviation is high for you this would easily explain why the leveling compensation results inaccurate prints. With inductive proximity sensor the possible bed magnets and probing near bed attachment screws vs other areas can affect the readings.

It makes sense to get the bed level to start with even with auto bed leveling. But just out of curiosity I tried putting thick business cards on one side of the bed under the glass plate so that there was 0.6 mm difference between right and left edge of the bed. I created new UBL mesh for this situation and one layer test print was successfully compensated around the bed. Then did another test with a mesh for normal situation and used UBL mesh tilt correction probing at the start of the print which also resulted in successful print.

[ManuelMcLure]

Guys... The kinematics have indeed recently changed. The sensor is now the relativity of the homing, G34, and G29 commands.

This has always been the case, for at least a couple of years (since I started using UBL). If you probe at, for example, (10,10) the probe will move to (10,10) and measure the bed at that position, and that measurement will be used when printing whenever the nozzle is at (10,10). That is the whole point of NOZZLE_TO_PROBE_OFFSET. The probe needs to be able to move to any point that is specified as a probing location.

[gokulvenkat]

Do you @gokulvenkat have something actionable to try reproducing your problems? I would at least do the probe repeatability test with M48 for which you should enable that feature in configuration.h. For BLTouch v3.1 I get reported around 0.0015-0.002 standard deviation. If the reported deviation is high for you this would easily explain why the leveling compensation results inaccurate prints. With inductive proximity sensor the possible bed magnets and probing near bed attachment screws vs other areas can affect the readings.

It makes sense to get the bed level to start with even with auto bed leveling. But just out of curiosity I tried putting thick business cards on one side of the bed under the glass plate so that there was 0.6 mm difference between right and left edge of the bed. I created new UBL mesh for this situation and one layer test print was successfully compensated around the bed. Then did another test with a mesh for normal situation and used UBL mesh tilt correction probing at the start of the print which also resulted in successful print.

i am using inductive probe and does it get disturbed by neodymium magnets but even though its out of the probing way

[tatusah]

So you have individual neodymium magnets under the bed @gokulvenkat ? Different metal types causes the inductive sensor trigger from different distances. For the inductive probe to work accurately it expects uniform composition of the bed then it could read if the bed is actually in different distance in probing locations. Now the bed doesn't seem uniform and also the magnetic fields from the magnets would probably cause interference. Don't know what kind of error correction and filtering methods the probe possibly has.

[Aurawin]

@gokulvenkat @tatusah ,

I just had a cold-rolled steel plate cut for me. I was so tired of BLT errors and inconsistencies I threw it all out and re-designed my probe system. Rumor had it that conventional ferromagnetic sticky mats are unusable due to loss of magnetism over 50C... So naturally - I had to test :-)
I ordered a magnetic mat (roll) for use on car magnet signage. I cut the square 330mmx330mm and used 3M high temp spray adhesive.
I coated the steel plate with high-temperature furnace paint. I regret it somewhat because the first layers remove the paint one print job at a time. Sooner than later I will remove all paint with a good sanding/polishing.

I use a tiny 2mm inductive sensor that is boosted by the ferrous in the plate and the magnet sheet. The plate is ~1.5mm thick.

I tested the plate at 90(c) and it worked. It worked so well I had to wait for the magnetic mat to cool down. The magnet would not release the plate until it reached ~50c. Good lesson: don't let impatience get the better of you. I ran a scrapper through my first magnetic mat.

The 2mm inductive sensor is by far the most reliable measuring device I have ever experienced. I used BLTs, Capacitive sensors and I was exploring a dual optical sensor.

I observe a bit of variation but I think it's acceptable and caused by the deflection/distortion of my bed and not from the repeatability as that came out better than any BLT and Capacitive. Nonetheless, I have a pretty large ABL grid.

I absolutely love the idea of (printing/flexing) the metal plate to remove a print.

[gokulvenkat]

Yes i am using magnet under the bed but probing points are far from magnet

[tatusah]

The pull request fixing the double min_probe_edge issue has been merged to the bugfix branch so update your firmware to get that fix in.

But if you are seeing uneven height compensation you might want to continue investigating the issue. Just to rule out different possibilities you might want to do the M48 reliability test. Best way to test the possible effects of the magnets would be to do the test in some position that's away from the magnets. Then if you have some spare magnets place on under the bed and keep the actual carriage position in the same place so that the only thing changing is the magnet you have placed under the probe position or near it. Check if the reported min/max height and deviation change.

[gokulvenkat]

Which link is the best to get updated bugfixed firmware

[tatusah]

I guess it's best to learn how to use Vscode and compile the firmware to your specific setup. Then you can always pull in the latest commits from Marlin GitHub repository and get exactly what you want. Additionally you can make your own fork of Marlin in GitHub to manage things.

[gokulvenkat]

I will try autobed leveling once i got the new firmware bug fix and will post here what happened

[gokulvenkat]

@tatusah i am new to the programing stuff and can you please explain or make me clear about vecode and repository means,sorry to ask this but i am new to marlin program editing

[boelle]

https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x

[stevenvo]

I'm on bugfix 2.0 branch and don't see the Z moving even though with M420 S1 in gcode before printing. So looks like it is not fixed yet.
Creality CR10S - skr v1.3
configs.zip

[stratodream]

Hi,
here attached my configs files for the same issue:
Ender 3 Pro
Original BlTouch 3.1
Skr E3 mini V1.2
Marlin BugFix 2.0.x (commit available on 18/01/2020)
ConfigFiles.zip

[stevenvo]

is there a way to simulate the z-compensation in unit test / integration test suite?

Marlin/Marlin/src/core/utility.cpp

Line 161 in e6a37ba

const float rz = bilinear_z_offset(current_position);

[boelle]

@gokulvenkat please re-test with latest bugfix from here: https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x

let us know if the problem is still there

[stratodream]

I tested It, to me It serena ti be fixed. Il dom 2 feb 2020, 10:12 Bo Herrmannsen <[email protected]> ha scritto:

…

@gokulvenkat <https://github.com/gokulvenkat> please re-test with latest bugfix from here: https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x let us know if the problem is still there — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4ATAXEQFFZXP3F3GTYDRA2FBPA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKRRUZQ#issuecomment-581114470>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4ARYVB36WNGKEXP5T2DRA2FBPANCNFSM4KBVHC6Q> .

[gokulvenkat]

Hi everyone,it's been a long time I tested with bugfix marlin 1.1.9 and the issue is solved now
Thank you @boelle @tatusah and every one

[gokulvenkat]

Sorry for the delay

[boelle]

1.1.9 or bugfix 2.0.x ?

[gokulvenkat]

1.1.9 bugfix

[stratodream]

but the issue was on 2.0.x bugfix if i'm correct, anyway as i told before, i tested It on 2.0.x bugfix and It seems ti be fixed. Il lun 3 feb 2020, 15:38 gokulvenkat <[email protected]> ha scritto:

…

1.1.9 bugfix — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16397?email_source=notifications&email_token=AD3S4AVXUP4IBW542EQ3FCTRBAT5DA5CNFSM4KBVHC62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKUCJNI#issuecomment-581444789>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3S4AQEZIC3YE4MNCVDMUDRBAT5DANCNFSM4KBVHC6Q> .

[boelle]

@gokulvenkat try bugfix 2.0.x also,

there is no 1.1.9 bugfix only 1.1.x bugfix

why i push for bugfix 2.0.x is that its the only one that is actively worked on daily
1.1.9 will not be updated, and the maintainers do not do anything with 1.1.x unless users submits PR's

[gokulvenkat]

Sorry i used 1.1.x bugfix

[gokulvenkat]

Not 1.1.9

[boelle]

but you should really try 2.0.x bugfix, its the way forward

[gokulvenkat]

On next upgrade of the machine i move to 2.0.x

[gokulvenkat]

but you should really try 2.0.x bugfix, its the way forward

Thank for your tip

[chderycker]

Still having this problem on ender 3 with Skr e3 mini 1.2 on a config made yesterday on Marlin Bugfix 2.0.3

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