Marlin: Unexpected behavior 3 point ABL for CoreXY (RCBugfix)

[joris57]

Marlin configured for CoreXY printer with 3 point ABL.

• G28 (safe homing) and bed/head movements behave as expected.
• G29 shows strange behavior
  
  
  
  • head/probe crashes in both X and y directions
  
  
  • z-probe is at no point in the process raised or lowered
  
  
• M114 reports head at (x=65,y=71) as exptected after the G29, however, physically the head is somewhere at (0,160).

Configuration.h.txt
debug.txt

[thinkyhead]

With recent cleanup in the area of bed leveling, it looks like a bug slipped in. Will scour that log soon to see what's going on and try to patch it today.

[thinkyhead]

I'm not sure why the Z raise isn't occurring. The log shows that it's "trying" to do the Z raise. It might be getting interrupted due to some kind of endstop testing.

I added new logging to RCBugFix today. If you could run G28 and G29 V4 again with the leveling debugging enabled, perhaps it will provide the clues we need.

[joris57]

Attached the new logfile.

Update:
Some form of probing seems to happen, only not in the form I would expect, i.e. move to one of the three points and double-dip the probe then go to the next point.

Most surprising however is that the points being moved to/probed are NOT (80,80), (80,100) and (100,80) as per the config, but something else (close to X=0 as I see the X endstop trigger).

Also the physical endposition (after G29) is vastly different from what is being reported by M114 (here also the x-endstop is triggered).

debug.txt

[smoki3]

This the same i reported last week.
https://github.com/MarlinFirmware/Marlin/commit/ea0dbee3c93fa221b8c7d3b6c566d635eae2afd2
I added logs an video to the commit. Already with the new debug.
I using the abl linear

[mperdue]

This is the same issue I'm having. I've tried all 3 leveling methods and they all fail like this.

[thinkyhead]

@joris57 @smoki3 @mperdue

A few tweaks have been made to bed leveling over the past couple of weeks. There's still an issue with BLTouch probes, but I think that's close to being resolved. Do you see any improvement in RCBugFix currently with respect to this particular issue?

[mperdue]

@thinkyhead It seems to wander a bit more before exceeding a limit but it still doesn't work.

debug-out.txt

[smoki3]

I still got the Y movement.

[thinkyhead]

@smoki3 @mperdue

• Are you able to determine the most recent commit (or date) where it still works? (I don't see anything in https://github.com/MarlinFirmware/Marlin/commit/ea0dbee3c93fa221b8c7d3b6c566d635eae2afd2 that would directly contribute.)

[smoki3]

I use linear too

[thinkyhead]

@smoki3 Ok, good to know. Apart from the issue of leveling, if you skip G29 everything behaves as it should?

[smoki3]

Yes. G28 is working. But i not tested all because in my configuration I need g29

[thinkyhead]

@smoki3 I'm asking if printing, or at least G1 movement, works properly if you skip G29.

[smoki3]

Not tested

[thinkyhead]

@joris57 @mperdue Does printing (or at least G1 movement) work properly if you skip G29?

[mperdue]

@thinkyhead G28 works fine. G1 also works fine. I'll try a print without G29 shortly.

Edit: Printing without G29 works as well as can be expected without a level bed.

[mperdue]

@thinkyhead If you can direct me to a place to download previous versions of rcbugfix I can run through them to see which is the last one that still works. We've already determined that Sept27 and Sept28 have the problem and that the version I'm running (somewhere near Sept16) does not have it.

[thinkyhead]

Printing without G29 works as well as can be expected

Good! I just want to make sure we're not looking at some general issue with the motion code.

[thinkyhead]

From the evidence gathered so far it sounds like a weird endstop or probe issue, but I can't think of any reason why CoreXY would be uniquely affected. I will continue to look into it!

[thinkyhead]

@mperdue I recently patched an issue related to endstops being read incorrectly. Try the current code to see if that makes any difference with your issue.

[mperdue]

@thinkyhead - I've tested it with Linear and Bilinear and it runs through the points without any problems. I haven't printed anything yet so i can't say that it applies the plane or mesh correctly but it does go through the steps as you would expect without exceeding the limits.

I have a couple of questions about bilinear.

1) What is the optimal setting for the number of points to probe in the X and Y? I have a 400mm x 300mm bed size so I'm sure it will need more than 3 x 3 to create a mesh that is usable.

2) Should the probing be done prior to each print, each session, or just periodically when you suspect it has changed? Having more probe points will, obviously, make it take longer to map so I need to balance things with respect to the time spent probing the mesh. If it only needs to be done at the beginning of the day's session that would be great.

[mperdue]

I guess you made changes to the fans as well. I didn't notice the fan was no longer running and melted my extruder mount and clogged the extruder...

[thinkyhead]

What is the optimal setting for the number of points to probe in the X and Y?

As a general guideline, divide the bed up so the grid squares are about 40x40 or smaller. So on a 200x200 bed you'd use at least a 5x5 grid, if not up to an 8x8 grid. In future it will be possible to save the grid to EEPROM, so you won't have to probe on every print, and then you could go even more fine-grained.

[mperdue]

@thinkyhead Just some feedback based on the current rcbugfix. This version seems to be working pretty well. I printed a fairly large test part that would normally have had issues with thin and thick areas on the first layer. I used bilinear mesh leveling probing an 8 x 6 grid on my 400mm x 300mm bed allowing a 50mm border on all sides of the bed. The first layer thickness was consistent across the entire base of the part. The only thing I noticed is that the Z probe offset is different with this release from the previous one i was running. Previously my Z offset was -1.21mm for my BLTouch. With the new version it's going to be closer to -1.4 (I don't have an exact value yet as I haven't finished tweaking things but that's pretty close.) Reloading the previous version reverts to the -1.21mm offset. Not sure what is causing that.

[thinkyhead]

Reloading the previous version reverts to the -1.21mm offset. Not sure what is causing that.

How are you determining the probe-to-nozzle offset?
Don't forget to reset that EEPROM with M502+M500 when needed.

[mperdue]

@thinkyhead The initial probe to nozzle offset was determined by the relative position of the probe to the nozzle tip in my 3D design file. I enter that value in the configuration.h file then I home the printer and lower the z until it either touches the bed or stops moving. I use the actual measurement obtained to calculate the required offset and make changes with the control knob, then save it with M500. I repeat this to verify to offsets calculated are correct and make changes as needed.

I guess I'm not really concerned if the value has changed as long as it is consistent.

oh, and my previous message has a typo. The new setting is -2.4 or about twice the previous offset.

[mperdue]

It also seems like the extrusion is a little heavier on the rcbugfix from yesterday as compared to the previous version I was using. Again, it's not a big deal as I can tweak the configuration file or dial it back with Simplify3D.

[thinkyhead]

seems like the extrusion is a little heavier on the rcbugfix from yesterday

Marlin is still moving E based on the steps per mm setting as it always has.
Did you store a different steps-per-mm value in EEPROM versus the default?

[thinkyhead]

The new setting is -2.4 or about twice the previous offset.

So the probe is triggering at a different height? The procedure I follow is to start out with a good solid G28 so that the nozzle is at bed height when Z=0. Next I raise the nozzle to make room for the probe and slowly move the nozzle down, in 0.1mm steps, until the probe triggers. Whatever height the nozzle is at when the probe triggers, I take the negative of that as the probe Z offset.

If homing Z with the probe, only when there's a well-tuned Z probe offset can the probe be relied upon to give a meaningful result in G28. So when homing with a probe, one first homes with G28, then moves Z down till the nozzle grabs a piece of paper. If Z isn't zero, adjust the probe offset by the difference from zero.

[mperdue]

@thinkyhead

Did you store a different steps-per-mm value in EEPROM versus the default?

The extruder steps per unit is set with M92 in the startup script. I'll insure that the firmware setting match it to see if that makes a difference.

So when homing with a probe, one first homes with G28, then moves Z down till the nozzle grabs a piece of paper. If Z isn't zero, adjust the probe offset by the difference from zero.

This is basically what I am doing. I start with the offset that is set by the physical design of the BLTouch just to give a starting point. When I am done I have Z zero at the surface of the bed at the home point. And the abs(Z) offset value is at the point where the BLTouch triggers. The value is different with the new firmware but I suppose it could be my process. I'll try a few different ways of verifying it to see if it's just OE. If no one else is having this issue it's probably just something I'm doing.

Time to dust of my calipers and feeler gauges... :-)

[thinkyhead]

Time to dust of my calipers and feeler gauges

If only we could just measure the physical probe, but they all trigger in different ways. And sometimes just based on their mood. Meanwhile, the repeatability of the BLTouch isn't even remotely close to what ANTCLABS claims.

[mperdue]

the repeatability of the BLTouch isn't even remotely close to what ANTCLABS claims.

Yeah, there is that...

[mperdue]

@thinkyhead I've decided I don't care about the offset and extrusion changes I've experienced. The bilinear mesh leveling is so awesome that I'll live with the tweaks required to use it. Looking forward to a version that saves the results so I don't have to run full leveling for each print.

[thinkyhead]

@joris57 I'll bet the 3-point leveling is working properly now. We fixed a bug where the position was being set wrong from the stepper positions, and I'm guessing that was also connected to the 3-point leveling issue.

[joris57]

@thinkyhead I actually was not intending to use 3-point leveling, but I just 'downgraded' from bilineair to 3-point in the hope that the bug would be easier to test (less trashing around of the probe) and/or describe for a simpler case.

In the meantime, I'm happily using bilineair leveling on a rather uneven 300mm x 300mm aluminium bed with an inductive probe on a corexy. :-)

Thanks for solving this for us. Issue can be closed as far a I'm concerned.

And, yes, 3-point works too (but is not good enough for my bed).

[thinkyhead]

@joris57 Good to hear 3-point works too. Another issue claims it's not working, and I have no easy way to confirm or refute. I tend to think it's down to too few points to be reliable.