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

[Bug] ExtUI blocking call breaks M502 / ABL #17429

Closed
minosg opened this issue Apr 6, 2020 · 2 comments
Closed

[Bug] ExtUI blocking call breaks M502 / ABL #17429

minosg opened this issue Apr 6, 2020 · 2 comments

Comments

@minosg
Copy link

minosg commented Apr 6, 2020

Bug Description

Code snippets which are intended to be updating the user interface are blocking, affecting the flow of commands which should not rely on a display.

In my case I have been trying to compile marlin 2.0.4.4, or 2.0.5.2 from tags and eventually bugfix-2.0.x. The machine is an old printer with an BTT SKR mini e3 1.2 and to using MalyanLCD. It is set to use a genuine BLTOUCH 3.1 as a probe, but not for homing.

I noticed that with everything working properly, using AUTO_BED_LEVELING_LINEAR, AUTO_BED_LEVELING_3POINT and MESH_BED_LEVELING.

Then when attempting to activate AUTO_BED_LEVELING_BILINEAR, and AUTO_BED_LEVELING_UBL the machine would freeze when I was trying to issue an M502 to clear the previous settings, or perform the leveling routine.

Looking at the code I noticed the following snippet

#if ENABLED(EXTENSIBLE_UI)
  ExtUI::onMeshUpdate(meshCount, z_values[meshCount.x][meshCount.y]);
#endif

With EXTENSIBLE_UI being evaluated as

// Extensible UI serial touch screens. (See src/lcd/extensible_ui)
#if ANY(HAS_DGUS_LCD, MALYAN_LCD, TOUCH_UI_FTDI_EVE)
  #define IS_EXTUI
  #define EXTENSIBLE_UI
#endif

This to my understanding is intended to upload the z value on the user interface. But If the screen library has not properly implemented this feature it will block and result in undefined behavior, which users may attribute to incorrect configuration of their probe or platform.

My Configurations

configs.zip

Steps to Reproduce

  1. Enable BL Touch
  2. Enable MALYAN_LCD
  3. Enable AUTO_BED_LEVELING_UBL or AUTO_BED_LEVELING_BILINEAR
  4. (Optional) Enable DEBUG_LEVELING_FEATURE
  5. Compile build & upload

In order to trigger the crash:

  • Connect to using pronterface and enable debug M111 S247
  • Issue m502
  • All further communication with the printer will be halted until power cycle

Alternative method:

  1. Set z-offset if not already done. M851 Z-1.0 (replace with your value)
  2. Home all axis G28
  3. Start auto-level using G29

Expected behavior:

The Gcode commands which trigger a settings.reset() to complete

Actual behavior:

The printer freezes, and eventually time's out of the UART interface, until power cycled. The serial port is no longer properly evaluated, and appears as unrecognized device on a Windows host.

If attempting to do auto-leveling, the machine will home, head to the first point and freeze, when attempting to wipe the grid.

Additional Information

A quick workaround is to adjust the pre-processor logic to not include the logic when MALYAN_LCD is defined, without affecting other displays.

G29.cpp

bedlevel.cpp

#if ENABLED(EXTENSIBLE_UI) && DISABLED(MALYAN_LCD)
  ExtUI::onMeshUpdate(meshCount, z_values[meshCount.x][meshCount.y]);
#endif
@thinkyhead thinkyhead changed the title ExtUI blocking call, can break M502 and AUTO_BED_LEVELING [Bug] ExtUI blocking call breaks M502 / ABL May 1, 2020
@thinkyhead
Copy link
Member

This might be related to a more general issue, which is that contributors to ExtUI (@marciot and others) don't always remember to update the ExtUI examples and other implementations when modifying the ExtUI API, so they fall out of sync. There are no official maintainers for these ExtUI implementations, so it's likely they will continue to get stale.

I could patch the onMeshUpdate methods pretty quickly, but someone with a deeper investment in ExtUI and its offshoots is going to have to take the reins or this kind of thing will just keep occurring.

thinkyhead added a commit that referenced this issue May 1, 2020
@github-actions
Copy link

github-actions bot commented Jul 1, 2020

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 Jul 1, 2020
jmp0x0000 pushed a commit to jmp0x0000/Marlin that referenced this issue Aug 7, 2020
njibhu pushed a commit to njibhu/Marlin that referenced this issue Aug 24, 2020
HairingX pushed a commit to HairingX/Marlin that referenced this issue Jun 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants