Octoprint and timelapse issue - crash

Get Help
1

I finally configured Octoprint to work with TevoTornado 3D printer (Marlin) and Raspberry PI3 via Simplify3D.

If I print without "timelapse" option, everything is working without problems, but if I enable this option Octoprint crash after printed job is done (in meantime while printing, I can access to camera picture without any problems).

After "crash" (I cannot access to http://octopi.local) is not responsible and I need to manually reset raspberry PI3 (disconnect from power).

  • I use latest version of Octoprint Version 1.3.9

  • Rasspberry Pi3 with 32 GB memory card / power supply USB (mobile adapter)

  • Camera Logitech C920

  • Timelapse settings: timed, snapshot interval 10 sec; fram rate: 25 fps: post role: 0

  • addon/plugin: TouchUI : 0.3.11

  • all rest settings: default settings

  • Log files uploaded:

serial.log (148 Bytes)

2

and additional logoctoprint.log (50.5 KB)

3

Try to run in Safe Mode and repeat with a tiny part (five minutes). Otherwise, disable all added plugins and do the same.

  • Verify that your power supply provides 5V @ 2.5A (if the webcam has a bright LED, it could be drawing too much power)
4

As far as I tested now, it's working but it crash immediately when I cancel printing (during print) - it looks this is the problem.

So while printing for example I discover an error on print and I press "cancel", after that octoprint crash and I need to power restart...

Any solution for that ?

5

Just so that we're on the same page:

[ ] it won't respond to an ssh or putty attempt
[ ] it does respond to ssh, for example, but ps -ax|grep octoprint shows that the service is no longer running.
[ ] when I press Cancel, it hangs on the message Cancelling
[ ] it won't respond to a ping octopi.local
[ ] allowing the job to finish completely works correctly, producing a timelapse video and none of the issues described
[ ] after it "crashes", I can still access http://octopi.local:8080/ and this works
[ ] this isn't a Raspberry Pi 3B+ (emphasis on the plus)
[ ] my power adapter is 2.5A

6

[ x] it won't respond to an ssh or putty attempt
[x ] it does respond to ssh , for example, but ps -ax|grep octoprint shows that the service is no longer running.
[x ] when I press Cancel , it hangs on the message Cancelling
[x ] it won't respond to a ping octopi.local
[x ] allowing the job to finish completely works correctly, producing a timelapse video and none of the issues described
[ ] after it "crashes", I can still access http://octopi.local:8080/ and this works
[x ] this isn't a Raspberry Pi 3B+ (emphasis on the plus)
[ ] my power adapter is 2.5A -> 1A

7

If this is a Raspberry Pi 3B then it needs a full 2.5A of 5V power. It would be good to check for throttling to see if your Raspberry knows that it doesn't have enough power.

ssh into the Pi and then: vcgencmd get_throttled

A non-zero value lets you know that this isn't good. I've actually designed circuits which are like the power adapter we're talking about. The electronics is pretty involved and it takes a lot to provide a solid 5V to something like the Pi. But it's all about power (voltage times current). If you provide 5V * 1A that's 5 watts of power rather than the expected 5V * 2.5A = 12.5 watts which are expected. What usually happens then is that something has to give. The power adapter in your case can only do 5W so it then delivers less than 5V (perhaps as low as 3V).

Imagine that you're a transistor and it's your job to recognize the difference between zero and one (0V and perhaps 60% of 5V or 3V). That 3V then is an important threshold. So now, you've provided a cheap power adapter and it's not the full 5V but more like 3V to start. The transistor is in trouble because it wants a solid reference point to begin with and things get ugly. (Technically, the Raspi uses 3.3V logic, btw.)

First things first, get the right power adapter and then troubleshoot from there.

8

That'll give nonzero for other reasons. First, the decoder ring. Throw away the 0x, and use the following for the first and the last digit:

0x50000 # has been under-voltage in the past but not now
0x50005 # has been under-voltage in the past and is
        # under-voltage and throttled now

There are some other possibilities for that first and last digit besides 5 and 0, but the important thing is that if the number is odd (1,3,5,7) you are under-voltage. You can pay attention to the number to see how often you are undervoltage:

watch -n 1 "vcgencmd get_throttled"

You might also get throttled from temperature without being undervoltage, it needs to go above 80c though:

$ vcgencmd measure_temp
temp=48.3'C

I don't have the luxury of heat to stress my Pi now. I could put a W in the oven and run stress but .. nah.

I've really gotta get my adapter board done, I assumed my USB supply was burly enough. It's easier to keep 2.5a if I'm feeding 12v to my adapter!

1 Like