Dual color screen display artifacts

[jghake]

I'm not sure what's happening here...

[sethvoltz]

Are you talking about the glitching at the top and the missing pixel row at the bottom?

I'm not sure either, I have been testing the various display modes and they have been working well over here. I wonder if there's some signaling issue on the data lines?

[Andy-ABTec]

It's interesting, a little Photoshop jiggery-pokery shows that the "glitching" row at the top IS the missing pixel row at the bottom! Hope it helps... 😎

[bluespaniel]

I have a single colour display and I have the same issue with the latest version.

[Andy-ABTec]

Just out of interest what happens if you set the progress bar to be displayed at the bottom?

[sethvoltz]

Hmm, running through screens on my build (my printer is running the release version) and I'm not getting the artifacts. I still think there is something about the wiring that's getting you. One thing that comes to mind is that with short wires and a single device, internal pull-ups are sufficient for I2C comms, however for longer runs you might need to add a 4.7k pull-up resistor for each of the SCL and SDA lines to the 3.3v rail.

[patofoto]

Same issue here. Working on designing a custom case. Using short cables. No buttons yet, just the screen.

[patofoto]

Interesting. As soon as the job was done, problem went away. Guessing it will come back as soon as I get another job going. Will confirm in a few minutes.

[patofoto]

Confirmed. Offset line only visible when job printing. At least for me.

[patofoto]

It seems the the screen is offset by one line. When the job starts and the bottom-most line appears, it wraps to the top. Here is a video of what happens:

https://user-images.githubusercontent.com/37857628/107169699-8b663000-698c-11eb-8e94-3140c2b2c250.mov

[patofoto]

Sorry for the barrage of messages. Figured that the more information you have the better. Apologies if too much. Here is the OLED I am using.

[sethvoltz]

Interesting, thanks for the extra info. I was testing just shy of the print head going down. I’ll check for that when this print finishes. With the progress on bottom, I don’t see any glitches even 70% in right now.

[patofoto]

Updated to 2.0.1 this morning and still have the same issue. Just reporting. Since I don't have any buttons I cannot test the other mode screens. Is there a way to have a way to have a software UI for the buttons also?. After checking to turn 180deg and also the progress-on-top checkbox to see if this time things were different, I have this screen display now.

This one seems to be correct but displays another set of info. Assume it is one of the mode screens you can toggle through. Unsure of how I got it to change to this. Happened after clicking one of the above mentioned options.

[sethvoltz]

Yep, that’s the system status screen and is the normal default. The plugin auto-switches to the print status screen on print start, however if you change the options it will reset the display. Without a mode button, there isn’t a way to switch back. The screen is meant to be tightly coupled with the physical buttons

[patofoto]

Thanks. Any way to add software buttons to the OctoPrint interface?. I am thinking that I am really only interested in the mode button. Maybe only need an option to check for automatic cycling of screens for people that don't want buttons. Possible?. I recently discovered a small Wifi enabled monitor for OctoPrint that uses the same display and cycles through all the info (including the weather! 😂

https://github.com/Qrome/printer-monitor

[unclej84]

As far as I can see on the video the progress bar is not cut on top when the line gets "added" which is strange because it starts at row 0 which is the first one. So there should be no line above it and "normally" it would override the first row of the box around the progress bar. The reason for coming from buttom to top is the image or pillow library which breaks everything below the last row back to the first row. I am not sure if this is even possible but it looks like your display is starting to draw at row -1. Could you try as @Andy-ABTec suggested to check without "Progress on top"?

[unclej84]

For testing proposes you could add following code(4 tabs indent) here:

self.draw.rectangle((0, 0, self.width, self.height), fill=0) self.draw.rectangle((0, 0, 1, 1), fill=255, outline=255, width=1) self.draw.rectangle((self.width - 1, self.height - 1, 1, 1), fill=255, outline=255, width=1)

This will clear the screen and add one pixel to the top left and one pixel to the bottom right. Would be interesting to see where they appear on your screen.

[patofoto]

Progress on top still displays the shift:

In the process of printing at the moment so will try your lines of code as soon as I can. Thank you.

[patofoto]

Have not tried the test lines of code. Need to finish printing something first but noticed today that the display is ok now. Have not changed anything since I last posted a picture. Weird.

[jghake]

Gah I came back here to say I still have the problem. I didn't realize there was a test fix. Why are we always in the middle of a print?!?

[sethvoltz]

@patofoto have you still been running fine without the shift? Also, you should post your build in the Show and Tell thread.

@jghake did it come back again? Can you run the test code to see what happens?

[patofoto]

@sethvoltz I have been running my OctoPrint Pi without a problem but with the monochrome version of the OLED display. I did purchase a yellow and blue version again but the size is slightly different and did not fit the current design. I got involved in other projects and put the display problems on the back burner. Current status is that it is running fine with the white monochrome version. Would need to buy a new bicolor one to keep testing. What models have you tested and tryed successfully. I will buy one you recommend.

I have not had time to try @unclej84 code. Apologies.

[timinator2020]

Here's a little more detail about how to reproduce this (at least for me).

First, I have a single color display so it isn't related to the display (monochrome or "yellow-on-top"). Second, it only appears to happen when the DisplayLayerProgress plugin is installed. Third, it only appears to happen when the status bar is set to be displayed at the top. If I leave it at the bottom, it's fine.

The magic sauce seems to be DisplayLayerProgress. I think the artifacts you see on the top of the display are the pixels from the bottom of the display wrapping around to the top. When the layer info is printed, not everything fits on the display. I think.

I think that also explains the comments above (why does it look fine until the print starts, and why does it look fine when the print is finished? Because the DLP layer info is removed from the display before and after the printing process).

WARNING: PLEASE don't try anything below until the DEV weighs in with their opinion. I am not a python developer (I barely know python at all).

As a quick hack, I simply changed the value of _colored_strip_height from 16 to 15 in ~/oprint/lib/python3.7/site-packages/octoprint_display_panel/init.py (moving all the text up 1 pixel). After changing that, everything seems to line up and display properly.

I honestly don't know if the yellow strip height varies per panel, or if it was simply off by 1 (maybe the pixel row starts at 0, so 15 would be 16 rows?).

I hope this info was helpful. I wanted to provide it since I'm thinking about using this plugin for an "emergency PAUSE button", and I like the look of the yellow progress bar across the top :)

[patofoto]

@timinator2020 I just got a dual color screen today and swapped it from the monochrome one I had been using. Followed (with caution and propelled by curiosity) to change the 16 to 15 in the .py file and after a quick test, I can say it looks very promising. It worked. I will try printing something tomorrow and give it a good run. Thank you.

[patofoto]

Can confirm that it is working perfectly so far. Changing the 16 to 15 in the .py file seems to do the job.