Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SidSkiba opened this issue Jan 12, 2022 · 14 comments
Closed

Comments

@SidSkiba
Copy link
Contributor

SidSkiba commented Jan 12, 2022

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
Copy link
Contributor Author

SidSkiba commented Jan 15, 2022

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
Copy link
Contributor Author

SidSkiba commented Jan 15, 2022

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
Copy link
Contributor Author

SidSkiba commented Jan 16, 2022

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
Copy link
Member

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

@SidSkiba
Copy link
Contributor Author

SidSkiba commented Jan 17, 2022 via email

@SidSkiba
Copy link
Contributor Author

SidSkiba commented Jan 17, 2022

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
Copy link
Contributor Author

SidSkiba commented Jan 17, 2022

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
Copy link
Contributor Author

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

@SidSkiba
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

SidSkiba commented Jan 19, 2022

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
Copy link

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
Copy link
Member

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
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Jun 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants