Fix delta moves in UBL mesh edit screen

[sjasonsmith]

Description

The UBL mesh edit screen had two distinct problems when used on a delta printer:

1. It tried to move to the 0,0 mesh point, which is not reachable on delta.
2. It used ManualMove to move between points, which resulted in non-segmented moves between points. This cause the nozzle to crash into the bed.

I fixed this with the following changes:

1. Do not move to the first mesh point before loading the screen. This isn't really noticeable to a user, but allows unreachable points to be skipped for kinematic printers.
2. Change UBL mechanism to not set current_position prior to the move, since this breaks the segmented kinematic move.
3. For kinematic machines, store a separate destination in ManualMove, to prevent the encoder from interfering with the destination currently being segmented.

Benefits

Allows UBL mesh editing screen to work on delta.

Configurations

Related Issues

I believe this will fix #20260

Related PR: #18373

[sjasonsmith]

I just realized I probably broke stuff for Cartesian printers. I had run checks locally and no builds failed, but that surprises me now that I look at the changes.

[sjasonsmith]

I have tested both manual moves and mesh editing on Delta and Cartesian printers now.

@Foxies-CSTL, could you test and report back whether this resolves your mesh editing issue also?

[Foxies-CSTL]

Hi, Best wishes for success and recognition !!

I have tested both manual moves and mesh editing on Delta and Cartesian printers now.

@Foxies-CSTL, could you test and report back whether this resolves your mesh editing issue also?

Infos:
Printer QQS (board hispeed) with 4xTMC2209Uart single wire, probe microswitch under the head (13.5mm).
Soft: UBL active after G28, , Delta segment 100/s, microstep 32, UBL Grid 8x8 with 32 insert.

Ok, I tested it this morning (with a clear mind ;-)) after a double EEPROM reset, a double default loading/memorizing of the parameters, a G33 v3 (sdt dev< 0.8), an adjustment of the ZoffSet ( -13.8). I started a cold mesh build from the menu (UBL tools) and later with a bed temperature of 60 ° C. I saved the mesh in 0.
When editing the mesh:

1. The kinematics of positioning is good (a homming then a position towards the first point of the mesh). I started again later and the same observation but with a positioning at the last measurement.
2. For the measurement: the head gets close to the point chosen on the mesh map (info: TFT UI COLOR) but remains at a distance far enough from the displayed value: point 1 displayed Z = -0.075 physical value between nozzle and bed 5.5mm.
3. Acknowledging the point starts another positioning on an adjacent point. Up to 8 points in a row after receipt of the presented value. At the last acknowledgment, the head is positioned above another point of the mesh (but not in the high position as at the beginning) and we have, again, the screen the representation of the mesh.
4. Another observation is the exit from edit mode by the menu or the time of no action on the screen: the head remains in its last position. Perhaps a homming should be inserted at the end of this exercise.
5. Concerning the adjustment of the point measurements: I manage to correct the bias of 5.5mm but the incrementation of very slow (step of 0.005).
6. I went a little further in the tests but I had a crash of the head on the bed during a mesh edit. I am not sure that the taking into account of the corrections is effective for all points.
   The launch of a print after correction was not attempted ;-).

This is my test feedback on this PR #20620
I hope this will help you.

Start of sequence.

Acknowledgment of the first point.

End of the correction of the first point and positioning of the head towards the next point!?!

[sjasonsmith]

My goal in this PR is not to improve the usability of the edit screen. I don’t normally use UBL myself so I assume there are parameters to modify the starting height, etc.

The goal of this PR is to prevent this menu from trying to destroy your printer by crashing into towers and the bed!

With that goal in mind, it sounds like your test was successful!

[sjasonsmith]

I renamed the PR to better reflect the scope of my changes.

[sjasonsmith]

@thinkyhead when you look at this please let me know if you have major concerns about the approach. I would like the chance to rework (and re-test) it myself if needed.

I had implemented a more unified ManualMove class to remove the big Cartesian/Kinematic differences, but decided to put up a smaller and lower-risk change as an initial bug fix.

[Foxies-CSTL]

My goal in this PR is not to improve the usability of the edit screen. I don’t normally use UBL myself so I assume there are parameters to modify the starting height, etc.

With that goal in mind, it sounds like your test was successful!

I agree the beginning of the problem has been solved: the initialization of the sequence of the edition of a mesh works.

All the rest of the editing of the mesh must be the subject of a new PR because the correction/adjustment of the points of the mesh is not optimum. Some point corrections crash the head on the bed so for me, editing the mesh isn't good.

[thinkyhead]

It's not entirely clear, but it looks like ubl_map_move_to_xy is moving between points without raising the print head in-between. If this routine needs extra attention to get the movement logic right in that sense, then we should attack that in a separate PR.

[sjasonsmith]

I can probably look into that tomorrow. I didn’t spend time actually adjusting the points, so my moves were well above the bed.

I had assumed issues on this screen were delta-specific. I thought it would be widely used on Cartesian, so I’m surprised it would be fundamentally broken like that. Perhaps UBL just probes so many points that whatever minor scraping might occur has been acceptable to people...