Screen info missing

Aero3D

For the past few weeks on both my Prusa and Creality, on which I have Raspberry Pi 3b's with Pi 7" screens, the display fails to update after starting a print. Sometimes it just stays as per the very first screen showing original ETE and ETA and layer 0 and never progresses and the progress indicator never updates. Also, on many but not all occasions many of the screens are missing most of the display objects. However, the Params option is always visible and if I click that the parameters screen is correct and then I can go back to the print or home screens.

Despite all of this the remote access via a browser never fails and is always correct. It is just the output on the 7" Pi screen that is all messed up.

Does anyone have any ideas? It has defeated me. I have tried different cables and also a 3A USB supply so have no yellow lightning bolt icon.

Thanks. I bought a license and love Repetier but having to consider going back to Octoprint (Yuk) or Astroprint (rather not).

Aero3D

So, 10 minutes into a print, started from the Pi screen and this is what I get. On the Printing screen, the Home button has disappeared so only way to navigate back is to select Temp or Params and then it reappears and can press it.

Aero3D

Whilst the remote screen via browser is still all present and correct

Repetier

These are web apps and completely independent. Touchscreen is connected via localhost so there is no problem in communication etc.

Did you use our image (which version) for the pi? There is a updated image now (V8) using latest debian stretch/chromium.

What seems to happen is that there happens an error in browser that stops parts from working as expected. Ihave not notived this problem so far, so it might be a defect in the files loaded that triggers this. So if you could make a new image with V8 and test if it is still there or not.

BTW: Did it work at the beginning and then started to fail 2 weeks ago?

Aero3D

HI. Thanks for the reply. Yes, it all worked fine initially, using your 0.86.2 image for Raspberry Pi, and then a few weeks ago just started behaving like this. I wonder whether it may be Marlin firmware related.

Aero3D

OK, downloaded and reloaded the latest Pi image and doing new tests. Note to self: save the previous printer profile before renewing image :)

Repetier

Ok, since it worked before without being updated I assume it has an other source. If you changed firmware that could be an issue, but I do not know how it should affect the interface in such a way. But lets see what the new image does.

Aero3D

OK, downloaded and reloaded the latest Pi image but absolutely no difference. First print, progress screen is locked without updating, if I switch to parameter screen and back to print screen all the info is missing as per the images above. Really disappointing as now acting in this way on both my Prusa and Creality, each using their own Pi and screen.

Repetier

Ok, so back to firmware theory. Did you upgrade firmware before it started not working? If so which firmware and version is it. Don't have both printers for testing but it might give a trace. What might be possible that now parsing some responses makes problems confusing interface when it interprets a invalid value. But that is just a guess, first we need to find the trigger.

As additional help, if you have no users defined, you can also run the interface in your PCs chrome
http://ip:3344/modules/front2/www/app.html/<br/></strong><br/>And open the developer tools->console.
I guess it will show some errors once it gets its problems and they might give some hints, even if names are shorted.

Aero3D

I have upgraded firmware to latest versions on both printers. On the Prusa I am using the latest Prusa 3.1.0 and on the CR10 I am using a fork of the latest Marlin. For the CR10 I have tried multiple versions of TH3D Studios Unified firmware and also a version by PrintedSolid and the results are the same. The strange thing is I have a friend who has the CR10 running the exact same firmware on his CR10 (I compiled it for him) and he has no problems using the same Pi3 with Pi 7" screen.

Aero3D

Just commenced a print with the interface running in Chrome and, for the first time in weeks, it is behaving properly, both in the Chrome interface AND the Pi screen. When complete I'll run another one without the Chrome interface and see how it behaves. More confusion :(

Repetier

Yes, I see that. Running a second instance on pc should not change how the pi chrome acts as they are independent. I think the trigger causing the problem just did not happen like with your friends version. Maybe it would be a good idea to activate logging while printing so you check around the time the error happens if log contains unusual content.

Aero3D

I've now run 2 prints without the PC interface and all is good. No idea what is going on but 2 consecutive prints with no loss of Pi screen interface. Looking at the Print logs though, there are regular Communication timeout warnings. No idea if this may have been a cause of previous issues but I've done nothing to the PI and now seems to be working correctly again. Very very strange.

The communication timeout warnings in the log appear about every 30 seconds.

Aero3D

Maybe time to buy some new USB cables. I think the one I'm using on the CR10 is an old Motorola Mobile cable (as it uses old style mini USB)

Repetier

Compile firmware to send line numbers with "ok". In log you see it has 109 bytes in buffer (server thinks so). But since nothing seems to happen it times out. This happens if "ok" is not detected due to com errors. Line numbers help server detect that one was missed and correct this on the fly.

I also wonder I see NO firmware responses in log. As you see with timeout server resets ok counter and send new commands but these should trigger an ok if connection is still healthy.

Aero3D

Running another big print now and all good via the browser interface in safari (http://ip:3344/modules/front2/www/app.html/) but the Pi screen is missing all the info again. I'll look into how to compile firmware as you suggest above, but I'm still at a loss to understand why my friend's works OK with exact same firmware but mine does not. Would/could cable quality affect anything?

Repetier

Communication problems with firmware can come from cable, but with the line number setting it should already get fixed as it does not seem to happen so often.
Communication to pis chrome is no cable issue as they are connected internally. The fact that one browser stops while the other stays working is more interesting a sit is the same app and both get same data most of the time.

WHat you could try is login to pi with ssh and run "top" to see memory usage. If you run out of memory due to a memory leak it could affect stability. Whcih page in the app do you watch while that happens? The print progress or something else?

Aero3D

Always the print progress screen. When I see that the circular progress indicator is not displaying and the layer number not progressing I switch to the Params or Temp screen and then back to the progress screen. It is then that all the graphics disappear. Also, the Temp screen never shows a graph when this happens but all params options are still there. So text seems to be OK but graphics are all missing.

Repetier

So if I understand you everything continues working except objects using the canvas html object - circle and temperature graph. That sounds like chrome stopped running canvas for some reason. So that part might be crashed or stopped on intention to maybe reduce memory. Did you test the memory usage? While it swings a bit it should not increase much over the time of the print.

You could also connect a mouse and open developer tools with context menu to see if chrome shows some error messages. Before edit /home/pi/.bashrc near end to remove --nocursor so you see your mouse pointe rafter reboot.

Aero3D

Now, even via the remote browser interface (Safari) I get this after clicking on an item to print. I give up. Will need to find an alternative solution I think.