G29 Issue #5898
Comments
|
Please use the latest RCBugFix as many issues were resolved. |
|
I'm currently using Bilinear Bed Leveling... here is a snip from my configuration.h file //===========================================================================
//============================ Auto Bed Leveling ============================
//===========================================================================
// @section bedlevel
/**
* Select one form of Auto Bed Leveling below.
*
* If you're also using the Probe for Z Homing, it's
* highly recommended to enable Z_SAFE_HOMING also!
*
* - 3POINT
* Probe 3 arbitrary points on the bed (that aren't collinear)
* You specify the XY coordinates of all 3 points.
* The result is a single tilted plane. Best for a flat bed.
*
* - LINEAR
* Probe several points in a grid.
* You specify the rectangle and the density of sample points.
* The result is a single tilted plane. Best for a flat bed.
*
* - BILINEAR
* Probe several points in a grid.
* You specify the rectangle and the density of sample points.
* The result is a mesh, best for large or uneven beds.
*/
//#define AUTO_BED_LEVELING_3POINT
//#define AUTO_BED_LEVELING_LINEAR
#define AUTO_BED_LEVELING_BILINEAR
/**
* Enable detailed logging of G28, G29, M48, etc.
* Turn on with the command 'M111 S32'.
* NOTE: Requires a lot of PROGMEM!
*/
//#define DEBUG_LEVELING_FEATURE
#if ENABLED(AUTO_BED_LEVELING_LINEAR) || ENABLED(AUTO_BED_LEVELING_BILINEAR)
// Set the number of grid points per dimension.
#define ABL_GRID_POINTS_X 3
#define ABL_GRID_POINTS_Y ABL_GRID_POINTS_X
// Set the boundaries for probing (where the probe can reach).
#define LEFT_PROBE_BED_POSITION 50
#define RIGHT_PROBE_BED_POSITION 250
#define FRONT_PROBE_BED_POSITION 50
#define BACK_PROBE_BED_POSITION 225
// The Z probe minimum outer margin (to validate G29 parameters).
#define MIN_PROBE_EDGE 10
// Probe along the Y axis, advancing X after each column
//#define PROBE_Y_FIRST
#if ENABLED(AUTO_BED_LEVELING_BILINEAR)
// Gradually reduce leveling correction until a set height is reached,
// at which point movement will be level to the machine's XY plane.
// The height can be set with M420 Z<height>
#define ENABLE_LEVELING_FADE_HEIGHT
#endif
#elif ENABLED(AUTO_BED_LEVELING_3POINT)
// 3 arbitrary points to probe.
// A simple cross-product is used to estimate the plane of the bed.
#define ABL_PROBE_PT_1_X 15
#define ABL_PROBE_PT_1_Y 180
#define ABL_PROBE_PT_2_X 15
#define ABL_PROBE_PT_2_Y 20
#define ABL_PROBE_PT_3_X 170
#define ABL_PROBE_PT_3_Y 20
#endif
/**
* Commands to execute at the end of G29 probing.
* Useful to retract or move the Z probe out of the way.
*/
//#define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10"
// @section homing
// The center of the bed is at (X=0, Y=0)
//#define BED_CENTER_AT_0_0
// Manually set the home position. Leave these undefined for automatic settings.
// For DELTA this is the top-center of the Cartesian print volume.
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS -15
#define MANUAL_Z_HOME_POS 0 // Distance between the nozzle to printbed after homing
// Use "Z Safe Homing" to avoid homing with a Z probe outside the bed area.
//
// With this feature enabled:
//
// - Allow Z homing only after X and Y homing AND stepper drivers still enabled.
// - If stepper drivers time out, it will need X and Y homing again before Z homing.
// - Move the Z probe (or nozzle) to a defined XY point before Z Homing when homing all axes (G28).
// - Prevent Z homing when the Z probe is outside bed area.
#define Z_SAFE_HOMING
#if ENABLED(Z_SAFE_HOMING)
#define Z_SAFE_HOMING_X_POINT ((X_MIN_POS + X_MAX_POS) / 2) // X point for Z homing when homing all axis (G28).
#define Z_SAFE_HOMING_Y_POINT ((Y_MIN_POS + Y_MAX_POS) / 2) // Y point for Z homing when homing all axis (G28).
#endif
// Homing speeds (mm/m)
#define HOMING_FEEDRATE_XY (50*60) |
|
(not relevant anymore since the comment was fixed) |
This is your probe rectangle. If it's not getting to where you want, check/change these. |
|
I did. I saw it just as I hit the post button....i deleted it and re-posted... You are quick. Lol |
|
My printer does not have any issues reaching the probe positions, my bed is 300x300mm. My problem arises once I go to print. It is as if it over compensating for the tilt of my bed. It seems to be touching the build plate on one corner but floating high above it on the opposite corner. |
|
Give the |
|
Right now the Please let us know the results if you try Did you try the latest RCBugFix? If the latest RCBugFix didn't fix the problem then another option is to try a 5x5 grid. That's fixed this problem for a couple of people. |
|
I was reading through the read-me for devel-ubl and it seems like there is a much longer process for leveling the bed. Am I going to need to run through this procedure every time I use my printer? |
|
Just use M500 to save it to EEPROM and from there out it'll be restored from EEPROM on power up or when reset. |
In an hour of time... Your bed (with a particular piece of glass) will be perfectly tuned. Much of that time is spent doing the initial probing and doing several Mesh Validation Prints. And the first time you are doing it... It is cool to watch. But when you are done, your mesh is saved in EEPROM and if you choose to configure the system this way, you can have the correction applied at power up and/or reset. You don't need to do anything again. In reality... after a few weeks, you might notice you have a spot that is a little too high or low. You just spend 10 seconds to edit that spot and save the mesh. You should be good for another 2 or 3 weeks. |
thinkyhead
added
Bug: Potential ?
Needs: More Data
|
It would be good to try and address / investigate the bug in the bed leveling code rather than diverting users to the UBL branch, especially as this appears to be consistent with 2 or 3 other issues reporting the same thing. We should determine whether it's a problem with the bed leveling code or something at a more general level that would also affect future-merged UBL. Potentially related? #5616 #4612 #5437 #5890 #5804 #5666 #5694 #5727 |
|
I have had this issue with ABL in every version (except for |
|
Is there anyway for me to get more information from G29 than what is provided through G29 V4? I want to try to troubleshoot this. I want to know if it is an issue with Marlin or with my hardware setup. |
|
I think I saw a DEBUG switch for G29. Also I'm not sure if you are allready doing it this way, but you don't need to start a print to test G29. Just do a G29 and the move the head with the host of your choice or the controller. You can then see the leveling applied to you movements and check the results using a piece of paper. |
|
I hope that this is helpful... I'm not sure it means much to me but here is my G29 V4 output with DEBUG enabled. I also ran M48 V4 S and got the following: Edit: Placed Code inside code block. @Tanoo Thanks for the help. |
|
Can you edit that with the |
|
@aaronthomaswebster You said you are using Bilinear but that output is showing a linear matrix. Did you switch your levelling method? Some questions to all: I don't understand how the measured points can be -1.72 to +0.04 to +2.04 from one corner to the other while the "Corrected Bed Height vs. Bed Topology" shows +0.4 to +0.28 to +0.38. Can anybody explain what those values are supposed to represent? |
|
@oderwat I just checked, and yes I did switch to Linear. here is the output i get on Bilinear setting. |
|
Is there a way to repeat G29 and test it against the created mesh to make sure it is really level? |
|
I have the same problem - my nozzle is too close to the bed on the right side, and in the back right corner it is especially bad. I'm using bi-linear with a 7x7 grid. Final output from G29 looks like this: I have tested by running G28 then G29, then moving the nozzle to a selection of the measured points, moving to Z0 then using M114 to get the step count, which I divide by the number of steps/mm (399 on my printer). The actually stepper offset always matches the expected offset e.g. at X165 Y165, point 5,6 in the table, where the correction should be 0.13mm, M114 tells me I'm at 53 steps, which should be spot on. I also took a few samples between probed points and the steps look as I would expect. Nevertheless, when actually printing, the right side is so near the bed the extruder motor grinds the filament because it can't extrude. The left side prints fine, and if I baby-step to try to fix the right the left will stop sticking to the bed. Happy to try anything I can to help diagnose this further. I've already disabled Z fade height (although I never used it). Ben |
|
Hi, I have the same problem as benlye above. Thanks, |
|
Just had time to do a little more testing. Thought I would start by trying to print just a snippet of gcode from a file - basically the skirt up until it reaches the back right, then run an M114. Something is definitely screwy. The initial layer height is 0.12mm. At the end of the print code, when it runs M114, the nozzle position is X204.036, Y201.723 and the height should be 0.12 above the bed. The M114 output at the end is this: But, If I then issue G1 Z10 followed by G1 Z0.12 I get a different number of steps: The difference is only small - 28 steps = 0.07mm - but why is it there at all? Is there a problem applying ABL corrections during moves? This is the gcode I ran: Ben |
|
Are you sure that your gcode stream include some sort of synchronization? Use m1 or m400 just before m114 to insure that no move are still in the queue... m114 will execute immediately while some move located before in the gcode stream are pending in the move queue... Please do not conclude anything about position without synchronization... |
|
Just for fun, re-run you gcode again... wait for prompt then re-issue m114 as the first command after your gcode script... |
|
@lrpirlet Funnily enough, I was thinking exactly that on my way to work. I can't recall if I ran another M114 outside the gcode to validate the one in the gcode before I did the next move or not. I will definitely re-test, but it won't be possible until I get back from work later today. In any case, the small discrepancy I saw in steps is not enough to make the difference I see in printing (which appears to be >0.1mm). I'm just trying to think of ways to try to diagnose what is going on. I'm happy to take any suggestions or other tests and checks to help try to figure out why I and others are seeing this behaviour. |
|
@Bob-the-Kuhn well you still don't get it, but I tried. Hint: "Z-Offset = Distance from nozzle tip to probe trigger (needs to be constant to create a valid measurement)" "Z-Compensation = Value of the ABL correction (is changing and calculated from probed points)". |
|
A mighty fine discussion of apples vs. oranges. I agree with the above statements. My comments were aimed at when having a constant Z offset mattered and when it didn't (assuming that the probe wasn't the source of the inconsistencies). |
|
Seems to me that G29 should have 3 offsets, z, x, and y between the nozzle and the probe. As I understand, the z correction is applied to the nozzle position (x,y) but it is calculated from data when the probe is at position (x+dx,y+dy). In my printer it doesn't matter since both dx=0 and dy=0, but commonly both will not be zero. |
|
I know that the issue that I have with Bilinear ABL is, it was air printing in the position of X120 - X185 (worse when closer to the edge (X185)) and was scraping tape from X0 - ~X70. I seriously thought my probe was inconsistant. I ran repeatability test at every point that it would probe in the 3x3 grid (9 points). I gathered data from the repeatability test ever 5 different times and plotted them in Excel. I was looking for an issue. I found that my probe was within .003mm throughout all of that. My glass and bed is fairly flat and can get it to print ok without any software bed leveling. MBL has worked better than without it. I never thought to check the Z offset at each point. Mainly thinking that my probe isn't moving. I have more testing to do.. Thanks guys! |
|
@BillStruve - during G29 the head is moved to (X, Y) which means the probe is at (x+dx,y+dy). G29 then saves (x+dx,y+dy) and the probe results. During moves the planner applies the probe results when the nozzle is at (x+dx,y+dy). |
|
@BillStruve - can you point me to the info on your print head system? I've heard of systems where the nozzle is the sensor but I haven't found any. How repeatable is your system (M48 type results)? |
|
What inductive sensors are you guys using? I'd like to play with a couple and see how they perform. |
|
I use this one: It seems to work very well, with good repeatability and accuracy across the bed. For example: The worst range I've seen across a 10-probe sample is 0.015, with SD of 0.004899. |
|
@Bob-the-Kuhn please get your terminology right "Z-Offset" is what is stored with M851. This needs to be constant on the physical side for any type of ABL to work. What I am talking about us not comparing apples with oranges and can't be ignored. It simply is the explanation for problems real people have with their real systems. @benlye try the following to see if your system reports constant z-offsets: Get the four extrem points for you abl measuring from the configuration. For example X20 Y20, X200 Y20, X200 Y200, X20 Y200. You can also just choose 4 points in the corners of your bed. Then do the full procedure below for each of those points and for X and Y at half your bed size (aka middle of your bed), for example at X110 Y110. Using your values for the 5 different positions instead of 110 in the example below. This will measure at which height relative to the nozzle the probe does trigger at your chosen points. The value should be as accurate as your M48 Sensor results and constant over all points. If there are bigger differences at different bed positions your z-offset is not constant and ABL can't not work probably. If that is the case you need to find the problem with your hardware first. |
|
Shouldn't that be |
|
@Tannoo not with a probe setup, they usually (always?) probe at the center of the bed. It also doesn't matter here. It is only needed to initialise the positioning. The important factor is that you G1 and G30 to the same point. This is the only way you can check if your z-offset (aka M851 aka distance between nozzle and probe trigger point) is constant over your whole bed. This is the basis for everything else and as important as the probe repeatability error. I made a small correction to the procedure because you only need to reset the z-offset and initialise the coordinates once. |
|
Ok, but a G28 with or without probe will put my nozzle at 0,0,0. Center of the bed is roughly 80,80. I'm just getting it clear on what you want done for when I get to do it later this morning. |
|
Well, with the probe, the nozzle doesn't get that close to the bed. Nevermind about the swap. I haven't used the probe for quite some time.. You'll have to forgive me. |
|
|
|
Well, what do you know, my Y_PROBE_OFFSET_FROM_EXTRUDER was out by 2mm! I just reset and recalibrated by bed settings as accurately as I think I can. I'll repeat some tests later today, including checking the Z-offset in each corner as well as the centre. |
|
@Bob-the-Kuhn I'm confused, how can "G29 then saves (x+dx,y+dy) and the probe results" if it does not know dx and dy. |
|
@BillStruve - thanks for the info. On (x+dx,y+dy) - I thought you meant dx was the X offset of the probe and dy was the Y offset of the probe. |
|
@oderwat - attached is the logic sequence I went through to arrive at my "constant M851 Z offset is not needed when using bilinear leveling" conclusion. Please review. |
|
@Bob-the-Kuhn Sorry about that, I did a (too) quick look at Configuration.h and did not find Y_PROBE_OFFSET_FROM_EXTRUDER, X_PROBE_OFFSET_FROM_EXTRUDER, so I thought that they were not specified. Boy, my memory is going since I had set both of these to zero a couple of months ago! |
|
I need to do a few more prints, but the few tests I've done since fixing my probe X and Y offset values and re-calibrating the bed settings have had much more consistent first layers. Before now, if I printed a skirt it would almost never come off in one piece because it would be nonexistent in one corner. For the last few prints it is paper-thin (my initial layer is 0.12) and consistent all the way around, and comes off in one piece. :-) EDIT: Just to be clear, by 're-calibrating the bed settings' I mean that I adjusted some settings relating to bed / positioning in configuration.h, namely the travel after homing settings, as I found that the center coordinates were slightly off the actual bed center. I did not adjust the levelling screws. |
|
I have an ignorant question.... is G29 all i need to do to enable auto bed leveling or is there something to do after G29 to apply the leveling? |
|
G29 automatically enables auto leveling. You can use M420 to enable/disable auto bed leveling once G29 has been run. |
|
hey guys, I've decided to double my 3d printer into a PCB milling machine and have run into a few issues trying to issue specific commands appended to the G29 procedure. I need to probe as many as 15 points in specific area's on the PCB so that I can use them to mill out my designs. It also saves me trying to probe the entire bed and reduces time. I just can't seem to get it to play ball. If I send G29 X8 Y8 L25 R65 F110 B160, It will only probe out the 1st 2 rows of 8 before resetting itself. I have AUTO_BED_LEVELING_LINEAR set which I believe allows me to modify the G29 parameters in this way. I thought it might be a memory issue because the latest release uses 97% of flash memory but I revert to previous that used 92% and i still get the same issue. It this a related issue? i am running on an Anet A8 machine. |
|
@jamhot1 — Are you using 32x microstepping? What kind of Z feedrate are you using between probes? Try reducing your feedrates to see if it prevents the reset. |
|
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. |
I have built my own CoreXY printer and I am running into issues with
G29. It does not seem to be working... My printer is trying to compensate but seems to be too close to the bed in the front right and too far away in the back left. I could post all my firmware settings but I was hoping to ask for some advice first.I am running Marlin 1.1.0-RCBugFix - 6
The text was updated successfully, but these errors were encountered: