Screen get's stuck after few minutes in printing status menu

[mrcg]

I really love the OctoPrint-TFT addon. Unfortunately i have the issue that OctoPrint-TFT get's stuck after few minutes.

The problem happens only in the printing status menu. In all other menu's the issue is not happening. That's the reason why i think it is not related to screen timeout settings.

The issue happens also in the printing status menu if printer is in idle mode (no print ongoing). After few minutes screen get's stuck (no screen updates) and it is also not possible to go back to home screen.

Would be great to get this fixed soon. Thanks for support.

[ppamidimarri]

I have the same issue. The screen wakes up from timeout, but is stuck in the Status screen. It won't go back, and the Stop button doesn't do anything either. The status information in the progress bar is also out of date when this happens. I am running OctoPi on a 3B+ with a Pi touchscreen and the Pi Camera module v2. The printer is a Prusa i3 MK3.

I love this UI on my Pi touchscreen, best way by far to use OctoPi when I am home!

[EissaAl]

same issue with OctoPi on a 3B+, printer is a Prusa i3 MK2S.

[EissaAl]

omg just fixed the issue by following this https://askubuntu.com/questions/476036/xset-unable-to-open-display

then this https://raspberrypi.stackexchange.com/questions/752/how-do-i-prevent-the-screen-from-going-blank

what i did to solve this problem i tried this command xset s noblank but it keeps saying xsetroot: unable to open display ':0' this mean my display is at DISPLAY=:1 so i entered export DISPLAY=:1 then xset s off # don't activate screensaver xset -dpms # disable DPMS (Energy Star) features. xset s noblank # don't blank the video device

[mrcg]

Hey EissaAl, i would like to be happy with you. But the issue here is a total other issue than yours. For your mentioned issue there was already solution posted in the closed topic section.

The topic here is only happening in the "printing status" menu after some time. And also the screen does not become blank.

So for the moment there seems to be no solution for this issue.

[zombu2]

Same problem here after a couple minutes on printing status the display goes unresponsive and does not update

[mrcg]

I did tcpdump trace to find out if there is special communication issue between frontend (octoprint-api) and backand (octoprint-tft).

Octoprint-TFT got stuck after sending "GET /api/job" command which is regulary (every 5sec) triggered from source file "status.go". Usually octoprint server replies withing few ms. At the time when octoprint-tft get's stuck i realized that there was no response from octoprint server.

Because of the missing response (resulting in missing variable) the following calculation is failing ... causing octoprint-tft to get stuck ???

switch s.Progress.Completion {
	case 100:
		text = fmt.Sprintf("Job Completed in %s", time.Duration(int64(s.Job.LastPrintTime)*1e9))
	case 0:
		text = "Warming up ..."
	default:
		e := time.Duration(int64(s.Progress.PrintTime) * 1e9)
		l := time.Duration(int64(s.Progress.PrintTimeLeft) * 1e9)
		text = fmt.Sprintf("Elapsed/Left: %s / %s", e, l)
		if l == 0 {
			text = fmt.Sprintf("Elapsed: %s", e)
		}
}

I am not 100% sure but for me it looks like to be the root cause. If this is the root cause solution could be use the "completion" variable provided from the octoprint-server without resetting the variable every 5sec. By this we should be "robust" also about missing answer from octoprint-server.

Would be great to get indication from one of the developers.

[mrcg]

Yesterday i have reproduced the issue another two times and the failure scenario is always the same. On "GET /api/job" there is no response from the server visible abd then octoprint-tft gets stuck. I also can see that response from server can take up to 5 seconds which could also cause some issues as the polling interval in octoprint-tft is also 5 seconds.

Suggestion to solve the issue could be:

1. Increase polling time to 10s.
2. Add robustness to the code so that missing HTTP reply does not cause any issue. E.g. Store previous variables until the get overwritten with udpated one.
3. Remove remaining printing time calculation and use instead the remaining printing time variable from the octoprint server response.

Unfortunately i have not much coding experience on souce code like this. Can someone help here?

[mrcg]

Regarding suggestion 3: I think the issue is caused by this calculations from "status.go":

e := time.Duration(int64(s.Progress.PrintTime) * 1e9) l := time.Duration(int64(s.Progress.PrintTimeLeft) * 1e9)

Maybe the calculation is failing because of missing update from both variables (due to missing response from server)???

[mrcg]

I am stopping my investigations here because i could not understand how to modify the "status.go" source. :-(

[The5py]

All working well in my end now the only issue keep happening to me seem to be known issues but making it not possible to use octoprint-tft: Screen get's stuck after few minutes in printing status menu (issue #34) and
Freeze while printing (issue #28) Any solution for them yet? Is there anyone it's not happening to him? Any workaround?

[ppamidimarri]

Thank you mrcg for your investigations. I tried to test your theory, so here are the changes I made to status.go:

        switch s.Progress.Completion {
        case 100:
//              text = fmt.Sprintf("Job Completed in %s", time.Duration(int64(s.Job.LastPrintTime)*1e9))
                text = fmt.Sprintf("Job Completed")
        case 0:
                text = "Warming up ..."
        default:
//              e := time.Duration(int64(s.Progress.PrintTime) * 1e9)
//              l := time.Duration(int64(s.Progress.PrintTimeLeft) * 1e9)
//              text = fmt.Sprintf("Elapsed/Left: %s / %s", e, l)
                text = fmt.Sprintf("Job in progress")
//              if l == 0 {
//                      text = fmt.Sprintf("Elapsed: %s", e)
//              }
        }

        m.left.Label.SetLabel(text)

Attached is the deb package that I built for Raspbian Stretch (OctoPi image) with these changes. My printer is broken right now (bed thermistor needs changing) so I can't test it right now. If you want to test it, install this file with dpkg -i and check if the problem is fixed. octoprint-tft_0.0-git04dd1f0-1_armhf.zip

[mrcg]

@ppamidimarri Many thanks for compiling the deb package!!! I will be able to test it earliest next week on monday. For trouble shooting it is good that you have taken out the printing time estimation completely. This should allow us to prove the concept in order to define final solution. I will report after testing on my 3d printer next week. Stay tuned!

[ppamidimarri]

@mrcg I fixed my printer and ran one job. I can see the new text "Job in progress" instead of the times. But unfortunately the screen got stuck around 30% into a one-hour job. So this doesn't seem to be the real issue. I will try to look further.

[mrcg]

@ppamidimarri Good that you have fixed your printer and have been able to test.

I think we need to modify also this:

 m.pb.SetFraction(s.Progress.Completion / 100)

Beside the calculation it would be great if you could make one deb package by only increasing the new background task time from 5 to 10 seconds. This should (hopefully) help to give more time for the reply if timeout is the real root cause:

 m.b = NewBackgroundTask(time.Second*5, m.update)

WDYT?

[ppamidimarri]

Yes, I changed that frequency of API call to once every 10 seconds.

m.b = NewBackgroundTask(time.Second*10, m.update)

I reverted the rest of the changes in status.go to original, except this line for clearer logic:

        default:
                e := time.Duration(int64(s.Progress.PrintTime) * 1e9)
                l := time.Duration(int64(s.Progress.PrintTimeLeft) * 1e9)
                if l == 0 {
                        text = fmt.Sprintf("Elapsed: %s", e)
                } else {
                        text = fmt.Sprintf("Elapsed/Left: %s / %s", e, l)
                }

Here is the Debian package with these changes. I will test this now. octoprint-tft_0.0_git04dd1f0-1_armhf.zip

Edit: This did not fix the problem either. The status screen got stuck 10 minutes into a 3 hours print.

[mrcg]

I have no access to my printer until monday. I am crossing my fingers that your tests are successful.

[ppamidimarri]

I tried to diagnose the problem using more log messages at the debug level in status.go in the code @mrcg highlighted. I also added this line to debian/octoprint-tft.service to see if any error messages are generated when the status panel hangs:

StandardError=journal

However I can't see any error messages using journalctl -t xinit around the time of the status panel hangs. Debug messages added to the line updating the text label show up in the journal until just before the panel hangs.

I am unable to fix the real problem. So I decided to put in a small workaround that reduces the frequency of this problem. In ui.go, there is a line that opens the status panel automatically when the printer is working on a job. I commented this out.

//                      ui.Add(StatusPanel(ui, DefaultPanel(ui)))

Attached is the deb file with this tweak. With this, the only time OctoPrint-TFT hangs is if you go into the status panel manually and leave it there. You just have to remember to back out of it to the main panel if you don't want it to hang. octoprint-tft_0.0_git04dd1f0-1_armhf.zip

Edit: I checked that after this change, if you manually enter the Status panel and leave it there while a print is going on, it will get stuck on that panel like always.

[EissaAl]

not only in the status panel, if you left it without connecting the printer it will freeze after some time. https://i.imgur.com/zjM0VJl.jpg

[The5py]

@ppamidimarri For now with the lack of fix for this bug or any solution I think your workaround is good and I am going to use it. Thought about another little nice to have to add (Maybe even to use it and not comment out automatic opening the status panel), on the event of status panel opening I suggest to invoke a timer which will get out of the status panel into the main screen automatically after a short period of time by that to help the user which forgot to get out of this screen not to get stuck in the middle of printing which is annoying...

BTW anyone knows about a command to restart the octoprint-tft process in case it is stucked already during print without the need to reboot the entire raspberry pie

[mrcg]

@ppamidimarri Will try your workaround but anyhow we should try to find the root cause from status.go code. Question: a) The timer increase did not solve the issue? b) Do you know if the timer change (10s) was really taking effekt to allow more time for receiving the feedback?

Another question: Is it possible to explain shortly how to create own deb package after modification of the source files? Or is this to complex to explain in few steps?

My idea would be to almost clear the status.go and then add successively one more function in order to find the guilty code.

How can we find out if missing answer from the server could cause the issues? Because - as already sayed above - in my wireshark traces on localhost i can see several times that there is not response from the server on the "GET /api/job" request.

[ppamidimarri]

@EissaAl, yes the Octoprint-TFT UI will stay on the splash screen unless your OctoPi is connected to your printer. See this other issue: #15. I don't understand the code or the go language enough to fix that.

[ppamidimarri]

@The5py, this is a good idea. I will see if I know enough to get this change done.

One way I know to get Octoprint-TFT to restart without rebooting the Pi is to install the deb package again with sudo dpkg -i. It works most of the time, but I once had the Pi stuck on a completely blank screen instead of the UI.

[ppamidimarri]

@mrcg, correct, the timer change doesn't solve the problem.

I know the timer change was taking effect. I confirmed that by adding in status go:

      Logger.Debug(fmt.Sprintf("Received: ", text))

just before:

      m.left.Label.SetLabel(text)

Once I had this running, I checked what the program was logging, using the command journalctl -t xinit and I noticed that it was logging a response once every 10 seconds. If I change the timer to 5 seconds, it logs a response every 5 seconds. So the change of timer is definitely happening, but it is not helping prevent the status panel getting stuck.

Here is a quick summary of how you can build your own deb packages with changes you make to the code.

1. Create a directory on your Pi where you will make the code changes. There, clone the respository with git clone github.com/mcuadros/OctoPrint-TFT.
2. Follow the steps listed by the original developer in the Readme file in the section "install from source". Use the command curl -fsSL get.docker.com -o get-docker.sh to get the Docker installation script. Then run the script with sh get-docker.sh. This step can take a long time. If you get errors, repeat.
3. Now you can build the deb package with your code changes. Go to the directory where you cloned OctoPrint-TFT and in that directory, use the command make build. This will take a while. Once it is done, the deb package will be in the subdirectory build/stretch. There will be two deb files there, use the one with the shorter name, without "dbgsym" in the name.

Please note that I am really new to Debian, Raspbian, OctoPrint, Docker, Go and GitHub. The last time I did programming was 15 years ago. I learned all these steps by googling each piece. So I may not be able to help if you run into issues with the above. I highly suggest making a backup of your Pi before you start this. Also, read the output of your commands carefully, and if there are errors in one step, don't move to the next before you take care of them. Good luck!

Edit: One more thing... don't make these changes to your Pi while you are printing from OctoPi. You can do step 3 just fine while the printer is running after every set of code changes, but if you attempt step 2 while the printer is running, your print job may be adversely affected.

[EissaAl]

@ppamidimarri I mean even if u connect the printer it will stay in the splash screen because I didn't connect the printer for some time. same as the status panel problem.

[ppamidimarri]

@EissaAl Got it, sounds like there is a bigger problem somewhere that makes the application freeze when the OctoPrint server doesn't respond for a while. I am totally out of my depth now, I hope the original developer has some time to help us out!

[mrcg]

@ppamidimarri Based on your description i was able to compile the deb package on my own. Many thanks for this !!!!

I am trying to take out some code in order to hopefully find the guilty part. Yesterday i took out the whole "updateJob" function from status.go where i have expected the root cause for the problem .... but unfortunetely it's not the case. The issue still happened which means it's caused by some other code. Today i will take out some more code but due to the fact it's very time consuming the activitiy will be limited.

[mrcg]

Some GOOD NEWS !!!

After disabling the "updateTemperature" function from status.go (remove line 145) the issue did not reoccure again after about 3-4h testing. It looks very promissing that the issue is somehow caused by this code:

func (m *statusPanel) updateTemperature() {
	s, err := (&octoprint.StateRequest{Exclude: []string{"sd"}}).Do(m.UI.Printer)
	if err != nil {
		Logger.Error(err)
		return
	}

	m.doUpdateState(&s.State)

	m.tool1.Hide()
	for tool, s := range s.Temperature.Current {
		text := fmt.Sprintf("%s: %.0f°C / %.0f°C", strings.Title(tool), s.Actual, s.Target)
		switch tool {
		case "bed":
			m.bed.Label.SetLabel(text)
		case "tool0":
			m.tool0.Label.SetLabel(text)
		case "tool1":
			m.tool1.Label.SetLabel(text)
			m.tool1.Show()
		}
	}
}

I am thinking now about this two potential workaround solutions:

1. Remove temperatur information from status screen completely because i have this information already locally available from 3d printer's LCD display.
2. Remove the tool1 handling as both of my 3d printers have only tool0.
3. Developer to fix the real issue in the code. ;-)

[EissaAl]

@mrcg how I can modify the code? sudo nano then what is the location of the file

[ppamidimarri]

@mrcg Excellent progress! Removing updateTemperature is a no-brainer for me. I never look at that when I want to know how hot my printer is, I look at the printer's LCD screen.

I will look into this more tonight and try to test it with several print jobs.

[The5py]

@mrcg - It works great! I remaked as well- updateTemperature on line 145 compiled it and it is up and running for some short prints nothing getting stuck for the moment

Great workaround for now! I think checking it with only removing the second hotend (tool1 and leave tool0) is a good path to try investigate.

Now looking for a solution or workaround for #18 @mrcg & @ppamidimarri does the temperature profiles works good for you?