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

About Auto Bed Leveling #5780

Closed Jolly2015 closed 7 years ago

Jolly2015 commented 7 years ago

Hello, I got a stupid question, after my delta executed G28/G29, the result is unsatisfactory, as this situation, should I run G29 again or any other methiod?Thanks

Bob-the-Kuhn commented 7 years ago

Which bed leveling method did you use?

The best explanations of the four options are: http://marlinfw.org/docs/features/auto_bed_leveling.html http://marlinfw.org/docs/configuration/configuration.html#mesh-(manual)-bed-leveling

The AUTO_BED_LEVELING_BILINEAR is used when the bed isn't perfectly flat. It'll compensate for peaks & valleys. That's the one I'm using.

AUTO_BED_LEVELING_LINEAR & AUTO_BED_LEVELING_3POINT assume the bed is perfectly flat but is tilted.

If you're using AUTO_BED_LEVELING_BILINEAR or AUTO_BED_LEVELING_3POINT you may try to increase the number of points that are probed.

Curiosity - what's your definition of unsatisfactory?

egenjohn commented 7 years ago

@Jolly2015 not a stupid question, I'm dealing with similar issues on my Kossel mini. Running G29 probably won't result in anything different unless your probe doesn't give consistent results. @Bob-the-Kuhn AUTO_BED_LEVELING_BILINEAR is the only option if DELTA is defined. I have a feeling that the issues I'm running into are a matter of sorting out the configuration. Where I left off last night was that after a z-probe I could get a consistent result with the paper test over most of the bed, except near maximum Y where I would suddenly get a couple of millimeter gap.

Bob-the-Kuhn commented 7 years ago

I was wondering about delta and auto bed leveling. It wasn't obvious to me if any/all was available to a delta.

@egenjohn - do you see anything strange when that area is probed?

Does M420 V show anything strange in that area? Does doing M48 (at a single point) in just the bad area show anything different than doing one in a good area?

About the only real suggestions I have are:

Long shot - I've seen some issues lately where the stepper cables were causing interference. Maybe move some cables or try a stronger pull up on the Z probe signal. Most people use the 10K internal pull up in the Atmel part. Maybe a 4.7K or a 2K external resistor would help.

egenjohn commented 7 years ago

@Bob-the-Kuhn Everything looks normal. But to be honest, I've only been trying RCBugFix for about a week, so I'm still getting comfortable with it. I was running Johann's branch for a very long time without problems. I don't get a lot of time to mess with the printers (such is life) but I'll see if I can try your suggestions tonight.

Jolly2015 commented 7 years ago

@Bob-the-Kuhn ,I used AUTO_BED_LEVELING_BILINEAR and define FIX_MOUNTED_PROBE,uses the nozzle to probe,I remembered there was a function to autocalibration(AUTOCALIBRATION_PRECISION) in marlin old version,does it's canceled or replace in RC version? Anyway,I'll try to increase probe points and pull the Zprobe signal up to 4.7K.My default homing speed is 3000,and use OMRON micro switch, so I think the homing speed is OK. Do you have anyother suggestion? @egenjohn , does your issue was solved?

Bob-the-Kuhn commented 7 years ago

I've only been playing with auto bed leveling for a couple of weeks. I couldn't find any reference to AUTOCALIBRATION_PRECISION in 1.02 or later.

The other thing to try is the latest RCBugFix. Maybe your problem has already been solved.

Blue-Marlin commented 7 years ago

Auto-calibration for deltas was and is unique to the jcrocholl branch (https://github.com/jcrocholl/Marlin) and its children.

Bob-the-Kuhn commented 7 years ago

Thanks

Jolly2015 commented 7 years ago

@Blue-Marlin ,OK,thanks,get back to the top of topic,for DELTA, the result is unsatisfactory after G29 was executed.is there any remedy for the bad result?or what's the condition must be satisfy before using G29 on DELTA machine?

Blue-Marlin commented 7 years ago

@Jolly2015 Sorry. I'm not a real delta expert - I have just read into some more different Marlin branches.

Most likely reasons are:

Where the last two points reason a different tilt of the print-head at different places, which means wrong measurements by the probe (if the nozzle is not the probe) and can't be calibrated in software - but have to be corrected in hardware.

3dGriff commented 7 years ago

@Jolly2015

I hope you're working out your issue, can you elaborate a bit on what specifically you are unsatisfied with?

For instance, is the nozzle height not correct? Or is it simply printing unevenly? If you are concerned with the accuracy of your probe you can enable:

define Z_MIN_PROBE_REPEATABILITY_TEST

In configuration.h and execute M48. This will produce a standard deviation that will give you an idea of how well your probe is performing.

If you are having issues with the nozzle height and are sure you have your offsets correct, make sure you are issuing a Z0 (G1 Z0) after your post probe homing. G28 does not apply the proper offset so Z0 must be executed.

I hope this helps. Otherwise, @Blue-Marlin has suggested other likely possibilities.

egenjohn commented 7 years ago

@3dGriff what would be considered an acceptable standard deviation from M48? Running M48 at five different points (center and four around the perimeter) yields these results for me: 0.000000 0.004580 0.004580 0.004911 0.004904

egenjohn commented 7 years ago

@Jolly2015 No, I'm still having issues. I saw some behavior last night that doesn't make too much sense. Particularly concerning ABL_GRID_POINTS_X. Changing it from 5, which placed the grid pretty well in the center of my bed, to 7 shifted the grid in the +Y direction and I had to set Y_PROBE_OFFSET_FROM_EXTRUDER way higher than it should be to keep it on the bed. Trying not to hijack your issue though. Just trying to collect information that may be mutually beneficial.

3dGriff commented 7 years ago

@egenjohn yes those numbers should give you a standard deviation of 0.00019 which tells me that your probe is working great so I'd shift focus from that to simplify your problem.

Just out of curiosity, are you printing directly onto your build plate? Do you have glass or PEI on the surface? Also, does the nozzle make contact with the bed during probing?

When you send the hot end to the bed does it pass the 'paper test'?

egenjohn commented 7 years ago

@3dGriff my surface is a 170mm diameter glass plate with a sheet of BuildTak on it. The probe extends well below the nozzle when deployed, so no, the nozzle doesn't contact the bed while probing. My typical adjustment procedure is to use M851 to adjust the x probe height at the center of the bed (0,0) in order to pass the paper test. I then move to the perimeter to verify. It's this verification that I can't get to pass. Maybe worth noting, this isn't a new printer. I built it over a year ago and it's been working great on Johann's (very old) branch. So, I'm hesitant to blame hardware.

3dGriff commented 7 years ago

Gotcha, thanks for the clarification on that. Its admittedly been a while since I've calibrated a delta, however, if it is raising or lowering as it nears the edges it's probably best to verify your delta radius.

So back to what @Blue-Marlin said earlier, some things can't be compensated for in the software.

Jolly2015 commented 7 years ago

@Blue-Marlin @3dGriff Thanks for yours reply. I am so moved with yours helps when I fall into trouble. and now , my delta running well(I just adjusted my probe and rod).

thinkyhead commented 7 years ago

Were the Delta Calibration menu items of any use in your testing?

Jolly2015 commented 7 years ago

@thinkyhead using level bed and adjust z offset and store the date items, and must keep the same lenth of six push rods

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.