[BUG] Unpragmatic changes to Nozzle and Probe during G28, G29, G34

[Aurawin]

Issues: #16397, #16397, #16397, #16371, #16348, et. all.

The attached illustrations are a demonstration of what happens when you probe using the nozzle's position rather than the probe's position.

Presently logic in Marlin changed from making the nozzle's position X,Y to the position of the probe's X,Y.

This change is not welcome and is causing problems with the Marlin not probing where we all expect it to probe.

The basic gist is describing how things were and how positioning needs to be to make use of our probes and the size of our beds (at least on a core XY).

[Aurawin]

Having given this thought, the Z values Probe.X and Probe.Y positions can pragmatically be used if probing is allowed within the constraints of the bed during sanity checks and kinematics.

So this issue's solution may be easier to solve than anticipated. Just make sure the nozzle's position is within the extents (absolute X,Y) of the bed while still using the probe's relative location to probe Z.

[InsanityAutomation]

Following consistency with defined standards as well as other firmwares, when you say to probe x 50 y 50 that is exactly where the probe itself should go. Behavior is getting more and more consistent. obviously a complete review pass will be necessary at some point to make sure nothing has been missed. What you are describing is proper use of Min Probe Edge, which many seem to be abusing instead of properly setting their probe offsets and causing a lot of the issues.

[Aurawin]

Following consistency with defined standards as well as other firmwares, when you say to probe x 50 y 50 that is exactly where the probe itself should go. Behavior is getting more and more consistent. obviously a complete review pass will be necessary at some point to make sure nothing has been missed. What you are describing is proper use of Min Probe Edge, which many seem to be abusing instead of properly setting their probe offsets and causing a lot of the issues.

Can you please elaborate what you believe the widespread abuse is?

[Aurawin]

A pragmatic approach to sanity on Left probes would be to use Xmin, EdgeOffset.X, and Probe_offset.X where probe is to the LEFT not right of nozzle.

If the probe is to the right of the nozzle than the sanity check should not include Probe's offset from the nozzle because the nozzle (AND PROBE) are already on the bed.

[InsanityAutomation]

When I see configurations with values of 30 or 40 mm, they were obviously probing off the bed and set it very high to get it to come in. If the end stop and bed positions were correct and probe offset were correct that should never be above 10.

[Aurawin]

When I see configurations with values of 30 or 40 mm, they were obviously probing off the bed and set it very high to get it to come in. If the end stop and bed positions were correct and probe offset were correct that should never be above 10.

This assertion is paramountly wrong. It is entirely feasible for people to use GARGANTUAN (30mm) clips that with a safety factor of like you say 10mm, would imply a 40mm edge offset.

[InsanityAutomation]

Possibly on 2 axis, and intentionally so they know why it's inset so much. Then they are not complaining that it's not probing the entire bed because they did it intentionally.

[Aurawin]

Following consistency with defined standards as well as other firmwares, when you say to probe x 50 y 50 that is exactly where the probe itself should go. Behavior is getting more and more consistent. obviously a complete review pass will be necessary at some point to make sure nothing has been missed. What you are describing is proper use of Min Probe Edge, which many seem to be abusing instead of properly setting their probe offsets and causing a lot of the issues.

Agreed. I no longer want to probe Z at nozzle's position. That was red herring so to speak. The issue is calculating safe extents during all these probe routines.

Currently:
G34's min calc is incorrect while max extent is spot on.
G28 safe probing is expected to use all mentioned values to locate the probe's location at the actual center of the bed - which it's not.
G29's max calc is incorrect while my check fails here and I can't test further becauese the probe is off my bed.

[Aurawin]

Possibly on 2 axis, and intentionally so they know why it's inset so much. Then they are not complaining that it's not probing the entire bed because they did it intentionally.

Don't spare "we are not a support group" reply. Or a one-line link to the official marlin G34,G28,G29, pages.

[InsanityAutomation]

G34 I planned some work on this weekend regardless, so Ill do a little testing while im at it and see if an issue is there. I havnt looked at the checks there in a long time.

G28 afaik hasnt been touched in a long time either so while the rest of the code has been gone over for consistency, it may be in the things to check in a sweep as mentioned above. G29 has a PR open to fix the issue right now.

[InsanityAutomation]

Keep in mind we changed alot of the underlying stuff when implementing M851XY to allow probe offsets to be modified at runtime and to be floats instead of int's. Since then alot has gone into finding edge cases and inconsistencies. Im not shooting down any actual bugs, but things need to be described well so we can tell the difference between expected behavior and a bug. For example the G29 fix thats in an open PR right now when I first saw the issue, because of bad wording I wrote it off as bad config. Someone else took a closer look when they saw a second similar issue come up and saw an actual bug was there. Hence the fix.

[Aurawin]

G34 I planned some work on this weekend regardless, so Ill do a little testing while im at it and see if an issue is there. I haven't looked at the checks there in a long time.

Please reference my illustrations. I assert that (in the case of a probe to the right) the probe's X offset is not needed in the calculation of the valid MIN extent.

[InsanityAutomation]

I have machines with the home switch at X-45 to park in a purge bucket and off the bed. If that value was not in the min condition I would lose out on a good bit of area it could probe. This is common with IDEX machines.

[Aurawin]

I have machines with the home switch at X-45 to park in a purge bucket and off the bed. If that value was not in the min condition I would lose out on a good bit of area it could probe. This is common with IDEX machines.

I don't think this an ancillary fact. Were just validating where the probe's X at this point

[InsanityAutomation]

In the case of a BCN Sigmax R19, MakerGear M3ID, Formbot Trex2+ or 3, if the probe is 12mm to the right, and the inset is 3mm, you want to apply the value so that the head is at X-9 when probing the edge of the bed. If you did not take the offset into account and went to X3 you are losing a full 12mm of bed area that could be included in the mesh.

[Aurawin]

you are losing a full 12mm of bed area that could be included in the mesh.

What is that number with X_MIN_POS factored in?

[InsanityAutomation]

Lets assume X_MIN_POS is -42 on one of those machines, its outside the calculation and its using the edge of the bed.

#define LTEST(N) (test_z_stepper_align_xy[N].x >= _MAX(X_MIN_BED + MIN_PROBE_EDGE_LEFT, X_MIN_POS + dpo.x) - 0.00001f)

So,
_MAX(0 + 3, -42 + 12) so the number in question comes out to be -30 but is not used as 3 comes out as the proper value.

[Aurawin]

What side is the probe on?
What is X_MIN_BED? I don't have that in my Configs.
What is dpo.X?

[InsanityAutomation]

X_MIN_BED is the start of the bed and is automatically defined if not set and usually 0. dpo.x is the probe offset extracted from the default array in a way the preprocesor can use. With a positive value of 12, that infers right. Negative value infers left.

constexpr xyz_pos_t dpo = NOZZLE_TO_PROBE_OFFSET;

[Aurawin]

The above illustrates the issue. Even at X_MIN_POS=-4, You can safely probe with MIN_PROBE_EDGE_LEFT=5 at X=5mm. ie. dpo.x checking is only useful for dpo.x<0

With the current logic, G34 only accepts X values larger than 33mm

[Aurawin]

This image shows the problem. My nozzle is at 33mm when it should be much closer to the edge. 5mm would be where I would expect it to be.

[tpruvot]

well, turn off your printer, move the nozzle with hands at the left max... take a picture, then a beer and watch :p

[Aurawin]

the

well, turn off your printer, move the nozzle with hands at the left max... take a picture, then a beer and watch :p

Hmmm.. Max Left? Min is left max is right? Is this a British/Aussie thing where you drive on the wrong side of the road? lol.
I don't have any issues with probing on the right side of my bed @ max.

[InsanityAutomation]

Send the whole configuration file and a photo of where it sits right after it homes so I can see where 0 is. I'll run the same calculation and see where it lands. Is this G29 or G34? If G29, did you include pr #16367 ?

[Aurawin]

K. Config file is posted here

Configuration.zip

Interesting thing. A while ago my probe was at center of my bed ~ 165,165,10 now it's off center and so is the nozzle. I have safe homing enabled

Safe Homing yields a homing of X166 Y133 on display

[Aurawin]

G29 is passing sanity checks but the probe is going off the bed. Probe Point 0 x = 326. Way too far to the right. It seems G29 did not account for my NPO

[tpruvot]

seriously, do some effort.... with your pictures, avoid 45° and 90 camera positions

[Aurawin]

seriously, do some effort.... with your pictures, avoid 45 and 90 camera positions

I did. Ubuntu showed them propper. I would. Only I'm having to be at 2 places at once. On hand on the E-STOP and 1 hand on the phone. Are you kidding me?

At any camera angle that clearly demonstrates MARLIN mashing my hot-end.

[Aurawin]

Regarding G29 first probe point and max X values, if I set to an enourmous MIN_PROBE_EDGE_RIGHT 50 I can get Marlin to execute G29 while keeping it on the bed.

Meaning there are a bunch of people with gargantuan values MIN_PROBE_EDGE_RIGHT. Which is a symptom, not a cure.

I' ma start printing now with my Gorilla sized #define MIN_PROBE_EDGE_RIGHT. I would love to figure this out, but I have a feeling the culprit is lurking here. LOL.

[Aurawin]

After pulling from my upstream, reloading my config on the controller all is working as expected.

[github-actions]

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.