Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Strange MIN_PROBE_EDGE_LEFT/RIGHT behavior. Marlin ignores MIN_PROBE_EDGES. #16338

Closed
alantoy opened this issue Dec 26, 2019 · 14 comments
Closed

Comments

@alantoy
Copy link

alantoy commented Dec 26, 2019

Bug Description

I am doing autohome (M28) and then starting M29 autolevelling and printer starts to measure grid from x position 1, not minimal x position 30, like a have configured via MIN_PROBE_EDGE settings.

My Configurations

actual up-to-date marlin version from BUGFIX 2.0.1 branch.

I have normal Ender cartesian printer and have configured
#define MIN_PROBE_EDGE_LEFT 30
#define MIN_PROBE_EDGE_RIGHT 30
... etc. bounds for bltouch/3dtouch probes.
And BILLINEAR_BED_LEVELING und also offset for my bl-touch
(NOZZLE_TO_PROBE_OFFSET { 29, 0, 0 }. my probe located on right side)

Steps to Reproduce

define MIN_PROBE_EDGE or MIN_PROBE_EDGE_LEFT, RIGHT, etc. separately
activate BILLINEAR_BED_LEVELING and start auto bed leveling.

Expected behavior:
use MIN_PROBE_EDGE_LEFT, MIN_PROBE_EDGE_RIGHT minimal offsets / bound from left and right, instead of ignoring them when positioning...

probe_at_point(30.00, 75.00, raise, 0, probe_relative) -> do_blocking_move_to X1.00 Y75.00 Z4.88
but should
probe_at_point(30.00, 75.00, raise, 0, probe_relative) -> do_blocking_move_to !! X30.00 Y75.00 Z4.88.
It should move to point 30, not to point 1.
so LOGICAL_X_POSITION(x) coord transformation/conversation is missing.

Actual behavior:
marlin ignores safe / predifined margins / bounds and tries to do first/leftmost probe at X position 1, instead of 30, like defined in config.

Additional Information

probe_at_point(30.00, 75.00, raise, 0, probe_relative)
current_position= X1.00 Y10.00 Z4.88 :
do_blocking_move_to X1.00 Y75.00 Z4.88
do_blocking_move_to
current_position= X1.00 Y75.00 Z4.88 : set_probe_deployed`

=================
Full detailed debug info:
see following post.

@alantoy
Copy link
Author

alantoy commented Dec 26, 2019

@dnasir
Copy link

dnasir commented Dec 26, 2019

I can confirm that the latest version of Marlin messed up my BLTouch probing. I ended up manually declaring each edge values to get my Ender 3 to do roughly what it was previously doing.

#if PROBE_SELECTED && !IS_KINEMATIC
  #define MIN_PROBE_EDGE_LEFT 20
  #define MIN_PROBE_EDGE_RIGHT 0
  #define MIN_PROBE_EDGE_FRONT 20
  #define MIN_PROBE_EDGE_BACK 20
#endif

The reason MIN_PROBE_EDGE_RIGHT is set to 0 is so that the BLTouch would probe as far right as possible.

The latest version of Marlin seems to ignore my probe offsets for some reason. I'm not sure what the logic is at the moment, but setting MIN_PROBE_EDGE_LEFT to 20 ensures that the BLTouch probes about 44-45mm from the left edge. FYI, my NOZZLE_TO_PROBE_OFFSET is currently set to { -49, -17, -1.6 }.

@sismo99
Copy link

sismo99 commented Dec 26, 2019

I have te same problem with this version the g29 makes a smaller grid if i reduce the MIN PROBE_EDGE (i use it at 30) amost works but now is messed up
I let mu configuration files

thanks

COnfiguraion Files.zip

@Scope666
Copy link

Scope666 commented Dec 26, 2019

I'm also having this problem. Certain values for MIN_PROBE_EDGE_LEFT will make the left edge of the grid START at the physical center of the bed. Other values seem to work fine.

In my case MIN_PROBE_EDGE_LEFT set to 38 caused the first probe point to be almost in the middle of the bed, setting it to 5 instead worked.

I think the value itself is triggering the bug depending on what the number is.

I'm on the recently released stable 2.0.1

My probe offsets: #define NOZZLE_TO_PROBE_OFFSET { -41, -10, 0 }

@sjasonsmith
Copy link
Contributor

sjasonsmith commented Dec 26, 2019

probe_at_point(30.00, 75.00, raise, 0, probe_relative) -> do_blocking_move_to X1.00 Y75.00 Z4.88
but should
probe_at_point(30.00, 75.00, raise, 0, probe_relative) -> do_blocking_move_to !! X30.00 Y75.00 Z4.88.
It should move to point 30, not to point 1.

This is expected. You have a probe offset of 29, so to probe at X=30 it has to move the nozzle to X=1.

@sjasonsmith
Copy link
Contributor

The nozzle to probe offset is stored in the EEPROM. Please either re-initialize your EEPROM (using LCD or M502 / M500, or verify the correct values are stored using the M851 command.

@dnasir, the right probing edge is calculated from X_MAX_POS and your probe offset. X_MAX_POS defaults to the right edge of your bed. If your nozzle can travel beyond the edge of your bed, you should update X_MAX_POS accordingly in Configuration.h.

@alantoy
Copy link
Author

alantoy commented Dec 27, 2019

Thanks. It works now. I think I can close an issue.

@alantoy alantoy closed this as completed Dec 27, 2019
@dnasir
Copy link

dnasir commented Dec 27, 2019

@alantoy How did you resolve the issue?

@drphil3d
Copy link

same issue

@sjasonsmith
Copy link
Contributor

@dnaisr and @drphil3d, if you are using AUTO_BED_LEVELING_BILINEAR there is another issue open for which I'm testing a fix right now. You can follow that issue for updates.
#16348

If you are using UBL or any other form of leveling, my fix won't help.

@Scope666
Copy link

Ah, so I wasn't crazy when I posted this above. :)

@sjasonsmith
Copy link
Contributor

Ah, so I wasn't crazy when I posted this above. :)

It has been doing this for a while, but with a small MIN_PROBE_EDGE (default of 10mm) it isn't very noticeable. It took some people setting crazy large probe edges for the problem to become obvious 😄

@Scope666
Copy link

One of the times it did it to me, I looked down at the printer and X was at 117 for the left-most probe point. This was with MIN_PROBE_EDGE_LEFT set to 38. (235 width, Ender 3)

I flashed multiple times and sometimes it did it, sometimes not, it all depended on the value I had at the time.

@github-actions
Copy link

github-actions bot commented Jul 3, 2020

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.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants