teeminus
Screen will always get garbled after a while.
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.
There seems to be a problem with the Biqu B1 board: https://github.com/teeminus/NoTouchScreenFirmware/discussions/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.
Interesting. By the way the same issue occurs when using the 'official' klipper enabled fw from BTT. I also posted this here: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/pull/1913#issuecomment-897653029
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.
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.
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.
Good luck, I hope this will fix the problem :)
Reporting back; had no effect unfortunately. Is there anything else we can try?
When using the emulated_st7920 Klipper display driver, you could try different bus speeds.
'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.
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.
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.
Have tried the original BTT firmware lately? Maybe the original firmware works better 🤷♂️
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.
That really sounds like voodoo as there were only minor changes which have nothing to do with the SPI interface...
I know, weird right, have suspected black magic all along... But I'm happy for now ;)
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.
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.
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.
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...
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.
@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 😂
@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.
@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 :bowtie:
@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.
I've had no issues since the Display is "disconnected" with the Chassis Ground.
@hapklaar Did you encounter the issue again or is 1.3.1 still working fine?
@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?
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.
