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.34k stars 19.26k forks source link

[BUG] Ajeje brazorf #17399

Closed ashinhood closed 4 years ago

ashinhood commented 4 years ago

Ajeje

scaery commented 4 years ago

Try to enable RESTORE_LEVELING_AFTER_G28

/**
 * Normally G28 leaves leveling disabled on completion. Enable
 * this option to have G28 restore the prior leveling state.
 */
#define RESTORE_LEVELING_AFTER_G28 // always do leveling before print

You did already specified Z in NOZZLE_TO_PROBE_OFFSET. Are you sure it is always correct like that?

Still, Im not familiar with the Bltouch, but that would be my first search to correct the mentioned behaviour.

ashinhood commented 4 years ago

I specified the Z nozzle offset because is the value tested, but the distance is not correct in every part of the bed, but only in 1 portion of the bed, that let me think about is not an OFFSET problem but something about auto bed leveling compensation that not work correctly.

I tried to enable RESTORE_LEVELING_AFTER_G28 same problem

scaery commented 4 years ago

Okay, Bltouch has a lot of troubles if you look in the issue list. Im not sure if your problem was not already been mentioned, else just stick with the old firmware which works currently or try the bugfix release. Maybe a duplicate of #17361

Could also be your eeprom was not cleared, but you reflashed it so that should be gone... Weird, sorry cannot help you with it. Too individual and not having a Bltouch to test with. Reset to zero at start leveling from scratch.

Grogyan commented 4 years ago

First, when you change firmware, you must do a M50, followed by a M500

I noticed that you are using safe homing.

Have you by chance noticed if the G28 probe position is actually at the centre of the bed with the probe offsets? For myself, with UBL, probe offsets aren't being applied, due to the requirement to use Safe Homing, which on my machine I3 Mk2.5 RepRap SKR1.3.
Ie bed centre is exactly (Probe_Offset/2) short from it is supposed to be

thinkyhead commented 4 years ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

Grogyan commented 4 years ago

Safe_home_Mesh.txt Configuration.zip

I understand that my config is UBL, however, the output mesh data is present in the log. Take note of G28 position, this is safe_homing which is offset from it's true location by 50% of the NOZZLE_TO_PROBE offsets

thestephenmarshall commented 4 years ago

I seem to be experiencing the same issues as OP. Lack of leveling adjustments is consistent with the grid produced running:

Grid looks good to go, but regardless I end up with incorrect Z offset (too low or too high). Before I disable my printer for an undetermined amount of time to produce the .txt file required, I am trying out 2.0.4.4 which would be the approximate version at which I can recall ABL to be working as expected. Will post back with results after a few prints.

Talha909 commented 4 years ago

I seem to be experiencing the same issues as OP. Lack of leveling adjustments is consistent with the grid produced running:

  • G29 P1
  • G29 P3
  • G29 J

Grid looks good to go, but regardless I end up with incorrect Z offset (too low or too high). Before I disable my printer for an undetermined amount of time to produce the .txt file required, I am trying out 2.0.4.4 which would be the approximate version at which I can recall ABL to be working as expected. Will post back with results after a few prints.

I will wait for your result. I also have the same problem. One time very high and time very low. Yesterday it was working fine with 2.5.3

thierryzoller commented 4 years ago

The Grid I print (G26) shows that it doesn't compensate. The only reason I can print is because I actually manually level it before ABL. Which defeats the purpose of having it

delskev commented 4 years ago

I have the Same problem with the BLTouch v3.1. I tried different firmware based on Marlin . And I end up like @thierryzoller ... manually level the bed...

thestephenmarshall commented 4 years ago

Update here after almost a full week running 2.0.4.4 I am no longer experiencing these issues with no compensation. I am still not 100% sure of anything at the moment as I did end up adding mean compensation steps to the end of my leveling procedure:

That being said, I am using a BLTouch v3.1 and right after moving back to 2.0.4.4 I did indeed see improvements. After I finish my project (sometime this week) and can fool around with it, I will grab the data requested above from both versions for comparison.

nfons commented 4 years ago

@thestephenmarshall i will have to try that out as well. I have a very similar issue in https://github.com/MarlinFirmware/Marlin/issues/17262

thestephenmarshall commented 4 years ago

Unfortunately, my Y axis bearings need replacement so I will not be able to proceed until I receive the Misumi replacements in a few days.

nfons commented 4 years ago

@thestephenmarshall did you try this with bilnear previously? or was it only UBL

thestephenmarshall commented 4 years ago

@nfons I did not try with bilinear - only UBL.

jimschaefer commented 4 years ago

I recently upgraded my cheap Tronxy X8 Printer (Melzy V2_5 controller board) with marlin 2.0.X bug fix and got a BLtouch clone (3dTouch from Geetech) working and also a heated bed with a glass plate. I was expecting the 3 point bed leveling to work better than my previous manual leveling process but it seems to compensate incorrectly or very poorly. I manually leveled bed and one layer brim printed OK but with bed leveling one side is higher than the other so much that adhesion is not good enough to print. I am not sure if it is hardware or software related and would like some feedback.

I ran some M48 V probe tests and the standard deviation comes back with a standard deviation anywhere from 0.026 to 0.056. Z speed around 60 mm/sec but slower speeds actually did worse for some reason. I put the system into a debug mode while probing (see attached file) and i was getting s second probe discrepancy anywhere from 0.09 to -0.40 with heaters on or off, didn't really matter. Note... my numbers above are from multiple tests, I just attached one of them to this post.

My initial thought is there is just too much variation in the values the probe is reporting but I have no experience to know if this is true or not.
I think the errors could be due to the following, but I am not sure how to rule things out:

Any suggestions on how to narrow this down ? Files attached. Thanks !

ConfigFilesAndLog.zip

Other comments: The 2.0.x bug fix really improved the BLtouch logic.. on the mainline 2.0.5.3 the probe extend retract is VERY inconsistent. I almost cracked my glass bed on homing. However, sometimes the BLtouch servo movements (pin up/pin down) get really flaky. Pin won't go down/won't come up, alarms, etc. Rebooting board seems to always fix the problem. I don't know how the PWM signal is generated for the device but wonder whatever caused the performance improvement since 2.0.5.3 doesn't always fix the issue, maybe changes the PWM signal ? Just a thought. I was reading how challenging it has been to get stepper pulses the correct width on the low end boards like mine.

GotoHack commented 4 years ago

I have the same problem. If you check out fc74c6a you should have a working version with BLTouch. I do not have time some far to dissect and find where the bug was introduced.

lordnibbler22 commented 4 years ago

Hello All,

i am currently running 2.0.5.3 on 2 printers with a SKR 1.4 turbo board. and i got some really strange first layer issues with UBL. I switched to ABL and found that the first probe after power ON or reset produces absolutely wrong results. when i run a G29 again the mesh is good. I can verify it on 2 different machines.

Probe is a PINDA v2 on a Prusa Bear with SKR 1.4 Turbo.

Printer 1 G29 after Power ON/reset

printer1_after_power_ON

Printer 1 G29

printer1_G29_1

Printer 1 G29 again

printer1_G29_2

Printer 2 G29 after Power ON/reset

printer2_after_power_ON

Printer 2 G29

printer2_G29_1

Printer 2 G29 again

printer2_G29_2

sergiofagundes commented 4 years ago

Is the Bed leveling compensation to be used only during print of gcode files or it will work even if using a direct G0/G1 Zxx on pronterface or similar software ?

I can't get to use compensation on pronterface for example:

G28 M420 S1 G0 Z1 G42 I0 J0

So after this I move in lcd menu the Z down (-0.025 steps) till the nozzle hits the bed, but when it happens it's not a 0 (Zero), Z is much high and doesn't match the leveling mesh data.

That's why I'm questioning if this is meant to work only during prints (I can't test a print right now, since I'm out of filament :)

sergiofagundes commented 4 years ago

Oh well, just installed today (25/04/20) the bugfix and now the compensation is working. Answering my own question ;-). Yes the compensation is meant to use in all movements (while M420 S1 = bed leveling ON). I am out of filament but have tested every point in the leveling points and all are good (with the new bugfix downloaded today).

thierryzoller commented 4 years ago

Consindering many reports that ABL works if the printer is restarted but not after cancelling a print or starting a second one. Can you confirm that's the case once you got filament please. Thank you.

thinkyhead commented 4 years ago

I switched to ABL and found that the first probe after power ON or reset produces absolutely wrong results. when i run a G29 again the mesh is good. I can verify it on 2 different machines.

@lordnibbler22 — It would be interesting to have a look at the logs.

Repeat this procedure as needed to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on.

Azrael321 commented 4 years ago

Configuration.zip

Today i started a print with the latest Bugfix (03.05.2020). I can notice, that with ABL_Bilinear, there is no movement in Z during the first layer. After the first layer, ABL seems to work as it should (i can see compensation movements in Z)

thestephenmarshall commented 4 years ago

Very interesting! In fact, I am seeing the same thing that @Azrael321 is mentioning. After the first layer, the z-axis motors are adjusting according to the mesh data. Here is the 5x5 UBL mesh data I used in this example:

Recv:     ( 20,180)                      (175,180)
Recv:         0       1       2       3       4
Recv:  4 | -0.235  -0.068  -0.004  -0.040  -0.063
Recv:    |
Recv:  3 | -0.226  -0.082  +0.005  -0.031  -0.054
Recv:    |
Recv:  2 | -0.217  -0.095  +0.014  -0.022  -0.045
Recv:    |
Recv:  1 | -0.228  -0.096  +0.015  -0.033  -0.056
Recv:    |
Recv:  0 | -0.236  -0.100  +0.014  -0.016  -0.040
Recv:         0       1       2       3       4
Recv:     ( 20, 20)                      (175, 20)

First Layer

first layer

Second Layer

IMG_1111

I can also confirm that, after power cycling the printer, ABL is working 100%.

thestephenmarshall commented 4 years ago

Update here after almost a full week running 2.0.4.4 I am no longer experiencing these issues with no compensation. I am still not 100% sure of anything at the moment as I did end up adding mean compensation steps to the end of my leveling procedure:

  • G29 P5 - get the mean
  • G29 P6 C[mean] - apply the mean to the mesh

That being said, I am using a BLTouch v3.1 and right after moving back to 2.0.4.4 I did indeed see improvements. After I finish my project (sometime this week) and can fool around with it, I will grab the data requested above from both versions for comparison.

Just need to update/correct this bit. So the "improvements" I was seeing here in 2.0.4.4 were actually a false positive as the prints I ran to test were all done right after powering up the machine and not subsequent prints or retrys. This means I did not power cycle the machine either. Seems this bug exists in 2.0.4.4 as well.

As a work-around, I am power-cycling my machine after each print. Not optimal, but it gets the job done.

thierryzoller commented 4 years ago

Sounds similar/same then https://github.com/MarlinFirmware/Marlin/issues/17872#issuecomment-624836618

thinkyhead commented 4 years ago

…the z-axis motors are adjusting according to the mesh data…

I found something similar in my testing, and did a bunch of logging, but I was never able to track it down to the exact cause. But that seems to be the right approach, so let's try that. I'll get some extra logging in tomorrow and play around with it, and then I'll post for you all to try, and hopefully we'll find the reason for the weirdness.

As a quick experiment, does the effect go away if you add M420 S0 to the end of the G-code file?

lordnibbler22 commented 4 years ago

@thinkyhead some logs with the latest bugfix from today. looks like the weird first run mesh is gone.

1_G29.txt 2_G29.txt 3_G29.txt

thestephenmarshall commented 4 years ago

One more set of updates from testing various versions of Marlin 2.0.x:

heated-1

What I've done as of now that seems to work fine:

  1. Always start as first print (reset button or power cycle) before printing
  2. The above doesn't work alone now (for whatever reason), so I've stopped using G29 P1 until the issues listed here and in many other similar issues are resolved
  3. To get a workable mesh, I've returned to manual bed leveling. This isn't good enough alone, so:
  4. finally, using G29 J (tilt mesh) after G34 (align Z axis) on a zeroed mesh gives me the results I need to continue printing

Figured I would share since I haven't had much luck with any other methods.

thierryzoller commented 4 years ago

What do you mean by "zeroed mesh" in #4

thestephenmarshall commented 4 years ago

P0: Zero Mesh Data and turn off the Mesh Compensation System. This reverts the machine to the same state it was in before UBL Compensation was enabled.

https://marlinfw.org/docs/gcode/G029-ubl.html

thestephenmarshall commented 4 years ago

I did try Bilinear ABL as well, but no dice there as well. I am very used to UBL, so I'm going to stick with that unless someone finds something interesting.

thinkyhead commented 4 years ago

@thestephenmarshall — If your bed is very flat and only tilted, you can use LINEAR instead, and you might get nicer results.

I'm not sure about the hypothesis that every other column is negated. There is no logic in Marlin that cares about rows and columns with respect to the results returned by the probe. The Z value is based solely on the Z position at the time the probe triggers. If the triggered Z position in the planner wasn't making it back to the current position, the error would accumulate, not oscillate.

You may want to try running a variety of M48 tests to make sure that the probe is behaving repeatably in all areas of the bed, just to rule out unusual probe behavior.

thinkyhead commented 4 years ago

Thanks for the logs, @lordnibbler22.

I will run several bed leveling tests today and do tiny print jobs in between them.

"ABL works if the printer is restarted but not after cancelling … or starting a second print

@thestephenmarshall — Others have mentioned that the Z discrepancy issue occurs between prints but does it really require a print? Or, will it manifest if any XYZ moves are done? If it requires a print to be started and finished (or canceled) it makes me wonder: Why should a print make a difference?

With that in mind, please send along a small G-code file that exhibits the problem, so that I have the exact START and END G-code from your slicer. This might be an important factor.

nfons commented 4 years ago

@thestephenmarshall not sure if you mentioned...what board are you using?

thestephenmarshall commented 4 years ago

@nfons I am using SKR v1.3, TMC2209 drivers, 12V

thestephenmarshall commented 4 years ago

@thestephenmarshall — If your bed is very flat and only tilted, you can use LINEAR instead, and you might get nicer results.

Good advice. I will have to try this out next. I do think something might be up in the BLTouch area of the hardware on my setup. Perhaps some sort of magnetic interference. It’s really strange tbh as the print surface is 4mm borosilicate glass.

thestephenmarshall commented 4 years ago

This is a highly modified MPMS v2.1.

BLTouch v3.1

Only thing left is the frame, rods, z assembly and Y motor. BTT SKR v1.3, TMC 2209 v1.2 drivers on X&Y, TMC2208 v3 dual drivers on Z.

Flexion HT extruder (not that it makes a difference here), but that demanded that I either decrease microsteps or upgrade the extruder motor to a Quimat > 2A capable motor (which I did) for more torque which ate up and extra 5mm on the X axis. Now it doesn't even break a sweat at 1500mA.

Bed is 200x195mm with 8mm swiss clip gutters.

4mm borosilicate glass with 200W silicone heater and 400W 12V power supply.

M851 - Probe Offset X0.00 Y-42.00 Z-2.40 Probe is aligned right in front of the direct drive assembly.

Results from the Probe Accuracy Test

Center - M48 P5 L5 X100 Y100

Mean: -0.008500 Min: -0.013 Max: -0.005 Range: 0.007
Standard Deviation: 0.002549

Front Left - M48 P5 L5 X8 Y8

Mean: -0.268500 Min: -0.273 Max: -0.263 Range: 0.010
Standard Deviation: 0.003391

Front Right - M48 P5 L5 X187 Y8

Mean: 0.016500 Min: 0.010 Max: 0.022 Range: 0.013
Standard Deviation: 0.004062

Rear Left - M48 P5 L5 X8 Y158

Mean: -0.135000 Min: -0.138 Max: -0.130 Range: 0.007
Standard Deviation: 0.002739

Rear Right - M48 P5 L5 X187 Y158

Mean: -0.063000 Min: -0.068 Max: -0.058 Range: 0.010
Standard Deviation: 0.003674

The deviations seem within tolerance.

I switched to Linear and here are the M420 V results

Send: M420 V
Recv: Bed Level Correction Matrix:
Recv: +1.000000 +0.000000 +0.000789
Recv: -0.000000 +1.000000 +0.000335
Recv: -0.000789 -0.000335 +1.000000

How could X8 Y158, X100 Y100 and X187 Y8 all be +1.0mm? To me, this matrix looks odd. G29 J on UBL doesn't produce these anomalies.

wakille commented 4 years ago

Hey guys, so I am also suffering from first layer problems with the combination of a SKR 1.3 and 3DTouch Probe (newest gen). I tried UBL and ABL, and results always in the same outcome. For x<100 the bed is too low or for x>100 too high (depending on set Z-Offset). I now did some testing with ABL. First I ran G29 and afterwards also probed the same points with M48. Here are the results:

G29
     0      1      2
0 +0.354 -0.051 +0.219
1 +0.087 +0.001 -0.070
2 +0.258 -0.034 +0.304

M48

  0    1    2
0 +0.352 -0.058 +0.213
1 +0.087 -0.001 -0.070
2 +0.262 -0.046 +0.302

Exact results with M48 P4 X*** Y*** P4 L2 E V2

X|Y : Mean(Standard Deviation)
8|8: +0.352422(0.002068)
100|8: -0.058394(0.000856)
192|8: +0.213393(0.004220)
8|100: +0.087803(0.001912)
100|100: -0.001686(0.000745)
192|100: -0.070463(0.000947)
8|192:  +0.262828(0.001951)
100|192: -0.046220(0.001516)
192|192: +0.302724(0.001599)

Difference between G29 and M48:

    0      1      2
0 +0.002 +0.007 +0.006
1 +0.000 +0.002 +0.000
2 -0.004 +0.012 +0.002

Bed size: 200x200

I will do the same test with UBL and provide also logs. Also I have this issue all the time, not only after aborting a print. LogG28G29M48.txt

Mils24 commented 4 years ago

Hi guys,

Ive commented on a few of these similar threads as Im not sure which one is most active.

Ive followed your request @thinkyhead please see debug file for me attached.

Printer: Homemade delta Motherboard: MKS SBASE 1.3 Firmware: Marlin Bugfix 2.0.x (currently) also tried Marlin 2.0.5 before moving to Bugfix as I had read somewhere that Bugfix worked with ABL. Sensor: Triangle Labs 3DTouch (BL Touch clone) ABL type: Bilinear ABL

Debug.txt

Mils24 commented 4 years ago

Ive been doing a bit more thinking and more reading of other threads on here with similar issues.

Seems a few people have linked odd ABL and BLTouch issues to Z_SAFE_HOMING.

Question - With Z_SAFE_HOME ON on a Delta should the endeffector move to the centre of the bed before homing up to the top? (assuming you have the safe homing set to (delta_printable_radius)/2???

This is something that has puzzled me also. I have Z_SAFE_HOMING on with the safe point set as per above. However when my prints finish or I'm I'm testing points of the bed and then home, my printer just moves straight up. My expected behaviour was move to centre of the bed and then up but it's not doing that.

If my Z_SAFE_HOMING isn't working properly and some people think its linked to ABL issues could this be my problem?

Is it crazy to tun it off?

thinkyhead commented 4 years ago

If you set your Z_SAFE_HOMING point to the opposite of your probe offset, then the effector will be in the center of the bed for safe homing.

thinkyhead commented 4 years ago

For x<100 the bed is too low or for x>100 too high

@wakille — This almost certainly indicates that you have a twist in your X gantry, which is a common problem. It causes probe readings to become distorted, and there is nothing unfortunately that the firmware can do to fix the issue. You must repair the twist in your gantry.

thinkyhead commented 4 years ago

How could X8 Y158, X100 Y100 and X187 Y8 all be +1.0mm? To me, this matrix looks odd. G29 J on UBL doesn't produce these anomalies.

@thestephenmarshall — You are confusing a MATRIX with a probe grid. A 3 x 3 matrix is used to tilt all points in a 3D space. Those numbers are not the measured Z heights, but are calculated by the Least-Squares method. See https://marlinfw.org/docs/gcode/G029-abl-linear.html

wakille commented 4 years ago

For x<100 the bed is too low or for x>100 too high

@wakille — This almost certainly indicates that you have a twist in your X gantry, which is a common problem. It causes probe readings to become distorted, and there is nothing unfortunately that the firmware can do to fix the issue. You must repair the twist in your gantry.

@thinkyhead Ok, thanks for the tipp. But I dont unterstand clearly what´s wrong with my gantry. Do you think my rails are bent or that there is a height difference between the left and right side of my x-axis ? And is there a way to be sure, that this is my issue, like can I meassure something to confirm this theory ? Because e.g. I meassured the height difference and is at maximum 0.4mm. Thanks a lot for you help!

thestephenmarshall commented 4 years ago

Back to provide some more updates. I have tried these things:

  1. G29 J2 - probe mesh at the four corners. Grid looks good, but compensation is still off when printing. Still seems like too much compensation (same areas as my previous posts).

  2. Found that G29 S should probably always be run declaring the slot ala G29 S0 as an example. During tests, I learned that simply running the command without the slot parameter can potentially save the data in some strange undefined place.. Who knows where it went (and I never explicitly selected any other slot than 0) ¯_(ツ)_/¯

  3. G29 J5 (or higher number of points) produces same strange I1 and 13 grid points as G29 P1

  4. Since the meshes I have provided above sure do look like bend X and/or Y rods, I did these things:

    • Completely disassembled the printer to check if the rods are bent. Rods not bent! (though unless I am mistaken even ABL should be able to compensate for this)
    • Ran G29 P0 followed by G29 S0 to ensure a zero mesh start (machine true)
    • Started my next print which spans the length and width of the bed
    • Upon noticing very similar results to the tests above, adjusted the 8,8 and 192,192 bed knobs slightly (while printing) until the line widths were consistent. Now the printer is laying down perfect layers including the first.
    • If the BLTouch was picking up bent rods and my rods were truly bent, shouldn't my line widths and layers be reflecting this? e.g. nozzle dragging, line width too narrow (gaps between lines)? This is considering I am running no ABL compensation (zeroed mesh).

Attached is the current 9-10 hour print sliced with Cura 4.6.1. Not using any experimental features or flow equalization.

WDI3_main-corners-mid-Corners-Mid.gcode.zip

Rage01 commented 4 years ago

Did we ever find out a fix for this? Or what is causing the inconsistency of the bed levels? Sorry I am not much of any help.

bitshiftr commented 4 years ago

I too have this issue with my Ender 5 (SKR mini E3 v1.2 and bltouch v3.1) running bugfix branch. I can clearly see during my first layer that compensation is not being applied in Bilinear ABL. Since my bed is fairly level to start with, I am still able to manage, but it's clear that the layer is too thin at some places vs. others.

Mils24 commented 4 years ago

I have given up on trying to get Bilinear to work. I had actually given up on Marlin and moved to Smoothieware but unfortunately I couldn't get me MKSTFT to allow me to do baby stepping with smoothie so Ive came back to Marlin. This time however I've opted for UBL instead of bilinear and it seems to work.

wakille commented 4 years ago

Disabled Bed Leveling and now printing without better than with bed leveling enabled. Checked also my mechanical setup and found no issue. And I also still don't understand, why ABL should not compensate for bent rails. And if the measurement would be distorted, shouldn't be the repeatability be bad ? For me this still looks like a bug, but maybe I am just too inexperiecend. Thought about using the RepRapFirmware Fork for the SKR boards.