[BUG] Z-Offset LCD screen numerals corrupt during adjustment

[bill-orange]

Bug Description: Numerals in LCD adjustment screen corrupt as encoder wheel is turned.

My Configurations: SKR1.3 board with RepWrap discount display (default), Configuration files are included below.

Steps to Reproduce:

1. Use a SKR1.3 with a discount (non graphical) RepWrap display.

2. Enter the Z-Offset adjustment Menu

3. Observe the numerals scramble ( i.e. extra lines, the top bar of a 5 appearing in a six)

**Expected behavior: normal display of numerals

Actual behavior: scrambled numerals with functionality unaffected.

Additional Information: This may happen in other screens with adjustable numerals. I have not tested other screens.

Marlin.zip

[oliver-eifler]

thats a timing problem (mostley with 32Bit boards) and some display controllers
// Alter timing for graphical display
#if HAS_GRAPHICAL_LCD
#define BOARD_ST7920_DELAY_1 DELAY_NS(96)
#define BOARD_ST7920_DELAY_2 DELAY_NS(48)
#define BOARD_ST7920_DELAY_3 DELAY_NS(600)
#endif
simpley add it at the end of configuration_adv.h

[bill-orange]

@oliver-eifler I had high hopes for that fix but it actually, in my installation, makes it worse. With a ferrite bead the problem goes away. With the noted delays the ferrite bead will no longer fix it.

Since the behavior was changed, you are on the right track. Perhaps the delays just need to be nudged a bit.

[ruggb]

I had that issue 6 months ago and used this after my display selection. Been working ever since. Got it from a post on the Reprap forum.
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER //**
#define ST7920_DELAY_1 DELAY_NS(0) //** scrambled screen without these
#define ST7920_DELAY_2 DELAY_NS(250) //** may have something to do with
#define ST7920_DELAY_3 DELAY_NS(250) //** newer versions of the IDE or U8GLIB

[bill-orange]

@ruggb were the delays put in configuration.h around line 1925 or elsewhwere? configuration_adv.h perhaps?

[ruggb]

just like it shows, right after the display define in config....h. I don't know that it matters exactly where it is I just put it there so I remember why I did it. The //** are just so I can find my changes easily

[ellensp]

you have REPRAP_DISCOUNT_SMART_CONTROLLER and REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER enabled.
This is going to cause you all sort of issues.
Also means we can't tell if you actually have a 20x4 char display of a graphics display attached.
You need to disable one.

[ruggb]

@ellensp

you have REPRAP_DISCOUNT_SMART_CONTROLLER and REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER enabled.
This is going to cause you all sort of issues.
Also means we can't tell if you actually have a 20x4 char display of a graphics display attached.
You need to disable one.

Are you talking to me? If so how do you figure that?

[ellensp]

@RUGGD no, I'm talking to the author about the authors provided configuration.h

[ruggb]

I didn't look at it, but his issue is slightly different than mine. Mine was garbage all the time, not just when turning the knob == I think only the full graphic has a knob.

[ellensp]

mate stop talking, its nothing to do with you or your comments.

[ruggb]

That comment was for the OPs benefit.
BTW, I wasn't talking, just wearing my fingers to the bone.
But, for some reason the CONTRIBUTORS attitude on this venue has taken a large turn for the worse.
Must be everyone is sick.

[bill-orange]

@ellensp You are correct about have both controller type defined. I neglected to comment out REPRAP_DISCOUNT_SMART_CONTROLLER. I added the delay statements noted by @ruggb and I will test it tomorrow. However I suspect that whatever delays are used for my REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER are defined elsewhere.

[bill-orange]

Edit. Sadly neither commenting out REPRAP_DISCOUNT_SMART_CONTROLLER and using the delays 0,250,250 or 96,48,600 helped. The latter may make it worse. The greatest improvement remains the ferrite bead.

[boelle]

@bill-orange still an issue?

[bill-orange]

This was solved by adding ferrite to one cable, not an ideal solution. Since no one has a better idea, I think we can close it

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