Page MenuHomeAleph Objects Inc

When flashing Pro with Cura LE, the touchscreen flashes until you power cycle
Open, Needs TriagePublic

Description

The touchscreen flickers after flashing with Cura LE, it seems as if the screen is going bad. It does reset back to normal after a power cycle, but is that really a fix? I could see if a customer were to re-flash their machine at home they would wonder if their screen was all of a sudden going bad.
I've never seen this happen while flashing with the terminal.

Event Timeline

paulette created this object with visibility "LulzBot Hardware Products (Project)".
DaniAO assigned this task to marcio.Tue, Jun 11, 12:58 PM
DaniAO changed the visibility from "LulzBot Hardware Products (Project)" to "Public (No Login Required)".
DaniAO changed the edit policy from "All Users" to "LulzBot Hardware Products (Project)".

I have one thats doing this all the time, even after a power cycle. @marcio

When looking at the machine at an angle its not that bad, but when looking right at it its bad.

This is actually a tricky problem to solve. When the printer is being flashed, there is no software running on it, so there is nothing to send valid signals to the screen. Different screens seem to behave differently in that situation. A lot of displays stay black, but some seem to flash in weird ways.

marcio added a subscriber: alexei.Wed, Jun 12, 9:58 AM

If flashing from the terminal and flashing from Cura behaves differently, then perhaps this is something @alexei could comment on.

When flashing through Cura, the screen does this weird fade out, where it looks like static on your TV and increases density over the whole screen. When flashing through the terminal, the screen is black during the flashing process. Could this "fuzz" be affecting the way the screen is displaying and causing some sort of residual static/flashing?

oliver added a subscriber: oliver.Wed, Jun 12, 10:12 AM

The machine that @robert is mentioning has persisted across a firmware update that usually either lessens the flickering or causes it to disappear. The worst machine has been red tagged and is currently sitting waiting for on whether R&D would like to inspect it. We are unsure if this is acceptable to pass and are not sure where the problem lies.

@robert are we seeing this on all the printer, some or only the one?

@DaniAO We saw it on a printer Paulette just had but reflashing it seemed to really help but you could still see a little flickering on blank grey screens, but so far its only been 2 machines and only 1 of them MER and us thought wouldn't be passable.

It may not be a pass according to our standards, but it does not mean the LCD is defective, the LCD is simply being put into a state it was not designed to operate under and it may behave differently depending on manufacturing variances. If we had identified this issue earlier in Quiver development, we might have been able to come up with a hardware workaround. Right now, our choices are limited to finding a software only fix. If we know for sure that flashing from the terminal behaves differently than flashing from Cura, then that is a lead to follow, but only if it consistently works better in one vs the other.

One quick test. Turn the brightness as low as it goes in the LCD panel prior to flashing FW. Then try flashing. If the brightness remains low and obscures the display flickering, we could possibly work something in to have Cura turn the brightness way down before flashing FW. But if the brightness turns up on its own, then we are SOL.

@marcio , @robert I don't see how flashing through BOSSA vs flashing through BOSSA.py can be different tbh. As @marcio said above, we can try to send g-code that lowers LCD brightness before starting flashing, but otherwise we'll not be able to fix this.

Tell people their printer is flashing. Literally. It's a feature.

@DaniAO the flickering screen after flashing firmware with Cura is any machine we've tried so far. (at least 4)

marcio added a comment.EditedWed, Jun 12, 10:45 AM

@alexei: The display board is essentially it's own microcontroller with a separate framebuffer. If "flashing" the AVR involves a soft-reset, that would leave the I/O lines active, then supposedly the display controller could continue showing the previous framebuffer. The problem occurs if the AVR resets and tri-states the I/O pins. This will cause the reset line to the microcontroller to either float, or get pulled down. This will stop the display controller, leaving the LCD now susceptible to noise (which is probably what causes the "fade" effect).

If there was a way to flash the AVR without affecting the I/O lines (i.e. without a reset), that would be ideal. Or, better yet, if it could flash to a different location in the SPI flash, and then reboot to that new location, so that the MCU could remain active during programming, that would be great too, But I don't know enough about how flashing happens to know whether those things are even possible.

bmh added a subscriber: bmh.Wed, Jun 12, 11:11 AM

While making it not flash at all would be ideal, could you just put a message in Cura during the flashing that the LCD screen might flicker and that this is normal. Maybe then also make part of the "flashing procedure" that after flashing, tell the user via a dialog to recycle the printer to complete the process. An idea that might make it seem "normal"/"expected" :-).

After showing Dani the problem we discussed it and depending on the severity of the flickering we'll use a judgment call on whether or not we should send it. If it flickers just a tiny bit like the one Paulette had earlier we'll pass it and if its more like the one I had we'll reject it. Unfortunately theres not really a clear way we can post examples though without just seeing it in person.

@marcio a Pro printer that was exhibiting these issues was sent over with the inventory team this morning. Please review it and test your thought.

Thanks!

Good news. Turning down the brightness prior to initiating the flash does hide the flickering.

Better news. No new GCODE or Cura changes needed. The firmware is what resets the board when it detects a 1200 baud rate, so I was able to modify it to turn down the display prior to resetting itself.

This change is in .133. What do you want me to do with the non-conforming printer? With this new FW, it's good.

@marcio good to hear! you can send that printer back with the inventory team. This is the only update for pro correct? It shouldn't change anything and we can start using it?

@alexei I know we were putting .116 in 3.6.10, but can we update that to this firmware? Is this something we can start using now?

@DaniAO: This FW has received virtually no testing. I think it needs to become a release candidate and we need to test it for a few weeks.

BTW, the non-conforming printer now has .133. If this goes back, it either needs to be restored to the older FW, or it will need to sit around until the new release candidate is approved.

DaniAO added a subscriber: logan.Fri, Jun 14, 8:38 AM

okay let who ever knows when they take it back to take it to MER

@MikeR @logan @oliver @zachah please watch for this printer and put it on the red tag shelf with a note about the firmware..

Please and thanks!

marcio added a comment.EditedFri, Jun 14, 8:44 AM

FWIW, .116 is very old. There have been several tickets worked on since that release, T7168, T7178, T7320, T7535, T7840, T7789. I think we are overdue for a new RC. It could become the RC for Redgum and Quiver.

@TyTh @Galadriel What are your thoughts on this flicker when updating firmware, do you think this will cause confusion or problems for customers in the field?

Please test this on the Pros you have at lago, and let us know what you think

TyTh added a comment.Fri, Jun 14, 1:42 PM

I don't think this would cause confusion, maybe the odd question but I doubt it. As long as the screen goes back to normal as soon as the update is done, it should be fine.

Having seen the issue... it makes it look like something is wrong with the screen. On the one printer that @paulette and@robert showed me, it kept flickering after the printer has been flashed. I feel like this is going to cause much more concern in the field then it should.

TyTh added a comment.Fri, Jun 14, 1:46 PM

@DaniAO
I have seen Cory update firmware, not care about it and it went back to normal when it finished. I'll have to do more testing for final confirmation.

It's not every printer.. it's hit or miss on which printer it is..

logan added a comment.Fri, Jun 14, 1:50 PM

@DaniAO
I saw those printers that @robert and @paulette had. The one that Robert had it was prominent and visible on all screens and reminded me of when a fluorescent light bulb is starting to go bad and begins to flicker/pulse. The unit that Paulette had was less prominent, and only visible on darker screens. This was all outside of flashing FW.

If I paid the price tag for the machine, I would be bothered by it.

@logan agreed. It looks like @marcio has a fix.. but we have to test the firmware first.