Hi there,
I have a serious problem with blobs due to the printer halting for a few seconds every now and then. I know that this is an issue that already affects many people and is not (exclusively) caused by octoprint itself. However there are a few things I don't understand - maybe someone familiar with these issues could help me clear things up.
First, here's my setup:
- Raspberry 3 B & Wanhao Duplicator i3 v2.1
- Raspberry 3B+ (octoprint freshly installed with no plugins) & Wanhao Duplicator D9 MK2
- Both are running the latest stable release and are connected with 115200 baud
- I prefer quality over speed, so I usually print at around 30mm/s and 100µm
I never had these kind of issues on Setup #1 although the (slightly slower) RPI also acts as a webcam server (RPi_cam_control - I don't use octoprint webcam support) and runs a CPU-demanding sensor-readout-and-plotting program.
On setup #2 though, there's lots of blobs on my prints with the printer stalling up to 5 sec. CPU-wise there's nothing to complain; it's mostly in the one-digit % area with no notable deviations when the printer pauses.
This even happens when I print the same .stl files with almost the same gcode. However it doesn't seem to happen on very simple files < ~2MB. Most of the time I'm printing gcodes of ~ 10-50MB in size.
So I guess the serial interface somehow is the bottleneck. This is really strange because the D9 is the more modern printer. On the other hand it's CPU seems slower (just judging by their clock speed). The old printer features an ATMEGA1284 (20MHz) while the newer one is driven by the ATMEGA2560 (16MHz).
Workaround for me is to print everything from SD.
Unfortunately I control the printer mostly remote. So uploading a file to SD card takes ~ 1hr/10MB; so I have to have the uploading PC connected to octoprint for 5 hours in case of a 50MB file - when connection drops, I have to start over again.
tl;dr:
Is there a way to first upload the file to the octoprint server and afterwards copy it from there to the printers SD card? Uploading to the server just takes a few seconds; so this would make the process much less painful.
Any other suggestions concerning my actual problem? Printing everything from SD can't be a long-term solution. Do I have to upgrade to a more modern mainboard? If yes - which one is recommended and works flawless with octoprint?
This probably won't be much help, but using S3D 4.01 to slice and a 3B+ pi, hardwired to the network, USB to printer and a completely different printer and manufacture, I have had no such issues and have been using this setup for about 8 months.
First if you have not done so, try a different usb cable. Next make sure you have the proper power supply for the B+. If you can get hold of another PI B+, do a clean install and see if the problems follow.. If so I would be focused on the printer not the PI.
A quick look at my Octoprint and it has the connection speed set to Auto.. are you using Auto or locked in at 115200? If locked try auto.
Good luck!
1 Like
Thanks for your advice!
s3d produces the smallest gcode files AFAIK, so this should definitely help. However I love cura and OSS and instead of investing 150€ into s3d I'd rather spend the same amount of money into a duet2 mainboard which should be capable of processing any gcode.
I've already tried changing the PSU for the RPI (got plenty lying around) - a new USB cable (short, shielded + with ferrite core) is already ordered and on it's way. The D9's RPI already runs on a clean install (most recent raspbian + octoprint; nothing else) I set up this weekend in hope to mitigate the speed-issue. Baudrate is set manually since yesterday; unfortunately 115200 is the max. speed for this printer. Setting it to manual didn't change anything.
And I also think it's the printer who's to blame. But maybe there are some tricks to mitigate the problem on octoprint's side.
Can you confirm you are on 1.3.10 on both Pis and neither of them are flagging for undervoltage/overheating?
Yes I can confirm both running on 1.3.10.
I've never seen the undervoltage/overheating symbols on the webserver (just had to google for them). Would there be some message in the log? If yes - what to search for? "tempe" and "voltage" at least doesn't give a result.
Generally I've observed them manually for CPU temp lately. The Pi #1 which is naked runs at about 65°C max while the Pi#2 which features a big heatsink usually is below 50°C.
Would enabling the serial.log help?
Those temps are fine. If you bought the power supply with the Pi from a reputable suppler you are probably ok.. I think where the power supply issues come in is when someone tries to use an old PS from a much older PI that does not put out sufficient current to power the new B+.
You'd think that, but a strong minority of Pis that report to the Octoprint mothership show problems with voltage.
@unwohlpol , run vcgencmd get_throttled and post the result.
1 Like
It says
throttled=0x0
on both Pi's. Looks good to me.
Anyway, I bought the PSU with the Pi 3B+ at RS components and it seems to be the official PSU. Except from an added ferrite core I've left the PSU in it's original state. At first I was suspecting the stuttering to come from EMI and added ferrites on the PSU and a grounded metal case to the RPI; as soon as I receive the better USB-cable I'm quite sure I've done almost everything to minimize EMI-effects.
Just one crazy idea:
In case the pause/stuttering is an effect of a buffer underrun on the serial port or something like that - wouldn't it be possible to add a feature/plugin to octoprint to detect if the buffer is running low and adapting the print speed to that event? This would still be much better than the nozzle stopping for 5sec. and melting my printed object.
that's good.
I'm not sure if you can truly detect an underrun, but certainly we've seen problems when there's a high "gcode to move ratio", e.g., a curve with too many splices, which causes this type of situation.
None of that would take literally seconds to resolve, though.
Update:
Changing the USB cable didn't help either. For now, printing from USB is the solution.
But I made another observation:
The longer a print is taking, the more often it suffers from interruptions. Plus: there are temp-drops in the temp-plot which also occur more often the longer the print takes.
They are very short but visible in the plot - for nozzle AND bed! Sometimes it's even the target temp thats dropping!! And It can't be measured with my parallel temp-measuring setup!!! This happens in USB and SD mode. And there are still no interruptions in the print process when printing from SD; just these "ghost-tempt-drops" as I'd call it.
I think I have to check my mainboard for overheating - it's all set up in an enclosure which isn't the best place to have it (although with a stronger fan... but who knows). Strange though - even if it's the printers fault I wouldn't expect octoprint to drop the target temp; and come back again immediately.
BTW: Here's a short log starting from uploading the file to SD until mid-print (after some of said temp-drops): https://pastebin.com/wBJFeRxL
Some of the messages seem like they don't belong there; can someone check that?
Last Update:
I found the cause and a solution: The enclosure was the culprit. It seems the CPU was shutting down due to overtemperature, causing print-pauses and weird readings in the octoprint graph.
Still strange that it didn't pause when printing from SD while there were the wrong readings in the graph too.
However, I've installed a stronger fan and equipped the PCB + CPU with some additional heatsinks. This seems to be enough; I haven't noticed any wrong temp-values or intermissions since.
1 Like
Hi, I'm having the exact same issue now and tried everything you have tried.
Was it the cpu on the pie causing and issue or the cooling of the main board let me know so I can keep either cooler and test
I have had the exact same problem with my Wanhao Duplicator D9-400. The same Pi3B+ with Octoprint that has been running for years without any hitches on my Anet simply gets these "lost temperature spikes" and then printing becomes more or less useless. Also happens only after a few minutes.
Will test with a Pi 4B+ and most recent Octoprint and revert...
There are two places where over-temperature could affect your printing. One is the RPi board and the other is the printer controller board (RAMBO in many cases). The printer as delivered will usually have some sort of cooling for its controller board deemed adequate by the manufacturer. If you add an enclosure, make sure that whatever cooling vents, fans, etc. on the printer are not enclosed.
The RPi is designed such that passive cooling should be enough if the air surrounding the RPi is room temperature. Heat sinks can be added for better passive cooling if the CPU load varies, and fans can be added for active cooling. Again, if the RPi is in an enclosure, then the temperature of the air surrounding the RPi could have a negative effect on cooling.
Here's a bash shell script you can use to measure the CPU and GPU temperature of the RPi:
#!/bin/bash
clear
m=5
l=60
if [ -n "$1" ]; then
m=$1
fi
if [ -n "$2" ]; then
l=$2
fi
echo "m= $m"
echo "l= $l"
f=1
while [ $f -le $m ]
do
cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 % $cpuTemp1))
echo CPU temp"="$cpuTemp1"."$cpuTempM"'C"
echo GPU $(/opt/vc/bin/vcgencmd measure_temp)
echo
sleep $l
f=$((f+1))
done
My D9-400 now works perfectly with a fresh (latest) Octopi installed on a Pi4B+ 1GB. I could NEVER get it to work stable on a Pi3B+ when the same Pi3 works perfectly on numerous other printers.
I personally doubt this a "over temperature" issue of iether the Pi or printer and would rather consider it to be an USB timing issue or similar.
My advice: Get a Pi4 and install latest Octopi.