Manual Probe Deploy hangs on Deploy Probe Screen Message with UBL G29 P1

[SidSkiba]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

I have a manual deployed Z probe for bed levelling. Basically a photo interrupter and a pin with a flag to probe the bed. The photo interrupter is open collector and the output is High when deployed and Low when triggered. The probe works as expected when not using #define PAUSE_BEFORE_DEPLOY_STOW, It works in that the probing all works fine with G29 commands but I cannot get the process to pause to install the probe. If I enable as follows:

// Before deploy/stow pause for user confirmation
#define PAUSE_BEFORE_DEPLOY_STOW
#if ENABLED(PAUSE_BEFORE_DEPLOY_STOW)
  //#define PAUSE_PROBE_DEPLOY_WHEN_TRIGGERED // For Manual Deploy Allenkey Probe
#endif

I do get a Deploy Probe message on the LCD and the machine pauses. However once I install the probe and click a button (5 button Zonestar LCD screen) i hear an extremely short beep and the printer seems to lock up. I cannot get past the Deploy Probe message and the printer no longer replies to any host GCode commands. I must cycle power on printer to regain control.

I tried with PAUSE_PROBE_DEPLOY_WHEN_TRIGGERED enabled and disabled and the result was the same.

This appears to occur whether I use G29 P1 or I use Build Mesh from LCD. Same result in both cases.

Bug Timeline

First time I ever used the probe was with 2.0.9.3 bugfix release. Could not get it to work.

Expected behavior

I was expecting that once I install probe that I could hit a button on LCD and the build mesh operation would continue.

Actual behavior

The printer appear to lock up. The LCD become unresponsive and the USB host (pronterface) can send but gets no response from printer.

Steps to Reproduce

Issue G28, Issue G29 P1. LCD will display Deploy Probe. Install probe and hit button. Extremely short beep and Printer freezes. Go to UBL Tools in LCD, Select build Mesh, Select PLA, Bed heats and E0 heats. One heated LCD displays Deploy Probe. Install probe and hit button. Extremely short beep and Printer freezes.

Version of Marlin Firmware

2.0.9.3 Bugfix

Printer model

Self Built

Electronics

Zonestar ZRIB V5.3 (Ramps Mega 2560), Zonestar LCD, TMC2209 Drivers in Smart Mode, Dual optical Z endstops, DIY photo interrupter Bed Level Probe (HIGH Deploy, LOW Trigger),

Add-ons

None

Bed Leveling

UBL Bilinear mesh

Your Slicer

Cura

Host Software

Pronterface

Additional information & file uploads

Marlin.zip

[SidSkiba]

I have done a bunch more debugging and am trying to follow the code. I enabled bed levelling debug and when I do a G29 P1 with #define PAUSE_BEFORE_DEPLOY_STOW I get the following before it seems to lock up:

SENDING:G29 P1
Default storage slot 0 selected.
Mesh invalidated. Probing mesh.
  current_position= X106.00 Y110.00 Z8.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(5.00)
>>> do_blocking_move_to  X106.00 Y110.00 Z8.00
>  X106.00 Y110.00 Z8.00
<<< do_blocking_move_to  X106.00 Y110.00 Z8.00
Deploy Z-Probe
echo:busy: paused for user
>>> do_blocking_move_to  X106.00 Y110.00 Z8.00
>  X106.00 Y110.00 Z8.00
<<< do_blocking_move_to  X106.00 Y110.00 Z8.00
Probing mesh point 1/100.
Mesh only partially populated.

When I disable the PAUSE_BEFORE_DEPLOY_STOW and issue a G29 P1 I get the following:

>>> G29 p1
SENDING:G29 P1
Default storage slot 0 selected.
Mesh invalidated. Probing mesh.
  current_position= X106.00 Y110.00 Z8.00 : Probe::set_deployed
deploy: 1
Probe::do_z_raise(5.00)
>>> do_blocking_move_to  X106.00 Y110.00 Z8.00
>  X106.00 Y110.00 Z8.00
<<< do_blocking_move_to  X106.00 Y110.00 Z8.00
>>> do_blocking_move_to  X106.00 Y110.00 Z8.00
>  X106.00 Y110.00 Z8.00
<<< do_blocking_move_to  X106.00 Y110.00 Z8.00
Probing mesh point 1/100.
>>> Probe::probe_at_point  X106.00 Y110.00 Z8.00
...(146.33, 122.11, raise, 0, probe_relative)
  current_position= X106.00 Y110.00 Z8.00 :
>>> do_blocking_move_to  X106.00 Y110.00 Z8.00
>  X106.03 Y113.81 Z8.00
<<< do_blocking_move_to  X106.03 Y113.81 Z8.00
  current_position= X106.03 Y113.81 Z8.00 : Probe::set_deployed
deploy: 1
>>> Probe::run_z_probe  X106.03 Y113.81 Z8.00
>>> Probe::probe_down_to_z  X106.03 Y113.81 Z8.00
>>> do_blocking_move_to  X106.03 Y113.81 Z8.00
>  X106.03 Y113.81 Z-2.00
<<< do_blocking_move_to  X106.03 Y113.81 Z-2.00
  current_position= X106.03 Y113.81 Z3.69 : sync_plan_position
<<< Probe::probe_down_to_z  X106.03 Y113.81 Z3.69
<<< Probe::run_z_probe  X106.03 Y113.81 Z3.69
>>> do_blocking_move_to  X106.03 Y113.81 Z3.69
>  X106.03 Y113.81 Z8.69
<<< do_blocking_move_to  X106.03 Y113.81 Z8.69
<<< Probe::probe_at_point  X106.03 Y113.81 Z8.69
Probing mesh point 2/100.

The probing continues on and finishes fine.

Maybe this will help to determine what is happening in the code. I have tried following the code but so far do not know where this is stopping in the code.

[SidSkiba]

I can trace what is happening until I get to this point in ubl_G29.cpp:

mesh_index_pair best;

    TERN_(EXTENSIBLE_UI, ExtUI::onMeshUpdate(best.pos, ExtUI::G29_START));
    do {
      if (do_ubl_mesh_map) display_map(param.T_map_type);

      const uint8_t point_num = (GRID_MAX_POINTS - count) + 1;
      SERIAL_ECHOLNPGM("Probing mesh point ", point_num, "/", GRID_MAX_POINTS, ".");
      TERN_(HAS_STATUS_MESSAGE, ui.status_printf(0, F(S_FMT " %i/%i"), GET_TEXT(MSG_PROBING_POINT), point_num, int(GRID_MAX_POINTS)));

      #if HAS_LCD_MENU
        if (ui.button_pressed()) {
          ui.quick_feedback(false); // Preserve button state for click-and-hold
          SERIAL_ECHOLNPGM("\nMesh only partially populated.\n");
          ui.wait_for_release();
          ui.quick_feedback();
          ui.release();
          probe.stow(); // Release UI before stow to allow for PAUSE_BEFORE_DEPLOY_STOW
          return restore_ubl_active_state_and_leave();
        }
      #endif

It seems like pressing the button to get past the Deploy Probe in probe.cpp:

FORCE_INLINE void probe_specific_action(const bool deploy) {
  #if ENABLED(PAUSE_BEFORE_DEPLOY_STOW)
    do {
      #if ENABLED(PAUSE_PROBE_DEPLOY_WHEN_TRIGGERED)
        if (deploy != PROBE_TRIGGERED()) break;
      #endif

      BUZZ(100, 659);
      BUZZ(100, 698);

      FSTR_P const ds_str = deploy ? GET_TEXT_F(MSG_MANUAL_DEPLOY) : GET_TEXT_F(MSG_MANUAL_STOW);
      ui.return_to_status();       // To display the new status message
      ui.set_status(ds_str, 99);
      SERIAL_ECHOLNF(ds_str);

      TERN_(HOST_PROMPT_SUPPORT, hostui.prompt_do(PROMPT_USER_CONTINUE, F("Stow Probe"), FPSTR(CONTINUE_STR)));
      TERN_(EXTENSIBLE_UI, ExtUI::onUserConfirmRequired(F("Stow Probe")));
      TERN_(DWIN_CREALITY_LCD_ENHANCED, DWIN_Popup_Confirm(ICON_BLTouch, F("Stow Probe"), FPSTR(CONTINUE_STR)));
      TERN_(HAS_RESUME_CONTINUE, wait_for_user_response());
      ui.reset_status();

    } while (ENABLED(PAUSE_PROBE_DEPLOY_WHEN_TRIGGERED));

  #endif // PAUSE_BEFORE_DEPLOY_STOW

that perhaps the button is still pressed when it gets to the ubl_G29.cpp spot where it takes that button press to mean interrupt the probing or something.

I can duplicate the extremely short beep (like a chirp) when running G29 P1 and I disable PAUSE_BEFORE_DEPLOY_STOW. If I run G29 P1 then hold the button on keypad it chirps, stops, and seems to hang. The feedback seems similar:

SENDING:G29 P1
Mesh invalidated. Probing mesh.
Probing mesh point 1/100.
Probing mesh point 2/100.
Probing mesh point 3/100.
Probing mesh point 4/100.
Probing mesh point 5/100.
Mesh only partially populated.

In that it ends with Mesh only partially populated.

The USB host can no longer communicate and the LCD keypad seems unresponsive.

Maybe someone who understands how this code is to work can point me.

Thx

[SidSkiba]

I can confirm the code is getting hung up in marlinui.cpp at the following:

      void MarlinUI::wait_for_release() {
        while (button_pressed()) safe_delay(50);
        safe_delay(50);
      }

It just sits in this while forever. No buttons are pressed but it does not seem to know that.

I had added some code to output to host while in the while loop. It never exits the loop.

Thx

[thinkyhead]

What the heck is a BOARD_ZRIB_V6? That's not something we have in Marlin yet.

[SidSkiba]

Is just a ramps Mega 2560 board knockoff Zonestar Board.

https://m.gearbest.com/printer-parts/pp_009911153463.html

I am just using a board file I found on Zonestar GitHub as it supports ZRIB_V53 which is what I am using. Very similar to ZRIB_V52. I can send those files if you like. I also have 2 custom thermistor files I again got from Zonestar GitHub.

Sent from my iPhone

On Jan 17, 2022, at 3:49 AM, Scott Lahteine @.***> wrote:

 What the heck is a BOARD_ZRIB_V6? That's not something we have in Marlin yet.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[SidSkiba]

Here are the newest original files for the ZRIB V6 and the Thermistor Files from a P802QR2 hotend and bed Original Zonestar Files.zip

Note that they appear to have updated the pins file since I had downloaded it. So mine is based on a slightly older version.

[SidSkiba]

Here are the modded files I am using with my setup. Mods primarily for TMC2209 UART on X, Y, Z1, and Z2 and to add the beeper pin to the LCD Modded Files.zip

These are based on a slightly older version of pins_ZRIB_V6.h

[SidSkiba]

If you need me to try something or test something just let me know. Happy to do so.

[SidSkiba]

I did a bit more testing. I tried M48 with latest bugfix and the Deploy and Stow work perfectly in that case. I can continue by hitting the center button on the keypad no issues. I located an older version of Marlin 2.0.7.2 is what it shows in version.h. Unfortunately the behavior was the same. With G29 P1 it locks up if I hit the center button. In both the latest bugfix and in 2.0.7.2 using M108 to continue after deploy probe message works fine. The M48 behavior is same in latest bugfix as well as 2.0.7.2......it works as expected with a deploy message, followed by a key press, does the M48, pauses with Stow message, displays the Std Dev after pressing center button.

[SidSkiba]

I also just tested Linear, Bilinear, and 3 Point ABL (in latest BugFix) and all work perfectly with PAUSE_BEFORE_DEPLOY_STOW. Seems this only happens with UBL.

[SidSkiba]

So I attempted some changes that seem to work. If I make the following changes to the code (between the //Added start and //Added end comments in each file):

marlinui.cpp

    #if EITHER(AUTO_BED_LEVELING_UBL, G26_MESH_VALIDATION)

      bool MarlinUI::external_control; // = false

      void MarlinUI::wait_for_release() {
        while (button_pressed()) {
          //Added start
          #if HAS_LCD_MENU          
          update(); 
          #endif
          //Added end
          safe_delay(50);
        }
        safe_delay(50);
      }

    #endif

probe.cpp

  #if ENABLED(PAUSE_BEFORE_DEPLOY_STOW)
    do {
      #if ENABLED(PAUSE_PROBE_DEPLOY_WHEN_TRIGGERED)
        if (deploy != PROBE_TRIGGERED()) break;
      #endif

      BUZZ(100, 659);
      BUZZ(100, 698);

      FSTR_P const ds_str = deploy ? GET_TEXT_F(MSG_MANUAL_DEPLOY) : GET_TEXT_F(MSG_MANUAL_STOW);
      ui.return_to_status();       // To display the new status message
      ui.set_status(ds_str, 99);
      SERIAL_ECHOLNF(ds_str);

      TERN_(HOST_PROMPT_SUPPORT, hostui.prompt_do(PROMPT_USER_CONTINUE, F("Stow Probe"), FPSTR(CONTINUE_STR)));
      TERN_(EXTENSIBLE_UI, ExtUI::onUserConfirmRequired(F("Stow Probe")));
      TERN_(DWIN_CREALITY_LCD_ENHANCED, DWIN_Popup_Confirm(ICON_BLTouch, F("Stow Probe"), FPSTR(CONTINUE_STR)));
      TERN_(HAS_RESUME_CONTINUE, wait_for_user_response());
      // Added Start
      #if BOTH(HAS_LCD_MENU, AUTO_BED_LEVELING_UBL)
        ui.wait_for_release();
      #endif
      // Added End
      ui.reset_status();
    } while (ENABLED(PAUSE_PROBE_DEPLOY_WHEN_TRIGGERED));
 #endif // PAUSE_BEFORE_DEPLOY_STOW

It seems to work correctly with UBL. Both Deploy and Stow work as expected.

Unfortunately I am NOT a programmer. So I have no idea if the above changes are logical or somehow otherwise risking some other issues overall.

Hopefully who knows what they are doing can suggest a better approach.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[thinkyhead]

Interesting. The safe_delay function should end up calling back to marlinui.update() already. Your addition of ui.wait_for_release makes sense, and I would go one further and add a check for button release at the end of wait_for_user_response to prevent an accidental button-press on the next prompt.

[github-actions[bot]]

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.