Background: the hd44780.py driver has a hardcoded 40us minimum delay
between commands sent to the display. That’s fine for genuine HD44780
chips (Hitachi datasheet minimum is ~37us), but some cheap “clone”
displays (in my case an ACM2004 4x20 character LCD) need more margin
to display reliably. Previously the only fix was hand-patching the
hardcoded constant in hd44780.py.
The PR adds an optional hd44780_delay config option to the
[display] section, defaulting to the existing 40us so nothing changes
for users who don’t set it. Tested on a live multi-printer setup: two
printers with conforming displays stayed on the 40us default, a third
with the non-conforming clone display now uses hd44780_delay:
0.000050 and displays reliably - no more manual source patching
needed.
It’s a tiny, backward-compatible change (2 files, +8/-1 lines), but
since HD44780 displays are common in the RepRapDiscount/budget
printer space, I think it’s worth a look. Happy to answer questions
or adjust based on feedback.
Thanks for the pointer, @hcet14 — really appreciated. I hadn’t seen
PR #5318, and I want to make sure this attempt actually addresses
KevinOConnor’s concerns from back then rather than repeating them.
I’ve just pushed an update:
Configurability risk: hd44780_delay is now capped at 0.001s (1ms)
via maxval, so it’s no longer possible to set a value large enough
to meaningfully stall the mcu task queue - the config parser will
reject anything above that with a clear error instead of silently
accepting a dangerous value.
Guidance for non-technical users: the Config_Reference.md entry
now explains what the symptom looks like (garbled/randomly
changing characters), suggests raising the value in small steps
from the 40us default, and says to use the lowest value that
works - no Python knowledge required.
Unlike PR #5318 (which added two separate delay knobs -
hd44780_init_delay and hd44780_pin_delay), this PR only exposes the
single existing HD44780_DELAY constant that was already there and
already used for every command - it’s not introducing new timing
concepts, just making the existing one adjustable within a bounded,
documented range. Root-causing exactly which clone chips/wiring
combinations need more margin is a fair ask, but in the meantime this
gives affected users (my own case: an ACM2004 clone at 50us) a safe,
bounded way to fix it without patching source.
@Dampfwalze - if you have time to take a look, it would be very
welcome.
P.S.: And thanks for the welcome. Until now I was just a reader because I found everything I needed
My solution since was to bind mount the source file in question into the Klipper docker container, to replace it with the one from the old PR (since I prefer running with Docker Podman). But this will break eventually, so I am very happy to see movement.
This new PR is more clean, so I prefer it. Functionally they are identical. The additional initialization delay that the old PR introduced, I see that as a separate issue.
LGTM.
I am not a maintainer though, nor did I ever contribute to Klipper. I am just a programmer who happens to have a DIY 3D printer. So these are just my two cents.
Thanks for testing/confirming, @Dampfwalze — good to know it’s not just my own setup. Agreed the old PR’s extra init delay is a separate concern; keeping this one scoped to just the existing HD44780_DELAY constant was intentional.
