Simpler mesh edit loop

[thinkyhead]

For UBL mesh editing via G29 P4, instead of using a null screen handler and a tight control loop, use normal screen handling and read the available edit value as it changes.

Intended to address a partial screen update issue by staying within the normal LCD update and control loop so draw flags will have appropriate values during the screen update.

TODO: The screen could be made modeless by moving all the mesh editing state control to the screen handler and should reduce some redundancies.

Closing #18174

[thinkyhead]

Ready to test. 🤞

[bill-orange]

Sorry, no difference in display behavior.

Motion > United Bed Leveling > UBL Tools > Edit Mesh > Fine Tune Closest

All other Menus I have observed are okay.

With //#define MESH_EDIT_GFX_OVERLAY commented in or out the display looks like the picture in my first post on this issue.
Did you do anything that would change the encoder timing? It seems better, no corruption in the numbers and no missed encoder ticks.

[thinkyhead]

This is a general improvement and will definitely help the controller response. I'm surprised to see that the top half of the screen is never being updated during editing. I had thought it was one of those "not updating the screen properly" issues. But now it seems more likely that the nozzle graphic overlay drawing is what's messing up. I'll look closer at that.

[thinkyhead]

Another commit has been added that should help.

The currently-employed method of external control conceals encoder events from the normal MarlinUI loop. As a result the encoder event isn't able to generate a screen update at the right moment. Instead, the screen update only occurs after the screen handler sees the changed value. To remedy this issue, I've added a refresh for captured encoder events.

If it works then this is good enough. In future I will fix up and standardize this stuff.

[bill-orange]

No change in display behavior on my machine. It would be a good idea if others could test on there machine.

[thinkyhead]

No change in display behavior on my machine. It would be a good idea if others could test on [their] machine.

I thought I ran out of spare graphical LCDs, but I just found one. I'll get into some testing forthwith.

[thinkyhead]

I've found some other flaws in the mesh editor that should definitely be fixed before 2.0.6 goes out. I'll aim to get everything working perfectly today.

[thinkyhead]

This is now working reliably. However, it could be improved by adding a small delay between moving the knob and starting a move to the selected point, so that you get fewer double-moves. Or, it could wait for a click before moving to the selected point, and then wait for another click to edit it.

[thinkyhead]

I've modified this to use the existing machinery for manual moves, which seems to work pretty well, and otherwise it tries not to interrupt movement. I did see one glitchy behavior with the mesh point out of range, but I haven't been able to force it to happen by spinning the knob wildly.

I need to compare to the previous behavior, because after I edit a point it continues on to the next mesh point instead of returning to the map view. But that might be intentional when you have an unpopulated mesh….

[bill-orange]

@thinkyhead I suspect the glitchy behavior that I see ( and you saw at least once) is more of a hardware problem than a software problem. Because I am a ham, I have lots of ferrite beads and clamps around. Putting ferrite on one ribbon cable between the display and the control board reduces the glitches.

Since the glitchy behavior is altered by a hardware change, I suspect that the solution and the problem reside there. The addition of pull- up resistors to the LCD display data lines to lower their impedance might fix the problem. One day I will test this theory.

[thinkyhead]

I suspect the glitchy behavior that I see (and you saw at least once) is more of a hardware problem than a software problem

Well, a common source of drawing mistakes is that DOGLCD displays are updated in segments, so the screen handler has to be called up to 4 times per screen display to update its content. Therefore screen handlers under MarlinUI need to take care not to switch to a new screen handler (or to change what they are drawing) in-between screen segments. If the top part of the screen isn't drawn, it can mean that the encoder events aren't generating screen updates (which was indeed one issue), or it can mean that the screen handler got switched at the wrong point in time from another screen handler.

The motion behavior in the mesh editor was itself not ideal, so this PR aims to improve that behavior and produce a more responsive and more controllable user interface.

At least one user has indicated that immediate automatic movement between mesh points, or movement after a pause are both "kind of surprising." So maybe the delay needs to be a little longer than 1/4 second, or it might be better to require a click to do the move, then initiate Z editing once the move is completed, or when there is another click at the same point.

[bill-orange]

Super, I will switch to BugFix. Is there a road map or schedule for ver. 2.0.6? If its coming very soon, I might wait for it.

[thinkyhead]

I'm looking at reports that bed leveling is acting weird. And reports that power-loss recovery isn't working. These are the only two blockers for 2.0.6 right now. So, hopefully it will be out this weekend.