Allow bed tramming with probe to automatically calculate points by pr…

[InsanityAutomation]

This allows bed tramming to automatically calculate points based on the probe offset. I built this in my branch sometime back, and saw a recent request to get this functionality upstream.

Resolves issues when users adjust the probe offsets after compilation where the tramming functions can no longer reach the bed plate and tramming fails.

The initial changes are from 7mo back just cherry picked... So this will absolutely need a testing pass. They worked then doesnt mean something that didnt trigger a merge issue caused a behavior change since.

[sjasonsmith]

It seems like this isn't "allowing" BED_TRAMMING_USE_PROBE to auto-selected points, it is "forcing" BED_TRAMMING_USE_PROBE to use auto-selected points.

If I am configuring tramming for my machine, I both want to use my probe, and I want to configure it to probe directly above my screws. It seems like that will not be possible with this change.

My thoughts:

• A better approach could be to allow BED_TRAMMING_INSET_LFRB to be commented out, indicating that points offsets be automatically selected.

• A second possibility would be to auto-select if the supplied points are unreachable. This could happen if someone changed their probe offset after initially selecting their offsets. I could see two ways to integrate auto point-selection in the the tramming workflow:

• Why does this require a probe? Could the offsets be just as easily auto-selected for non-probe tramming?

[InsanityAutomation]

There is no g-code to interact with this function, only the menu. If there was a gcode trigger, we could modify it with the LRFB arguments similarly to G29 or G34 to allow fixed point as well. I would consider that a second stage improvement for the function to bring it in-line with G34 adding eeprom storage and use fixed points that are recalculated on demand either by error condition or explicit reset. This nets the prerequisite of getting values out of progmem and into runtime though preventing a full on blocking condition.

Without a probe, there is no cause for these to be adjustable and expending the RAM. The entire issue is when shifting the probe with a new XY offset, the compiled positions often become unreachable. Without a probe, the probe min/max functions dont exist and there are no variable to calculate limits off of. When gcode and eeprom storage is done though, with and without probe could then both use the adjustable points if desired though I see little reason to.