Klipper: Periodic refresh to lcd display

[aeropic]

I'm using with success Klipper on my ANET A8. I get some weird display on the LCD. It is known the ANET's display is sensitive to electromagnetic noise either radiated from the motors wires or conducted from the power lines.

Would there be a command to refresh the full screen during print ?
Or would there be an option to include in the code a systematic full refresh of the LCD every minute or so?

Thanks

[KevinOConnor]

The only way to do this right now is to issue a RESTART command.

-Kevin

[aeropic]

Sure, this works... But as the problem occurs while the printer is printing, I'm afraid this will ruin the print 😎

[KevinOConnor]

Understood. Unfortunately, it's not straight forward to refresh these screen as it's relatively easy to put them into "weird" modes (turning on hardware cursors, scrolling the window, selecting different line lengths, etc.). It isn't something I plan to work on, but I'm open to it if someone else wants to do the work.

-Kevin

[aeropic]

@KevinOConnor or @Arksine : I experimented a bit with display.py just adding a gcode to reset the LCD :
def cmd_LCD_RESET(self, params):
self.lcd_chip.init()

This works well but indeed does not solve the ANET's problem. When the LCD is set into weird conditions, sending this command performs a refresh of the screen but the LCD remains in its weird mode...
What is interesting is that even after a firmware reset when the screen displays "normal" information, sending this LCD_RESET several times will systematically bring the LCD into "weird" state.

I suspect a timing problem with those screens, somewhat the same issue which is experimented with MARLIN... Which means the issue is located in the MCU firmware, not in klippy ? Am I right ?

[Arksine]

@aeropic You can adjust the delay between commands in the host (HD44780_DELAY), however 3.7 us should be correct according to the spec.

If by "timing" you mean adding some delays between init commands then yes, you will need to do that on the MCU.

[aeropic]

@Arksine , thank you for your answer. I tried to play with HD44780_DELAY but increasing it does not help to solve the issue ...
I'm afraid i'm stuck... I will try to power the screen from another power supply, the issue might come from electromagnetic noise such as induces spikes on the +5V...

[KevinOConnor]

What is interesting is that even after a firmware reset when the screen displays "normal" information, sending this LCD_RESET several times will systematically bring the LCD into "weird" state.

That's odd. If you make the change below, does this prevent repeated resets from corrupting the screen?

--- a/klippy/extras/display/hd44780.py
+++ b/klippy/extras/display/hd44780.py
@@ -78,7 +78,7 @@ class HD44780:
             old_data[:] = new_data
     def init(self):
         curtime = self.printer.get_reactor().monotonic()
-        print_time = self.mcu.estimated_print_time(curtime)
+        print_time = self.mcu.estimated_print_time(curtime) + .100
         # Program 4bit / 2-line mode and then issue 0x02 "Home" command
         init = [[0x33], [0x33], [0x33, 0x22, 0x28, 0x02]]
         # Reset (set positive direction ; enable display and hide cursor)

-Kevin

[aeropic]

@KevinOConnor , just tested, it has no effect, the LCD_RESET corrupts the screen in one or two tries. It's more or less like if the word "Ready" nominally at the bottom left of the screen after reset was randomly positioned after LCD_RESET... The more you send LCD_RESETs, the more you get some Ready or parts of Ready like "y" only displayed on the screen...

[aeropic]

And even a simple FIRMWARE_RESTART does not properly clear the screen with a 100% efficiency... It may fail 10% of the time with for instance the thermometer (hothead symbol) not displayed properly, replaced sometimes by the feed rate symbol ...

[KevinOConnor]

Not sure why that is, but I do know the init sequence on these chips is a bit goofy. My hd44780 is packed away right now. I didn't see any instability when using FIRMWARE_RESTART back when I initially wrote the code.

-Kevin

[KevinOConnor]

I'm going to close this for now as it doesn't look like any solution was found.

-Kevin

[CraXyOW3]

Leaving this just in case someone else bumps into this.
I have a AC Kossel LP with reprap discount 2004 LCD, BUT using a SKR 1.3
After i installed Klipper, display was garbled!

Found info about it here:
https://3dtoday.ru/questions/s-marlina-na-klipper-nekolko-problem/

/klippy/extras/display/hd44780.py
Changed from HD44780_DELAY = .000037
To HD44780_DELAY = .000300

I have NOT finetuned it or anything, it worked and i am happy, hope someone else might find this useful.

[KevinOConnor]

@CraXyOW3 - can you attach the Klipper log file from a session with the fix?

-Kevin

[CraXyOW3]

@CraXyOW3 - can you attach the Klipper log file from a session with the fix?

-Kevin

Done, :D
klippy.log

[KevinOConnor]

Okay, thanks. What is the smallest value of HD44780_DELAY that works on your display? Does .000040 work? Does .000050?

-Kevin

[CraXyOW3]

Okay, thanks. What is the smallest value of HD44780_DELAY that works on your display? Does .000040 work? Does .000050?

-Kevin

At .000038 it is less garbled.
.000039 seems to work with occasional artifact.
.000040 feels to be stable, been fiddling around the menues with this and have not yet noticed anything negative.

[KevinOConnor]

FYI, as of commit ef4710c6 the main code now uses a 40us HD44780_DELAY setting.

-Kevin