ABL on Delta starts at x0 y0 (instead of at edge of bed) and slants #4206
Labels
Milestone
Comments
|
`
|
|
Hi @alitai You should post your entire It will also help if you enable |
|
|
@thinkyhead - I've posted the entire configuration.h above. I've set the debug and will post it as soon as I can. |
|
|
One point I'd like to add is that when I disable the Auto Bed Leveling Feature (by quoting the line #define AUTO_BED_LEVELING_FEATURE) - the print works great, centered around the x0 y0 z0 point in the middle of the bed. |
|
I've been running the points as they appear in the log - they are indeed spread evenly on the bed. I don't know why the actual G29 shifts so they run in a single quadrant. And at a slant... |
|
For a test set your |
|
Alternately your |
|
@Blue-Marlin - Thank you - I changed Z_RAISE_BETWEEN_PROBINGS from 5 to 25. While jumping higher between probes - It still touches the x0 y0 z0 point, and then moves to the next point in the negative (-) X direction. Indeed it looks as if the coordinate system is messed up - but when I printed some items (without G29) and they printed well - and centered. Can the coordinate system be messed up only for ABL? |
|
@Blue-Marlin - If the MANUAL_Z_HOME_POS would be too high then issuing a G0 Y0 X0 Z0 would touch the bed? It doesn't. I calibrated the printer so the nozzle is paper thickness from the glass bed. |
|
Not for ABL. Because ABL touches 0,0 unplanned. |
|
I did install the latest today (about 2 hours ago). I'll see if there were any new commits since I last downloaded. Interesting about having a different coordinates for ABL. How does one go about zeroing XY&Z for ABL? |
|
Try setting |
ABL takes a given idealized XYZ from your GCode and modifies the XYZ to produce a corrected position based on the tilt of the bed. Since ABL uses only a single tilt across the whole bed, it's important that the sampled points be accurate and that there be very little irregularity in the bed when you probe. Too much irregularity will give strange results. |
|
@thinkyhead |
|
Ah… I'm not too familiar with the difference in Delta leveling. |
|
@thinkyhead The setting is at 9 points #define AUTO_BED_LEVELING_GRID_POINTS 9. It is similar to what I had before. @Blue-Marlin ABL worked well on RC6 (the print itself didn't, though) and on a previous Marlin firmware I have been using for more than a year. The Bed is Glass, is rather flat, and the endstops are finely adjusted using a screws so I have a rather well calibrated system (if I say so myself - a 50mm test jig comes out at 50.08mm and symmetric). I use Hiwin rails which make the 1515 rather stable. Since ABL worked on RC6 - I wonder what had changed since RC6? |
|
So I made a few movies of running ABL on the Bugfix version (where ABL fails) and the RC6 version (where ABL succeeds). ABL functioning on RC6: https://vimeo.com/173734690 A coincidental observation: Something during G29 is screwing up the Delta Coordinates - I stopped shooting the Bugfix movie right as it hit the GT2 belt. So to move it away from the tower I used the motor controls and discovered that the movement plane was completely off - a Y move resulted in a nearly 45 degree slant on Z. After using M28, the move was perfectly flat parallel to the bed plane. Slanted movement after G29: https://vimeo.com/173734614 This was shot with an updated firmware - updated to commit 4e84c80 from July 7. |
|
Would you mind posting the G29 log from 1.1.0-RC6 so I can compare it to the log from RCBugFix? Meanwhile I will look more closely at the code. We did a huge amount of cleanup on bed leveling, and somewhere in the process we clearly overlooked something. |
|
@thinkyhead Thank you - I will do it in an hour or so when I get back. |
|
Here is the Log of the G29 from RC6:
|
|
From the video it looks like a weird assortment of probe points. Are they all within a single quadrant of the bed, or does it probe elsewhere? Are you using the same |
|
So far in my examination of the G29 code nothing is jumping out as an obvious bug. I think it must be someplace in-between, maybe.
This is making me think it would be nice to have an LCD option to cancel |
|
@alitai I've created a branch for testing where I can add more logging to figure this out. I already did a few tweaks to it, so give it a try and see if it works any differently: https://github.com/thinkyhead/Marlin/tree/th_delta_debug_homing_leveling I will add more logging to that if needed, and hopefully we'll figure it out quickly. |
|
|
I actually tried to use the same Configuration.h. But the one I use now is different - there are quite a few differences between the RC6 and the Bugfix files - Hitachi character set was changed from Japan to Japanese; there were additional Z probe Raise parameters in RC6 that don't exist in the Bugfix, etc. |
|
@thinkyhead So I looked at the LCD - Indeed there is a mismatch between the LCD and where the effector/hotend is. For example, it starts off at Y=-49 (which should be close to the edge of the bed) - but the effector is at Y=0. So the first probe should be X=31 Y=-49 but it ends up being X=0 Y=0. |
|
@AnHardt Another change we made recently was - for deltas that had a specific (50, 100, 150) Z-before-probing value, the effector would move down to that coordinate. But now we don't move down, only up, so we might have lost that initial move. (Or, with delta and/or Z max machines, I might have made an exception and still lower to that point.) I'll have to peek at the code to remind myself. Anyway, perhaps that initial lowering is helpful. |
So I probed at a few points outside the quadrant the ABL is stuck in such as x-35 and y-35 and it worked well. The nozzle touched the bed at the proper location - and returned properly. |
a test we could ask for adding an endstop_adj of a few mm to all axes to free the endstops before another move can happen. Or we could simply try: G28 I tried this - It doesn't solve the problem - what should I be looking for? |
|
I hoped for a straight correct move from [0,0,z_max-x] to the first probe point in G29 with x bigger than a few 1/10mm. :-( |
|
Tried quoting out - And it made no difference. :-( |
|
Ok. Let's see what's going on. |
|
@thinkyhead @AnHardt I do apologize. I am rather new on GitHub and didn't know that the AnHardt#56 was a build for me to try. I was actually looking at this thread daily for the next set of instructions. I will test this later today. |
|
I am not sure how to use this. I tried showing the code for commit AnHardt#56 as full code and downloading it. Added it to the RCBugFix and to the AnHardt code tab download - and in both cases got a "conflicting decleration 'volatile boot_wait_for_heatup'" compiler error. In the main AnHardt code tab - I don't see the report_current_position() calls that the #56 has... |
|
Tried quoting out the lines that compiler was unhappy with and made it even less happy... I guess the question is how do I find and download the code that goes with the #56 commit? |
|
@alitai At the top, notice that the name of the branch that AnHardt#56 comes from is rep-pos-delta-G29 (https://github.com/AnHardt/Marlin/tree/rep-pos-delta-G29). Download the ZIP from there, or you can check it out with Github Desktop, if you have that installed. |
|
@thinkyhead - Thank you - downloaded it and it worked. Posted the log and configuration.h into the AnHardt#56 message. BTW - On a side note, the configuration.h version may need to change as CONFIGURATION_H_VERSION 010100 no longer compiles with the code. Missing some declarations. |
|
@AnHardt figured it out - the effector is trying to move to the initial point while still homed. So the carriages hit the endpoints. A move to point X:31.00 Y:-49.00 Z:243.70 E:0.00 Count X: 86168 Y:86248 Z:85995 remains at X:0 Y:0.... In the past, the effector used to go down prior to probing. Is that settable in configuration.h? There is a workaround for now - running: works, and completes a full G29 cycle. Thank you @AnHardt, @thinkyhead, @Roxy-3D and @Blue-Marlin for all your help - you guys are awesome. |
|
Should I close this issue - or should we close it only after the issue is resolved in code (or configuration)? |
|
@AnHardt - I apologize again - You had asked about this before–
Only now do I see what you meant - when the effector tries to get to the coordinates it does hit the endstops. you were on to the problem 4 days ago... |
Yes, this was recently (unintentionally) changed. It was assumed that the initial height ( Clearly on a DELTA the initial "raise" still needs to be applied even if it is lower. The |
|
#4303 is almost the right idea, but.... Background: I believe the upper part of a delta's total build volume is actually a cone, so the full volume looks like a pointy rocket. Marlin currently supports making full use of that limited upper-region of the build area, as long as you don't try to move any of the carriages beyond their upper limit. So you can print a taller Chrysler Building than a cylinder. That said (and apropos of the corporate engineering lab) I think it's good to place safety margins. But… I think enforcing a fixed height based on where the nozzle can reach the outer edge is probably too strict. Compare to software endstops on a nice square Cartesian. They are easy to enforce, but ultimately meaningless on a delta. Instead with a delta we have to constrain based on the radius (fortunately no static float get max_cylinder_z() { . . . } // highest Z with usable full radius
/**
* Like clamp_to_software_endstops, but for delta moves.
* Alters the xyz before use so hi and lo level axes are in sync.
* Constrain totally screws up your print in progress, so slice with care!
*/
void clamp_to_delta_volume(float &xyz[NUM_AXIS]) {
static float max_cylinder_z = get_max_cylinder_z(); // can rod trim change this?
float max_radius = delta_radius; // the full usable radius
// above the max cylinder z? (only needs recalculation as Z changes)
if (xyz[Z_AXIS] > max_cylinder_z) {
// proportion at Z [e.g., 1-(110-100)/(150-100)==1-1/5==0.8]
max_radius *= 1.0 - (xyz[Z_AXIS] - max_cylinder_z) / (Z_MAX_POS - max_cylinder_z);
}
// point outside the radius?
float r2 = sq(xyz[X_AXIS] - CENTER_X) + sq(xyz[Y_AXIS] - CENTER_Y);
if (r2 > sq(max_radius)) {
float prop = sqrt(r2) / max_radius;
xyz[X_AXIS] = CENTER_X + (xyz[X_AXIS] - CENTER_X) * prop;
xyz[Y_AXIS] = CENTER_Y + (xyz[Y_AXIS] - CENTER_Y) * prop;
}
} |
|
@thinkyhead since #4303 is merged, can we close this ? |
|
RC7 works really well on my Mini Kossel G28 followed by G29 work without hitting the endstops - Thank you all for the excellent work! |
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi - Still working on getting the BugFix version to work. Downloaded a new RCBugFix branch today and am getting an issue with the ABL functionality. The probing starts in the center (X0 Y0) and moves to the rear right quadrant, and does so at a slant.
I am using the Zmin pin and the nozzle as a probe (with a Trinket Based FSR detector), so offsets are all '0'.
Thanks,
Assaf
Bed Leveling Configuration
The text was updated successfully, but these errors were encountered: