What is the problem?
Not sure. This has happened twice with a print of the same model, but different gcode. The first failure happened with a print (DeadpoolChibi_Head.gcode) that was ~3hours in the second time this happened when a print ( (DeadpoolChibi_Head_Fine.gcode) was ~6hours in. Both times this was near completion of the print (about 80%) and seemed to happen the instant when I opened octoprint from the browser on my phone via remote network access (i.e. internet instead of local network). I'm 90% sure it happened exactly when I accessed from my phone via remote network / internet.
What did you already try to solve it?
Nothing yet. Looking for ideas. Seeing a lot of "wrong checksum" messages during print.
I've printed this model with success multiple times. I don't think it's the gcode because it's happened with 2 different gcode files (the same model at different layer heights / settings).
Additional information about your setup
OctoPrint 1.3.9
OctoPi 0.15.1 (RPi 3 B+ with 3Amp PSU, Printer does have relay switch powered by the printer's PSU and controlled by the Pi)
Monoprice Maker Select V2 Connected at 115200
FIRMWARE_NAME:Repetier_0.91 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 REPETIER_PROTOCOL:2
(yes I know I need to update)
Log during failure: octoprint-2018-09-09.log (148.5 KB) -- Failure happened after line 3788 in hte log and there's a bunch of NUL characters in the log.
Just shooting in the dark, I guess I'll finally update my firmware (not looking forward to that). But again I really think the issue is with connecting via the internet somehow. Though I can't reproduce unless the printer's been running for a while which is not fun to try...
Thanks. I logged the get_throttled values as well as temp, core, and ram voltages.
Throttle reports 0x50005 ten times over the course of ~3 hours while printing and checking via localhost and internet to my server a variety of times throughout the print. The print, however, did no fail or server crash during any of this.
So... I've got a 5v 3Amp supply going to the Pi, so I'm not sure how it's going under voltage. It's not like it's powering the printer. Just a Pi camera which doesn't take much.The core CPU voltage doesn't go over 1.39 so I should be safe there and never below 1.2v. Temp never goes above 65C.
Wish i had a load tester, I'm getting tired of the Pi reporting under voltage with all these little PSUs. Similar was happening to my media server, but that was under heavy load on a 2amp supply. Now that one's been moved up to a 3amp supply it doesn't complain (that I ever notice).
It's definitely going under-voltage. If it says 0x50005 you are currently under-voltage, if it says 0x50000 it means you have been in the past (since last reboot).
CPU voltage will remain stable- the 0x50005 is from before the CPU voltage regulator. (I spent time trying to figure that out a while ago).
I'm still trying to deal with some voltage supply issues too. I need to swap to a shorter cord; I think part of the problem is voltage sag. The board I'm designing has a INA219, it'll be interesting to compare what it says versus what the Pi tells me.
Yeah, I'm going to switch out the supply's cable first and check to see if it's just a crappy cable. Those USB cables go bad fast and aren't really meant to carry much current (though 2A shouldn't be an issue).
I don't think the problem is carrying that much current, the problem is with such tiny wire diameter, they have resistance which causes voltage drop, and I think the Pi is especially sensitive to any voltage drop. Your cell phone doesn't mind charging at 4.5v but a Pi will complain at 4.9v- or so goes my untested theory.
Well it's been a few prints since I switched out my USB cable. I tried a couple different ones with the switches in them. They both kept going under voltage. So I changed to a nicer, braided cable and no problems. When I said amps I'm assuming the effect is due to a bad PSU which drops in voltage the higher the current goes. The PSU and cable are fully capable of delivering enough voltage when not under much load, but yes there could also be a significant resistance change in the small wires as they heat up and are required to deliver more amps. Now it really seems like the switches are the culprit, but without a variable load tester I'll never be able to confirm that.
At any rate, I'm going to post up some code here which some may find useful. This bash script writes to a log file (CSV) whenever there's throttling due to voltage drops.
log_temp_volt
.
#!/bin/bash
fName='temp_volt_'$(date +"%F_%T")'.log'
echo "Start at "$(date +"%F_%T") > $fName
echo "throttled,CPU Temp,Core V,SDRAM_C V,SDRAM_I V, SDRAM_P V" >> $fName
while true
do
throttled=$(vcgencmd get_throttled)
throttled=${throttled:10}
if [ $throttled = "0x50005" ]
then
d=$(date +"%T")
t=$(vcgencmd measure_temp)
t=${t:5}
t=${t::-2}
#echo $d,$t, >> $fName
c=0
for id in core sdram_c sdram_i sdram_p
do
v[$c]=$(vcgencmd measure_volts $id)
v[$c]=${v:5}
v[$c]=${v::-1}
c=$(expr $c + 1)
#echo $v >> $fName
done
vs=$(printf ",%s" "${v[@]}")
vs=${vs:1}
echo $d,$t,$vs >> $fName
fi
sleep 10
done
I think my next community contribution will be a plugin for Octoprint that shows a little lightning bolt indicator when under voltage like the raspbian desktop.
Cheers and thanks for the help.
If you want to do that (and log the voltage fail), cool. I was going to but I can contribute a pure-python call to get the throttling, which doesn't exist (yet). There are really only two things that need reporting- currently under-voltage and 'have been under voltage'.
