Screen will always get garbled after a while.

[hapklaar]

Used both modes (emulated and not), but in both cases the screen (TFT35-B1 in a Biqu B1) always gets garbled after a little while.

#[display]
#lcd_type: st7920 
#cs_pin: EXP1_4
#sclk_pin: EXP1_5
#sid_pin: EXP1_3
#encoder_pins: ^EXP2_5, ^EXP2_3
#click_pin: ^!EXP1_2

[display]
lcd_type: emulated_st7920
spi_software_miso_pin: EXP2_1
spi_software_mosi_pin: EXP1_3
spi_software_sclk_pin: EXP1_5
en_pin: EXP1_4
encoder_pins: ^EXP2_3, ^EXP2_5
click_pin: ^!EXP1_2

Starting to think it might be some interference going on with the EXP1/EXP2 cables internally, but these issues don't surface when using the normal fw with Marlin mode. This makes me wonder why this implementation suffers from this issue.

[teeminus]

There seems to be a problem with the Biqu B1 board: #43

Could be a timing issue. The BTT firmware and this firmware share most of the hardware drivers, but there are minor differences in the SPI part. The problem could be caused by this. But other than that, I have no idea what could cause the problem.

[hapklaar]

Interesting. By the way the same issue occurs when using the 'official' klipper enabled fw from BTT. I also posted this here: bigtreetech/BIGTREETECH-TouchScreenFirmware#1913 (comment)

[teeminus]

Well, thats interesting...

The improved ST7920 driver (both this firmware and the MR by Msq001 in the original firmware) are more CPU consuming than the previous implementation. Could be a timing issue inside the MCU (e.g. when the I/O resources are used simultaneously, but thats just a quick guess).

Whats also interesting is, that so far only the Biqu B1 board has been reported to have this issue.

[hapklaar]

The B1 uses a standard SKR 1.4 mainboard, but the TFT is slightly different and specially made for the B1. It also requires a firmware compiled specifically for the B1. No idea what the internal differences are though...

I will try moving the cables around a bit and see if that makes any difference. Read somewhere (I can't find it anymore) someone had some success by looping the EXP cables though some ferrite cores.

[teeminus]

Good luck, I hope this will fix the problem :)

[BrianValente]

I'm having the same problem with the SKR Mini E3 v2 in an Ender 3 Pro

[BryanHaven]

I was seeing the same issue as @BrianValente - after I did a power cycle it's stuck on the Emulator Ready screen and nothing beyond that - I'm going to try reinstalling the firmware and see if that helps.

Update: I reflashed the firmware and that seems to have resolved this issue for the time being.

[hapklaar]

Good luck, I hope this will fix the problem :)

Reporting back; had no effect unfortunately. Is there anything else we can try?

[teeminus]

When using the emulated_st7920 Klipper display driver, you could try different bus speeds.

[hapklaar]

How can I do that? Is that an option in klipper's printer.cfg?

[teeminus]

'spi_speed', see https://www.klipper3d.org/Config_Reference.html?h=spi_speed#common-spi-settings

The default value is 1MHz, minimal value is 100kHz.

[hapklaar]

I don't notice any difference in behavior when using other speeds. Tried from 100000 to 4000000 like this:

[display]
lcd_type: emulated_st7920
spi_software_miso_pin: EXP2_1
spi_software_mosi_pin: EXP1_3
spi_software_sclk_pin: EXP1_5
spi_speed: 100000
en_pin: EXP1_4
encoder_pins: ^EXP2_3, ^EXP2_5
click_pin: ^!EXP1_2

However did notice the screen only garbles up when the Y axis motor (bed) is being driven. Just homing that axis triggers it. So tried rerouting the cable for that motor, but unfortunately also no difference.

[teeminus]

Maybe the issue is caused by crosstalk on the mainboard.

[markcarroll]

I am seeing the same problems on a BTT SKR 2 with BTT TFT35 E3 V3.0. Here are my settings:

[display]
lcd_type: emulated_st7920
spi_software_miso_pin: EXP2_1
spi_software_mosi_pin: EXP1_3
spi_software_sclk_pin: EXP1_5
en_pin: EXP1_4
encoder_pins: ^EXP2_5, ^EXP2_3
click_pin: ^!EXP1_2

It goes wrong for me on homing too, but only when the X and Y axes both move at the same time. Homing X is fine, homing Y is fine, then it moves the probe to the center to home Z and that is when it garbles.

[teeminus]

Have tried the original BTT firmware lately? Maybe the original firmware works better 🤷‍♂️

[hapklaar]

Have tried the original BTT firmware lately? Maybe the original firmware works better 🤷‍♂️

Actually your current 1.3.1 release works almost flawlessly for me. In about 100 prints I only had one occasion where the screen froze and one where it garbled up, both at the start of a print. This is much better than before, where it went wrong almost 90% of the time.

[teeminus]

That really sounds like voodoo as there were only minor changes which have nothing to do with the SPI interface...

[hapklaar]

I know, weird right, have suspected black magic all along... But I'm happy for now ;)

[TazerReloaded]

Maybe you could try a shielded cable for the display, for example CAT7 LAN. Connect the shield to a earthed case or GND.
Strange anyways, I have stepper and display cables routed together and none of them is shielded, no issues even with 10h+ prints, I even bought longer cables because I wanted my display in front of the printer.

[hapklaar]

I don't think it's cable related. Have tried many different cable layouts and also ferrite cores etc, that all made no difference at all.

[pixeldoc2000]

This is really weird!

Same issue here with BIQU B1 and TFT35-B1 with BIGTREETECH-TouchScreenFirmware in Marlin Mode. So I guess it has noting to with this Firmware.

Maybe it is down to an SPI Bus Problem. Also though about testing ferrite cores and cable routing.

I will try to hook up my Logic Analyser to the SPI Bus so see whats going on.

[pixeldoc2000]

Weird...

Today I dismounted the Display Unit from the Printer and hooked in my Logic Analyzer. The Issue was gone.

Looks like the Problem does not happen when the Display has no connection to the Printer Chassis (metal housing).

Maybe we have some intermittent Ground Loop Issue when the Display has more or less Contact with the Chassis of the Printer, which is connected to the Earth Wire / Neutral Wire (in EU / Germany).

I will have to do some prints to ensure the Problem does not happen this way.

@hapklaar
Maybe you can give it a try...

[BryanHaven]

Interesting, does anyone who has a replaced the metal bracket with a printed enclosure seem to have this issue?

…

Sent from my iPhone

On Nov 30, 2021, at 7:06 PM, pixel::doc ***@***.***> wrote:  Weird... Today I dismounted the Display from the Printer and hooked in my Logic Analyzer. The Issue was gone. Looks like the Problem does not happen when the Display has no connection to the Printer Chassis (metal housing). Maybe we have some intermittent Ground Loop Issue when the Display has more or less Contact with the Chassis of the Printer, which is connected to the Earth Wire / Neutral Wire (in EU / Germany). I will have to do some prints to ensure the Problem does not happen this way. @hapklaar Maybe you can give it a try... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[teeminus]

@pixeldoc2000 Very interesting discovery. Could be indeed some kind of ground loop. Or some interferences coupling into the display. Or some difference of potential between the frame and the ground connection of the printer.

My display is electrically isolated from the frame. It's basically dangling on a strain of yarn since my printer enclosure is not done yet 😂

[hapklaar]

@pixeldoc2000 For unknown reasons I'm no longer experiencing the issue since updating to 1.3.1.

When the issue rears its head again, I will investigate any grounding issues.

PS My B1 is not connected to a grounded mains socket.

[pixeldoc2000]

@hapklaar
Ok. But why isn't it grounded? In what Country do you live? Sounds unsafe to me...

Did two successful prints in a row and the Display is still not garbled and useable while not connected to the Chassis. I believe it's a first for me. ATM, this seems to fix the issue.

BTW, I am a Sysadmin too

@teeminus
The question remain, why does it happen only with Klipper and not with Marlin? Maybe we will have to dive into the Marlin Source Code to figure out if the SPI Bus or other hardware aspects are handled differently like enable pullups or else.

Maybe I will try a "proper" ground connection between the Display and the Chassis next and see if the issue reappears.

[pixeldoc2000]

I've had no issues since the Display is "disconnected" with the Chassis Ground.

[teeminus]

@hapklaar Did you encounter the issue again or is 1.3.1 still working fine?

[hapklaar]

@hapklaar Did you encounter the issue again or is 1.3.1 still working fine?

Haven't had the issue anymore after that one time since I installed 1.3.1.

PS. Now I've come to think of it, it might be that I changed the powersupply of the Pi at or shortly after the time I upgraded to 1.3.1. As the Pi is connected to the printer by USB cable, this can have an effect on the ground plane of the printer which seems to be involved in this issue?

[Revenger]

I am getting this myself on my Ender 3 Pro SKR Mini E3 2.0 and TFT35 with Klipper Octoprint on a Pi3B+
So wondering if anyone has a solution will have to investigate sometime.

[TazerReloaded]

I am getting this myself on my Ender 3 Pro SKR Mini E3 2.0 and TFT35 with Klipper Octoprint on a Pi3B+ So wondering if anyone has a solution will have to investigate sometime.

Is your display PCB connected to the printer frame somewhere (screws)? Mine is held by a printed bracket and has only the wires electrically connected. But I have a TFT24, maybe it's hardware related. I also recommend a quality power supply and separate wires for the high power components and the electronics, some chips crash if the power supply is unstable. Maybe a capacitor on the power input side of the display helps?

[Revenger]

Here's a test I did.
Both screens not connected to the frame, both sitting on a bathroom tile when powered.
BTT TFT 35 is glitchy.
Default screen is fine.

[teeminus]

Thanks for your investigations and your feedback. This supports the suspicion, that it’s a hardware/grounding problem caused by the screen itself rather than the firmware.

[Revenger]

Went back to Marlin reflashed my Pi to the backup I made just before Klipper to test a different issue and everything was fine when screen was detected.

At this stage all I can think of is its the klipper firmware on the printer or the klipper driver for the screen doing something different than Marlin causing the issue on the BTT screens.

[BrockPlaysFortnite]

Is there any update on this? I have also had this problem more and more lately. At first it was every now and then but now it's almost every day.

It happened just now as I opened the printed screen cover for my Ender 3 pro and it made me think it had to be related somehow to the cables or screen itself that slightly wiggled when I opened it since there's no way it happened randomly just as I was opening the screen cover.

[teeminus]

It's most likely a grounding issue, like a grounding loop that interferes with the data signals. For me, isolating the display from the frame works pretty well.

[bkenobi]

I just tried my first print with this firmware and it pretty much immediately started glitching. Is it still believed to be a grounding issue or is there anything else I should consider? The firmware was sooo much more stable than the BTT firmware in Marlin mode up until trying to print.

[bkenobi]

I printed a few more parts and this seems random. Sometimes it works fine. Other times it will get garbled after it initiates the print (fine during bed leveling). I'm not sure I can provide anything to help since it seems somewhat random at the moment.

[TazerReloaded]

Could you check if one of the heaters has an influence on the screen?

• turn heaters on and off, individually or together, and see if the screen has issues
• move the printer around manually, turn lights, fans and other stuff on and off
• if during one of those operations the screen gets garbled, try a "dry print" with that feature disabled. Many slicers can disable extrusion for tests, so you can "print" without heaters.

I sometimes had the garbled screen problem with the old 12864 display and Marlin, which was a hardware implementation, so I don't think it's an issue with the emulation, but with communication or the display driver, most likely electrical (inductive coupling, ground loop, under voltage).
Unfortunately that's very hard to diagnose, and I replaced almost every part of my printer since I had that issue, so I don't know what caused it then and can't test anything myself.

Here is my setup, which has worked without issues for years now, maybe you can test some of those points:

• main board is a BTT SKR 1.4, display is a BTT TFT24
• display is not electrically connected to the aluminium frame
• cables are quite long, around 50cm between main board and display
• cables run alongside other cables (steppers and heaters), but only for a few centimeters, not the entire length
• multi-rail power supply for industrial PCs, separate rails for electronics/steppers and heaters/fans
• configuration is as posted above by markcarroll, stock Klipper, nothing special
• printer frame is not well grounded, many plastic parts between metal components, the heated bed is connected to PE, but everything else is floating

[bkenobi]

I have not had a chance to perform any of the recommended checks. However, I did notice my nozzle had backed out a bit requiring a schmoo (PLA) cleanup. When I touched the hotend with my wrench to remove the nozzle, the display seems to have reset. Later when I reinstalled the nozzle, the wrench caused it to change a few characters which is what happens during the garbled screen issues.

I had grounded myself to the frame of the Ender3 before touching the wrench to the hotend so I didn't shock anything. But, I suspect there could be an issue with a lose connection somewhere that causes things to ground. OR, when I touched the hotend I moved the x-axis which caused some feedback through the motor and made the control board upset. I'll monitor because the last couple times I've used the printer the display has been working fine.

[bkenobi]

I can't say I have resolved this issue, but I believe there's a chance I figured it out. A few weeks ago my x-axis controller stopped working on my SKR mini E3 v1.2 board. I thought it was an overheat issue related to the electronics enclosure not getting enough air flow. While that is still possible, I also found after doing some tests that the RPi was powering the SKR via the USB plug in addition to it being powered directly from the PSU. This would cause an issue with a shared ground that may not match and could very well be the source of my ungrounded condition causing shocks.

After applying some strategically placed electrical tape in the connector, I no longer have a dual power supply to the SKR and both should be properly grounded. I have not seen nearly the amount of static discharge since and do not recall having the screen become garbled as I was experiencing regularly in the past. I plan on replacing the board with a full sized SKR which will make it possible to go back to the stock Ender display but I wanted to suggest the solution I found (I think) so others might have something else to check.

Edit:
I was testing some settings with Cura today and when I finished one of the tests the screen got garbled. This is with a loaner SKR mini and I do not plan on staying with this config (either board or display). I guess ignore my comment about USB power solving anything.

[killrob]

i had quite this issue too using an SKR mini E3 V2 and BTT TFT35 E3 V3
this is my config:
[display]
lcd_type: emulated_st7920
en_pin: EXP1_7
spi_software_sclk_pin: EXP1_6
spi_software_mosi_pin: EXP1_8
spi_software_miso_pin: PA3
encoder_pins: ^EXP1_5, ^EXP1_3
click_pin: ^!EXP1_2

but the screen is black with only "marlin mode" on top screen and nothing else.