Small Pixel Errors on Display

[ckiefer]

Small pixel errors are shown on the display as of release amz_melzi_bed_bl_a2-bugfix-2.0.x-20210311-firmware.hex
Printer: Anycubic Mega Zero 2.0 with stock Melzi board, BL Touch attached to exp-a2 connector
Some pictures are here: https://photos.app.goo.gl/YqFMgkwE3Ro6Ti2Y7

[kad]

I think I found potential upstream changes that can cause those. Would you mind to try experimental build http://orava.kad.name/3d/experimental/amz_melzi_bed_bl_a2-bugfix-2.0.x-20210319-firmware.hex in your setup and see if that fixes it?

[ckiefer]

@kad Thx for the investigations. The pixel issues unfortunately still occur with this build.

[kad]

Do they start to appear right away after booting or only after some conditions?

[ckiefer]

Right after booting. Even on the very first screen with the Marlin logo. @kad You don't have it on your printer?

[kad]

Interesting. No, I can't reproduce that on the board that I have. Tried to flash bed+BLTouch in two variants (PIN27+EXT-A2 or EXT-A2+Zmin), both seems to be ok, the self-tests are passing.

https://ibb.co/7SxvC2C
https://ibb.co/54Hp1kQ
https://ibb.co/sFn9GN2
https://ibb.co/CmFQN7P

[ckiefer]

@kad I have checked my wiring and it looks ok. I am again using the build from March 10.
In the meantime I also ordered another mainboard I'd like to use: the BTT SKR Mini E3 V2.0. This will be a nice upgrade to my printer.

[kad]

@ckiefer SKR mini E3 V2.0 is indeed good board, but for MZ there is better one: BTT SKR mini MZ. It is schematically exactly as SKR mini E3 V2.0, but physical dimensions are specifically done to fit it into Anycubic Mega Zero case.

Regarding pixels errors, can you share photo of your board and wirings? might be something will give a hint...

[ckiefer]

@kad I've added a few pictures of my wiring here: https://photos.app.goo.gl/YqFMgkwE3Ro6Ti2Y7
Are the pictures useful?
Regarding the board: well I didn't see that there's also the same board for my MZ ... let's see, it's already shipped ...

[DENightOne]

I agree with @kad I bought the BTT SKR mini MZ and am very happy with how easy it was to swap with the standard board, also its extremly quiet.... Also you dont need to buy the 3.5inch TFT as the Mega Zero LCD works perfectly with the BTT SKR mini MZ. I bought the TFT because I thought I needed it, it does look very good at works great but its was not needed.

[kad]

@kad I've added a few pictures of my wiring here: https://photos.app.goo.gl/YqFMgkwE3Ro6Ti2Y7
Are the pictures useful?
yeah, looks good. What I'm thinking, is to try with EXT-A2+Zmin setup. servo (3pins) to EXT-A2 and 2 pins to zmin. and eliminate pin27 adapter and see if that would improve situation. Shouldn't be too much change, but really, for now I don't have explanation on LCD data garbage. :(

[ckiefer]

@kad I will try this too once in a while. Thx for the support!

[kad]

@ckiefer can you try latest 20210403 build? there were some updates regarding LCD+AVRs in upstream code

[ckiefer]

@kad Just tried it but still no luck. Pixel errors still occur. Many thx anyways.

[Kysztof]

Hey, I've experienced the same pixel problem on my MZ2 running this build:
http://orava.kad.name/3d/20210328/amz2_melzi-bugfix-2.0.x-20210328-firmware.hex
Gonna try the latest build and will update if this helped :)

[kad]

@Kysztof thx for report. if that wouldn't help, try to revert to some previous one... trying to triage where it starts.

[Kysztof]

Well, I flashed the latest build (http://orava.kad.name/3d/latest/amz2_melzi-bugfix-2.0.x-20210411-firmware.hex) and it looks like there are less pixel bugs showing on the screen :)
Also, turning knob seems to trigger those errors - maybe it is just screen refreshing, dunno, I thought it might be important for You.
Screen pictures: https://drive.google.com/drive/folders/1dtK4_2YNj4N1B4KK0fw3dL3o500T1HJZ?usp=sharing

[kad]

I suspect that something got broken with timings/delays for this type of LCDs in upstream code. I've seen changes for that on ARM based boards, and I suspect that same might happen to Atmel based boards (like stock one). However, I was not able to reproduce that on my board/display combination, thus I'm starting to suspect that default timings for these LCD controllers are also varying... :(

[Kysztof]

I see, well it is somehow better now - at least the screen is readable :D
I've got "spare" broken original LCD - the backlight and knob work, but there is no pixels showing, got another one from Anycubic. If You could make any use of it, I could send it to You.
I am quite a noob in terms of programming boards but, if I could help You anyhow - let me know :)

[kad]

@Kysztof thx, but I already have bunch of hardware in my lab. :)
Can you post a pictures of your LCD (back side, wirings) ?

[Kysztof]

Okay, it took me while but I've updated the drive link with LCD pictures :)
Besides, I've encountered some random reboots during longer prints (after about 3-5 hours).
Should I start a new thread? Is there any method to log such bug?

[kad]

@Kysztof @ckiefer regarding issues on LCD, based on photos it looks like different revision of LCD compared to what I had on my printer. So, definitely timings are off.

As I don't have such display revision, we need to experiment a bit, to see what would work.
In theory, adding those to Configuration.h should solve, but that would slow down LCD data transfer.

#define ST7920_DELAY_1 DELAY_NS(120)
#define ST7920_DELAY_2 DELAY_NS(80)
#define ST7920_DELAY_3 DELAY_NS(580)

Trying to adjust those figures down, probably we can find good value... e.g. about 80 / 80 / 200 or something in that range.