[BUG] UBL Fine Tune Screen Not Displayed Correctly

[bill-orange]

Bug Description: The top half of the UBL mesh editor screen is cut off. I am using the RepRap Discount Full Graphics display attached to an SKR1.3. All other Menus/Screens are fine. See photo.

My Configurations: Attached

Steps to Reproduce:

1. Do the P1 and P3 steps.
2. Using the LCD display and encoder, move through the menus until you get to the Mesh Editor Menu.
3. Note the cut off text.

Expected behavior: Fully legible text

Actual behavior: Cut off text. This is cosmetic. Functionality appears fine.

Additional Information: This is the only menu that I have found to have a problem.

Marlin.zip

[qwewer0]

Works for me.

SKR Mini E3 v1.2, Latest Bugfix, 7x7 UBL mesh.

[bill-orange]

@qwewer0 What display board are you using? Remember the problem is the display not functionality. Go to the mesh editor and check your display.

[qwewer0]

@qwewer0 What display board are you using? Remember the problem is the display not functionality. Go to the mesh editor and check your display.

My bad. Ender 3 original 12864 display.
But the "Works for me" was for the display part, as it shows everything without a problem.

[Tannoo]

Nevermind. Still works for me. I missed the link below the pic the first time.

[bill-orange]

I suspect this problem relates to the RepRap Discount Full Graphics Display only. I would try to solve the problem myself but I have no clue about which file contains this particular piece of code.

[Tannoo]

I am not so sure on that. I have that exact display and it's working fine with the Mega2560.

[Tannoo]

Here is my UBL mesh edit screen from bugfix-2.0.x that I downloaded on 5/25/20.

Are you sure you are using the latest?

You also didn't state that you were using UBL either. My bad.

[Tannoo]

Here is the closest I have is the babystepping / Z-offset:

[Tannoo]

There were some timing lines you could add to see if it helps.

And it looks like you have already done this in issue: #17989

[Tannoo]

My suggestion is to download a copy of bugfix-2.0.x at your earliest convenience, unzip, configure, and upload it.

See if that fixes it as I do not have any of the special timings in my config. But, that can just be the controller not being able to handle the normal timings.

[bill-orange]

Yea, testing the bug fix is the next logical thing to try. Thanks for uploading the image. I did not know what the menu was supposed to look like. What is odd, is that only this menu is affected. My info screen looks normal. I don’t see what could be different about the graphics in this menu bs the info screen. Perhaps @thinkyhead could tell us what might be different.

[Tannoo]

I had a similar effect when I was updating from a year ago and after I posted about it on discord, I found the PR's that "fixed" it and another issue, I found that those PR's were applied AFTER I downloaded my copy. I applied those PR's to my copy and it corrected the issues I had.
So... I downloaded the latest (5-25-20) to update to any new features that I might be missing out on that I didn't know if I could live without or not.

So... always try a fresh copy of the bugfix branch as that is where all of the bugs are fixed. lol

[bill-orange]

Sadly, same results with Bugfix. I think the key to this will be to figure out what is different about the offending menu from all the other menus. On my machine the even menu @Tannoo posted with the square in the middle looks fine.

[Tannoo]

Okay. What exact menu option are you selecting?

[Tannoo]

Using the LCD display and encoder, move through the menus until you get to the Mesh Editor Menu.

Menu > Motion > United Bed Leveling > Mesh Edit
That is what got me to the "Radar Map" edit screen.

Actually editing the point is the screen you are on? I have USE_BIG_EDIT_FONT enabled so I can see the numbers. lol
I will turn that off later and take a look.

[bill-orange]

I got to it by:

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

I think this menu is "reused" several places in UBL.

[Tannoo]

Here is my point edit screen with USE_BIG_EDIT_FONT disabled:

I can't get it to mess up either. Did you just "drag and drop" your old configs into the newest bugfix? If so, Can you just modify the configs that come with bugfix. In Windoze, WinMerge makes this process soooo much easier.

[bill-orange]

Did you just "drag and drop" your old configs into the newest bugfix? I confess, I did. I will compare the configs as time permits. Even with good tools it can take a while. I generally use the compare add-on in Notepad++. Its easier on my old eye.

[Tannoo]

10 mins tops unless your old configs are really old.

[Tannoo]

I see that you have MESH_EDIT_GFX_OVERLAY enabled. I am trying that now.

Mine shows all of the text, but the "Nozzle" is missing. It is supposed to "bump" up and down depending on the direction of the encoder.
This is up:

And this is down:

Let me see if I can hunt down the issue. It might be beyond my abilities, though.

[bill-orange]

I did a fresh build on Bugfix and experienced the same problem. Oddly, I am a little more cut-off than you are. If you can hunt down the problem, that would be great. I had a hard time understanding the structure of the menu building code, when I had a look last week.

@thinkyhead you might want to look at this, since we now have confirmation of this minor bug.

[Tannoo]

Well, I have tried and tried.... I am at a loss. I have jacked up my code so much that I likely need to reload the bugfix branch into my printer.

For the time being, disable MESH_EDIT_GFX_OVERLAY so you can see the numbers.

[Tannoo]

BABYSTEP_ZPROBE_GFX_OVERLAY option and the babystepping screen works just fine.
TERN_(BABYSTEP_ZPROBE_GFX_OVERLAY, _lcd_zoffset_overlay_gfx(probe.offset.z));

MESH_EDIT_GFX_OVERLAY option and it's screen doesn't work properly.
TERN_(MESH_EDIT_GFX_OVERLAY, _lcd_zoffset_overlay_gfx(mesh_edit_value));

probe.offset.z vs mesh_edit_value are generated differently.

MESH_EDIT_GFX_OVERLAY is here in menu_ubl.cpp"

static void _lcd_mesh_fine_tune(PGM_P const msg) {
  ui.defer_status_screen();
  if (ubl.encoder_diff) {
    ubl_encoderPosition = (ubl.encoder_diff > 0) ? 1 : -1;
    ubl.encoder_diff = 0;

    mesh_edit_accumulator += float(ubl_encoderPosition) * 0.005f * 0.5f;
    mesh_edit_value = mesh_edit_accumulator;
    ui.encoderPosition = 0;
    ui.refresh(LCDVIEW_CALL_REDRAW_NEXT);

    const int32_t rounded = (int32_t)(mesh_edit_value * 1000);
    mesh_edit_value = float(rounded - (rounded % 5L)) / 1000;
  }

  if (ui.should_draw()) {
    MenuEditItemBase::draw_edit_screen(msg, ftostr43sign(mesh_edit_value));
    TERN_(MESH_EDIT_GFX_OVERLAY, _lcd_zoffset_overlay_gfx(mesh_edit_value));
  }
}

and BABYSTEP_ZPROBE_GFX_OVERLAY is here in menu.cpp:

  void lcd_babystep_zoffset() {
    if (ui.use_click()) return ui.goto_previous_screen_no_defer();
    ui.defer_status_screen();
    const bool do_probe = DISABLED(BABYSTEP_HOTEND_Z_OFFSET) || active_extruder == 0;
    if (ui.encoderPosition) {
      const int16_t babystep_increment = int16_t(ui.encoderPosition) * (BABYSTEP_MULTIPLICATOR_Z);
      ui.encoderPosition = 0;

      const float diff = planner.steps_to_mm[Z_AXIS] * babystep_increment,
                  new_probe_offset = probe.offset.z + diff,
                  new_offs = TERN(BABYSTEP_HOTEND_Z_OFFSET
                    , do_probe ? new_probe_offset : hotend_offset[active_extruder].z - diff
                    , new_probe_offset
                  );
      if (WITHIN(new_offs, Z_PROBE_OFFSET_RANGE_MIN, Z_PROBE_OFFSET_RANGE_MAX)) {

        babystep.add_steps(Z_AXIS, babystep_increment);

        if (do_probe)
          probe.offset.z = new_offs;
        else
          TERN(BABYSTEP_HOTEND_Z_OFFSET, hotend_offset[active_extruder].z = new_offs, NOOP);

        ui.refresh(LCDVIEW_CALL_REDRAW_NEXT);
      }
    }
    if (ui.should_draw()) {
      if (do_probe) {
        MenuEditItemBase::draw_edit_screen(GET_TEXT(MSG_ZPROBE_ZOFFSET), BABYSTEP_TO_STR(probe.offset.z));
        TERN_(BABYSTEP_ZPROBE_GFX_OVERLAY, _lcd_zoffset_overlay_gfx(probe.offset.z));
      }
      else {
        #if ENABLED(BABYSTEP_HOTEND_Z_OFFSET)
          MenuEditItemBase::draw_edit_screen(GET_TEXT(MSG_HOTEND_OFFSET_Z), ftostr54sign(hotend_offset[active_extruder].z));
        #endif
      }
    }
  }

Now, I have reached my brain's mental capacity. I am lost as to what to do about this. My gut says to unify these two, but I am not sure if that can be done because they are two different animals that look the same.

[boelle]

@bill-orange still an issue?

[bill-orange]

Yes, this is still an issue. It appears to be a confirmed bug. I am not working on it because tracking down the error exceeds my skill. I am hoping that someone with greater knowledge of the structure of the LCD components of Marlin will pick this up. Mercifully, the errors in generating the LCD screen do not affect functionality.

[thinkyhead]

For screens that self-manage from within the menu system I've taken care to ensure that when you click a button to go to a new screen that the screen change happens at the right time to ensure at least one complete screen update. This is not a screen that I implemented, and the screen change event seems to be done external to the regular screen update loop. So, I'll need to find a clever way to ensure that screen changes external to the screen update loop also have the correct timing, or at least do an extra update.

[bill-orange]

@thinkyhead Thanks. When you need me to test, I have a Tronxy X3A and an Anet A8 that exhibit the problem with the discount full graphics display and SKR1.3.

[Tannoo]

Just to note, I am using a Mega2560 with RAMPS.

[thinkyhead]

Please give this a try and see if it helps. #18373

[bill-orange]

Sorry, no difference in display behavior.

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.

[bill-orange]

on my system, the latest changes in bugfix have not affected the problem. However, the encoder's behavior is greatly improved. It is interesting that the mesh editor screen is the only one with this problem.

Perhaps @Tannoo should retest also.

[bill-orange]

@thinkyhead I tested the branch Marlin-bf2_simpler_mesh_edit_PR this morning and the EDIT display now functions normally. Thanks. If I turn the encoder wheel quickly, I can still corrupt the digits. To get the digit corruption the encoder wheel needs to be turned faster than a wise person would actually turn it in real use. There is therefore a pretty minor issue.

There was also an innocuous compiler warning, unused variable 'old_pos_index' [-Wunused-variable] .

[boelle]

@bill-orange so as soon @thinkyhead merges #18373 we can swing the axe on this one?

[bill-orange]

I believe so. I briefly tested the un-merged working version and it corrected the display problem on my machine.

[sjasonsmith]

@bill-orange, can you close this once you are able to test the merged change? If we don't hear back in a couple days we will likely presume it is fixed and close it for you.

[bill-orange]

I see no reason not to close it now. If a problem is found later it probably should start as a new issue anyway.

[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.