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

Mils24 commented 4 years ago

I defintly think there is some sort of bug in Marlin. Its just odd that it happens for some and not all. Makes me wonder if there is another setting that some of us have enabled that is cause it not to work. My z_safe_homing is still not working either but I have just gave up on it. I tried as per thinkyheads instruction but setting it at 0,0 or the opposite to my ZProbe offset doesn't work. My head always just goes straight up from the last known XY position instead of moving to 0,0 and then homing. I also thought about trying the RepRap fork but I don't have the WiFi ESP board and I don't really want to buy any more parts for this machine. I already bought Raspberry pi and have it hooked up to Octoprint therefore adding the wifi module would feel like the Pi was a waste of money.

For now I'm just going to stick with UBL enabled and hope that sometime in a future release the Bilinear gets fixed. I would prefer bilinear as with my MKSTFT I don't have the functionality to easily adjust the mesh and therefore bilinear seems like it would be easier.

AnHardt commented 4 years ago

ABL (Auto BED Leveling) is strictly only to compensate for tilted beds. Nowadays we also can improve printing on bumpy beds (mesh based and UBL). ABL is NOT meant to solve any other geometry problem of the printer. Any probe based leveling system is particularly sensible to errors changing the difference between nozzle-tip and trigger-point of the probe with the position of the nozzle. For example To avoid that probing problem you could use good old manual-mesh-bed-leveling (using the nozzle as a probe) or could overrule the probe by editing (overruling the probe) the mesh-points with UBL.

Always when you see a systematic error (left/right/front/back/diagonal too high/deep) it's very likely to be a distortion of the frame to make the probing fail - resulting in a leveling based on wrong data. Or leveling is simply not switched on.

thinkyhead commented 4 years ago

Please test the latest bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

shitcreek commented 4 years ago

We've tested the latest build with ABL Bilinear and found no issue when we did an exaggerated test ie setting the bed leveling compensation mid point to 2mm (using M421). We saw that the print head moves up and down accordingly. I ran this test gcode repeatedly and the logs produced are identical: leveltest-dr.gcode.zip logs

Bed leveling results are within acceptance (biggest difference was 0.007)

Bilinear Leveling Grid:
measured_z = [
 [ -0.250, +0.032, +0.323 ],
 [ -0.388, -0.039, +0.099 ],
 [ -0.414, -0.055, +0.275 ]
];

Bilinear Leveling Grid:
measured_z = [
 [ -0.258, +0.036, +0.323 ],
 [ -0.389, -0.039, +0.100 ],
 [ -0.423, -0.053, +0.268 ]
];

Bilinear Leveling Grid:
measured_z = [
 [ -0.270, +0.026, +0.320 ],
 [ -0.405, -0.044, +0.098 ],
 [ -0.439, -0.062, +0.256 ]
];

However when I did some test prints, line adhesion to each other on 2nd prints appear to not be a great as the first prints after power cycling (first prints weren't perfect either). But this could have been caused by something else perhaps. Nevertheless by simply squishing the first layer a bit more fixes this completely: abl-tests

I am pretty confident that ABL is working as it should.

boelle commented 4 years ago

@shitcreek i will risk my neck and close this one then

it also works for me

aSocialMenace commented 4 years ago

I am having this exact same problem.. Im using the btt skr mini e3 in my ender 3 pro and I'm running octoprint on a pi 4 (2gb) .. I've followed ever tut online and I can't get it to compensate in the first layer. I've complied this firmware a dozen times or so over the past couple weeks.. I've used "know good" configuration.h files and still she won't adjust in the first layer.. I can generate and view the mesh in octoprint but the printer does not correct the z on the first layer.... I'm super frustrated here.. anyone have a fix for this? Anyone know that last good version of Marlin that bl touched worked with??? I am considering reverting back to 1.1.8 as mentioned above but I'm unfamiliar with how to compile that version with the btt skr mini e3 board..

sognatore99 commented 4 years ago

I was (maybe still am) having the same issue with Marlin bugfix 2.0.x. I switched out my 3d Touch with a newer one and still had same issues. I googled the heck out of it and only came up with a note in the BL touch manual. I chose the second option and had to put it also in the Marlin starup section in the "Configuration_adv" section. Note use /n to separate commands. Once I did this the G28 command worked correctly, I however leveled the bed manually so I really can not say if it fixed the overall issue. Here is the snippet from the BL Touch (works with generic also) manual:

Depending on your board, you can choose between the following two.

  1. Logic voltage free(default) mode (Recommended) ← Both 3.3V /5V Logic are available M280 P0 S160 ; BLTouch alarm release G4 P100 ; delay for BLTouch G28 ; home G29 ; auto bed leveling

  2. If the nozzle is in contact with the bed after missing the trigger signal(A board with large capacity capacitor in end-stop input circuit, such as the Melzi). M280 P0 S140; ← Only 5V Logic mode(Do not activate 5V logic on 3.3V logic system without 3.3V logic conversion) G4 P2000 ; delay for BLTouch M280 P0 S160 ; BLTouch alarm release G4 P100 ; delay for BLTouch G28 ; home G29 ; auto bed leveling

Boards with large capacity capacitor in end-stop input circuit: Melzi and some of the Creality3D, ANET board, etc. (Select 1 if you have already removed the capacitor from your board)

jermbe commented 4 years ago

Hi, something I read triggered me.

When people use TMC2208/TMC2209 drivers, they need to reverse their axis in the firmware (or reverse the connectors on the motherboard). Can it be that if the axis are reversed in the firmware, that the ABL is correcting this on a non reversed bed? My BL touch sees that my bed is low left, a high right. But when I print left the filament is almost scraped off, and right it is almost not fixed on the bed. => It is compensating the wrong place of the bed.

gbkwiatt commented 4 years ago

I am having same issue, and I had same idea as above, that it might be somehow reversed, I can't make BLtouch work. I used to have BLtouch on ender 3 with marlin 1.8 and never had an issue. But just got ender 3 with board 4.2.7, and can't make it work properly, I can see on octopi and bed mesh visualisation that it does detect unevenness, but seems not compensating for it during print, I am giving up

hamster65 commented 4 years ago

CoreXY with TMC drivers and bed leveling bilinear: Height is correct on the right, but too high on the left part of the bed no matter what I do.

thierryzoller commented 4 years ago

@hamster65 @gbkwiatt Have you tried the latest bugfix2.0 build?

Talha909 commented 4 years ago

I also have the same issue. G29 command run successfully but when print start there is no compensation of ABL. I had 4 days old Bugfix.

gbkwiatt commented 4 years ago

I have latest bug fix and also tried 2.0.7.x it doest compensate because I can fill Z rod moving up and down, but either it's compensating wrong way or not enough

sognatore99 commented 4 years ago

You may already know this but just in case, make sure you reset the EEPROM contents using M502. Then try your bed leveling procedure again. I had the same issues and posted above (sept 4th). I am able to print again, but I made sure my bed was leveled manually. The visualizer shows minor bed issues (0.2-0.4 mm) so it might be compensating for me. I hope this helps, i know i wanted to just throw the whole printer out the window!

gbkwiatt commented 4 years ago

I did level bed and visulizer shows it almost all green but yet comeonsarion is not enough/wrong will have a further investigations

sognatore99 commented 4 years ago

I have added a zip file that contains my configuration.h and configuration_adv.h files. Under the advanced section I included the following

define STARTUP_COMMANDS "M280 P0 S140 \n G4 P2000 \n M280 P0 S160 \n G4 P100"

As it has been a few months and my comment in that section really was not clear. I believe I did this as my z axis would move the head to low and press into the bed.

Anyway all of my changes for Marlin-bugfix-2.0.x are annotated with //PES

I hope this help :)

These are for an ender 3 pro with a modified print head so use this only for comparison.

Configuration.zip

hamster65 commented 4 years ago

@hamster65 @gbkwiatt Have you tried the latest bugfix2.0 build? Last pull was about 5 days ago, I'll test the current one on my next print. I also do M502 and M500, it's part of my flash process.

Could this be related? https://github.com/MarlinFirmware/Marlin/issues/19132#issuecomment-713477249

gbkwiatt commented 4 years ago

Not sure, I've just checked everything and it does compensate something and also looks like proper direction, but just not enough. I literally had to level bed perfectly, but then what's the point of having BLtouch, I've had marlin 1.8.x with my previous ender 3 and board 1.1.5 and bltouch and I have never leveled bed and it was perfect every time.

At this point I am not sure why is this happening, maybe something to do with new board 4.2.7 it just doesn't make sense.

Bed visualizer shows all differences so BLtouch works, I don't know its bizzare and I am annoyed as I got printer for my bday and all I do for past week is trying to figure out what's going on ;)

gbkwiatt commented 4 years ago

Okay I did everything and took printer apart etc. Previously when I had ender 3 with BLtouch on old board I never leveled bed manually with BLtouchx it was always perfect. Now it just doesn't compensate enough, it works because you can see bed visualisation, bit during print seems like corrections are to genfkenor too small. I ran out of ideas, obviously I could level my bed manually but that not the point...

marcusletric commented 4 years ago

I was struggling a lot in the past days to get my printer work correctly after the installation of a 3DTouch v3, here are a few things I had to do to make it work

Anet A6 printer, Skynet 2.3.2 (Marlin 1.1.0-RC8).

I know it's an old version, but seems like the new ones still suffer from these issues.

I use bilinear and now it seems like it is ok, I intentionally tilted my bed a bit and during print I can see the Z axis slowly moving and doing the correction.

I am not willing to install / tests newer version for several reasons:

jermbe commented 4 years ago

Hi @marcusletric, would you mind letting me know the changes in the code? Then I might try my hand at it on Marlin 2.x. As I'm also fed up that this hasn't yet been addressed while plenty of people are reporting the exact same issue.

I'm more and more inclined to move towards other Firmware, even though that means changing my motherboard...

thierryzoller commented 4 years ago

I followed youtube instructions to calibrate z-offset and it said to do it after G28 (homing). The offset was ok when I moved the Z to 0, but then I did a G29 and the offset was not correct anymore. I do Z offset calibration after G29.

Can anyone confirm the above ? This may well be linked to one of the variants to the problem

@marcusletric : When you say "I do Z offset calibration" - do you mean you set the Zoffset using G-code again?

marcusletric commented 4 years ago

@jermbe Here you go:

Conditionals_LCD.h: (in #if ENABLED(BLTOUCH) directive, where all the servo commands reside for BLTouch)

#define BLTOUCH_5VMODE 140

Marlin_main.cpp: (in void setup() method)

#if ENABLED{BLTOUCH_FORCE_5V_MODE)
  bltouch_command(BLTOUCH_5VMODE)
#endif

@thierryzoller Please remind that I'm using an old version of marlin

After the first homing I also do a bed leveling (G29) then I move Z to 0 and measure the offset after.

One more thing: "changed the title [BUG] Marlin 2.0.5 - Auto Bed leveling not work - no compensation [BUG] Ajeje brazorf"

Well, this will not help in future google searches huh?

gbkwiatt commented 4 years ago

After all this weeks fighting with bltouch, I am giving up. I put my old board with marlin 1.1.9 and it works as a charm. But with newer 32bit board and latest 2.0.x bugfix I just can't make bltouch to work correctly. Everything looks perfect, Bed visualiser shows correct differences after G29, but during print, it just doesn't compensate. I can see Z axis moving but looks like it's not moving enough, so I am ending with having one squished side and other printing in the air. I've made the test on marlin 1.1.9 and I made slope on my bed, and I mean like 5mm difference, and it still printed fine.

I can level bed manually and it will be fine, but the whole point of having bltouch ... down the drain.

I did post some of my logs here https://github.com/MarlinFirmware/Marlin/issues/19839 I need more ideas, what can I do or check ? I really want it to work on my silent board.

My process of setting Z offset is, G28 and then set Z offset, but even during print I do babysteps to make it perfect, and it is on 2 side but then it goes all titsup on other side, so it's not matter of Z offset as such. It's something that bed leveling does or maybe doesn't do. I am using Bilinear auto bed leveling 3x3. Tried 4x4 but no difference. I took printer aparat multiple times to make sure everything is perfect and doesnt change with movements, and at this point I am 100% it's purely firmware issue.

gbkwiatt commented 4 years ago

Hi, something I read triggered me.

When people use TMC2208/TMC2209 drivers, they need to reverse their axis in the firmware (or reverse the connectors on the motherboard). Can it be that if the axis are reversed in the firmware, that the ABL is correcting this on a non reversed bed? My BL touch sees that my bed is low left, a high right. But when I print left the filament is almost scraped off, and right it is almost not fixed on the bed. => It is compensating the wrong place of the bed.

After 2 months fighting it kind of feels like that's what is happening right now. everything looks like it works but compensation is wrong. Currently I ended up having one side squished and other one printing in the air, but I can see Z axis moving but it's moving wrong ...

boromyr commented 4 years ago

@gbkwiatt Also I have been having this problem for a while now, the Z axis is not compensated enough. I am working with both version 2.0.7 and bugfix. To test that the basic process works I purposely tilted the bed like you, and trying a "blank" print the ABL correction was visible to the naked eye. I did a test by putting some obstacles on the bed in order to produce a positive error during the calibration: the result was satisfactory to the eye. I was thinking of adding a correction coefficient in the measured data, which increases the sensitivity, something like value * 1.02. Note: the probe I use has a standard deviation of about 0.001

gbkwiatt commented 4 years ago

I am still fighting, another night wasted. Can't figure it out,
so I have that: image

BUT, now it looks like it's overcompensating so where the bed is lower, nozzle goes even lower, but where bed is leveld and close to 0 like 235x235 corner, nozzle is too high there. what's going on ?

I was just checking with gap gauge, and it looks like visualisation shows, opposite ... where it shows bed is lower, it seem to be higher ... how ?

thisiskeithb commented 4 years ago

This issue has been closed (and original post has been edited to remove all useful information), so for best results getting help with configuration and troubleshooting, please use the following resources:

boromyr commented 4 years ago

and original post has been edited to remove all useful information

If the problem has been solved why remove the "useful information"?

thisiskeithb commented 4 years ago

If the problem has been solved why remove the "useful information"?

I'm not OP, but consider this issue dead. Join the resources linked above for further troubleshooting.

thierryzoller commented 4 years ago

BUT, now it looks like it's overcompensating so where the bed is lower, nozzle goes even lower, but where bed is leveld and close to 0 like 235x235 corner, nozzle is too high there. what's going on ?

Well that would be the case if the Z-Direction is inverted.

ellensp commented 4 years ago

This is not a support forum please take this else where.

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

After seeking help from the community, if the consensus points to a bug in Marlin, then you should post a bug report.

thierryzoller commented 4 years ago

I'm not OP, but consider this issue dead. Join the resources linked above for further troubleshooting.

It wasn't closed because OP said it's solved. It was closed because some of the mods thought it could be closed.

thierryzoller commented 4 years ago

@ellensp - He is clearly pointing towards a bug and has clearly invested time to assist Marlin. Wouldn't be the right pointer to tell him to open a new bug. This bug should have never been closed in the first place.

thisiskeithb commented 4 years ago

It wasn't closed because OP said it's solved. It was closed because some of the mods thought it could be closed.

It was tested and ABL was working as intended. See https://github.com/MarlinFirmware/Marlin/issues/17399#issuecomment-647817580. I also don't experience these issues on several printers running various genuine BLTouch versions.

Again, please use the resources linked above for further troubleshooting.

jermbe commented 4 years ago

If it was tested and works as intended. How come there are many people still facing the issue? As far as I see, the bug is still there.

We have (if I see correctly) ONE person saying it works and a dozen more who say it doesn't....

ellensp commented 4 years ago

One person, who is a high end Marlin developer, says it is working as expected. The original poster has removed all content. This issue is closed. If you personally have issues with bed leveling open your own issue, after getting advice from the support forums and checking it is not a bad configuration or old code.

thierryzoller commented 4 years ago

Oh - the "high end Marlin" developer says - all is fine, in a thread where multiple persons apart from the OP have raised problems. It's the Linus Model of OSS :)

For those new to reporting Marlin Issues, I will translate for you : " As we think this issue is resolved, if you experience the same problem than reported in 20+ related issues - please open a new one and we will be happy to look into it". <- there you go, it's not THAT difficult is it ?

sjasonsmith commented 4 years ago

There is no point discussion it in this thread. The entire description of the bug is gone. It is dead, and this thread should really be locked.

As for your issues @thierryzoller I know you have had issues with bugs in the past. I know you have filed well-documented bug reports that you feel were mishandled, and I probably agree with you.

Nobody WANTS to ignore real bugs. Leveling is an odd scenario where no matter how much time is spent, devs are unable to reproduce the reported issues. This leads to assumption that most are user error or mechanical issues. What we need is for someone who HAS leveling problems AND development skills to help solve the problem.

shitcreek commented 4 years ago

Locking thread because whether this is the same bug or an unrelated one, the original post has been striped of information by OP.

@gbkwiatt - Please create a new bug report if you are feel certain you are experiencing a bug. Thank you.