Hello,
i'm expieriencing bad (bubbles due halted print head caused by "hanging" pi) prints after updates and as far as i can tell acutally it might be a python3-performance-issue on a pi 3.
After approx. 6 months i reactivated my before wonderful working combo Pi3+Ender3 Pro 4.2.7 Direct Drive.
After installing the offered updates (i think i also updated from python2 to python3) the octopi halts every few seconds in print so i get lots of bubbles in my prints. i tried:
another USB-Cable
disconnecting DHT 22 and 2 relais (Light / Case Fan)
another Power Supply (incl. cable) - althrough i didnt get an undervoltage warning
new SD Card, new OctoPi with restored backup
printing without SD-Card in Printer
printing from SD-card in printer without octoprint (works ...)
Stressberry (all fine, idle 52°C, max 82°)
Raspberry Pi 4 8GB (same SD, THAT worked, so i came up with the performace issue)
temperatures while printing are approx. 60-65°C
load idle around 1
load when printing is around 2
so i disabled all 3rd-party plugins - and the quality is much better, lot less halts in print.
so my question is - is the rasberry pi 3 still recommended for octoprint?
i there something i dont see? something i can check? the pi feels generally a lot slower than before.
There is a major issue with the enclosure plugin.
When it is enabled there is a huge amount of this error messages:
2022-07-26 11:14:09,028 - octoprint.plugins.enclosure - INFO - Failed to execute python scripts, try disabling use SUDO on advanced section of the plugin.
2022-07-26 11:14:09,029 - octoprint.plugins.enclosure - WARNING - An exception of type ValueError occurred on log_error. Arguments:
('not enough values to unpack (expected 2, got 1)',)
Traceback (most recent call last):
File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_enclosure/__init__.py", line 1113, in read_dht_temp
temp, hum = stdout.decode("utf-8").split("|")
ValueError: not enough values to unpack (expected 2, got 1)
You may check the settings.
Did you always test with the same model or some others too?
It may work, but keep the MCU as cool as possible.
There is also this in the log:
2022-07-25 21:35:52,259 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 1692, current line = 1694
| Last lines in terminal:
| Recv: ok
| Send: N1685 G1 X109.835 Y145.999 E25.40631*96
| Recv: ok
| Send: N1686 G1 X107.913 Y145.999 E25.45435*107
| Recv: ok
| Send: N1687 G1 F1200 X105.991 Y145.999 E25.5023*48
| Recv: ok
| Send: N1688 G1 X104.069 Y145.999 E25.55024*103
| Recv: ok
| Send: N1689 G1 X102.147 Y145.999 E25.59819*103
| Recv: ok
| Send: N1690 G1 X100.225 Y145.999 E25.64613*96
| Recv: ok
| Send: N1691 G1 X98.303 Y145.999 E25.69407*94
| Recv: ok
| Send: N1692 G1 F1333.3 X98.104 Y145.807 E25.70028*38
| Recv: ok
| Send: N1693 G1 F1500 X95.763 Y105.744 E26.50115*52
| Recv: Error:checksum mismatch, Last Line: 1691
| Recv: Resend: 1692
That can be a hint for a disturbed USB connection.
Keep the USB cable away from the steppers and their cables and also away from the LCD an it's connection to the board.
An easy way to do this is safe mode. You don't have to disable/enable all 3rd party plugins by hand.
In many tests that we have done (and general feeling/reporting from other people) Python 3 actually runs faster than Python 2 does in many tasks. The code is not completely optimized for it (since we have had 2 years of having to run on both 2 & 3) but 1.8.x should (on paper) be slightly better than the versions that maintained compatibility.
A test in safe mode would definitely be recommended. A key cause of pauses in the prints will be any resends you have - there is a resend counter in the UI to inform you if the connection quality is bad, as it definitely leads to worse prints.
Yeah, i saw that in the log - and this is because i disconnected the DHT22-Sensor during my tests. The error is gone after disabling the Enclosure Plugin - but the prints stay rubbish.
no, i have only 1 pi3 and 1 pi4, i dont think a pi1 will make sense
yeah, i've already tested another usb cable to connect the printer and another cable for power supply and another power supply. the pi is now approx. 1m away from the printer (platine only, no case, better temps (50° while printing), outside enclosure) and the cable leads straight away from the printer.
1 retransmission in 20 minutes / 1MB seems to be ok ... when the printer stops every ~5 seconds ...
i will test in safe mode - but like i've already mentioned the print is almost okay with 3rd plugins disabled - so i'm expecting a good print ...
i'm slowly believing that the pi has some sort of bigger problem. does anyone know how to find out if the pi hangs for some seconds?
some months ago a screw fell into the case of the pi - it may be powered on, i dont remeber ... but it may be screwed (haha) because of that ....
a yesterday printed filament clip has also errors. share your thoughts. i think the printer is capable of printing the model correct because with the pi4 and print-from-sd worked fine.
Curious if you have Cura open and connected to OctoPrint reading information back into it's interface with the octoprint connection plugin (monitor tab)?
I know you've tried other USB cables, but the type and quality of cable can be an issue. At one point several years ago, I had a list of known good USB cables. Unfortunately, I've lost track of that - and it might be outdated anyway: manufacturers change their materials and methods from time to time. However, I cable that worked before SHOULD work now, and long as it hasn't suffered some abuse or connectors got dirty. If you used the same cable with the Pi4 and it worked, that would eliminate this as a potential issue.
something along the same lines: are the USB sockets in good shape or are they getting dirty/loose-fitting?
Hello,
i tried a lot in the last days.
Because the resends of 0 i dont think that the USB cable is bad - and because i tried another cable. And it worked fine for more than a year before.
I also reformatted the "Test-SD-Card" with kodi and checked the pi's stability while watching fhd movies.
As all worked fine i took a second look at the "Test-SD-Card" i used all the time. The card i used was from my digital camera and was slow (~5MB/sec). so i tried a brand new fast sd card, installed octopi, restored a backup, disabled all 3rd-party plugins - and got fine prints. After enabling the 3rd-party-plugins i got slighly bad prints - and disabled the faulty enclosure plugin - and got good prints. After installing the missing library for dht22-sensor even with enabled enclosure plugin the prints are fine again. I also used some time for recrimping the connections for the enclosure relais.
So i assume that the old SD-Card was gone bad and the Test-SD-Card was not fast or good enough for octopi.
This is my first post in this forum and i am really impressed how good this community is! Thanks a lot!
