UPS did not solve the problem.
I saw this issue after the last Octoprint update. Especially on circular parts of prints like your pictures. If you watch the head closely you will see it stutter like it is waiting for the next move command. Those micro stutters cause the blobs. I also had no problem with the same gcode on an SD card. I thought it was related to the plug-in Printtimegenius. But I am beginning to think this is just performance issues on Raspberry Pis from the last Octoprint update. I didn’t have the issue before that. I also get no log errors. So you aren’t the only one seeing this. Wish I had a solution.
More info: https://github.com/guysoft/OctoPi/issues/318#issuecomment-284762963
It might be time to print two small parts on the platform: cube versus cylinder. If the cube is beautiful and the cylinder is blobby then it seems to be following gcode density (lots of tiny movements). You'd want to orient one side of the cube with the X axis, btw.
What else could it be?
Ruled out:
- consistent power at the UPS
- adequate power at the DC adapter
- a good-quality serial cable which contains a ferrite core on it
- a Raspberry Pi which isn't overheating and therefore throttling
- a Raspberry Pi 3B rather than a 3B+
- ran this in safe mode so it's not an added plugin (but honestly, this would explain things)
If you turn off the motors, does the extruder assembly itself move freely throughout its range?
We didn't talk about the length of the serial cable. Shorter is better. Extensions add capacitance to the circuit. Extra capacitance acts as a low-frequency filter (the opposite of a ferrite core). Try to use one serial cable with the correct ends rather than one plus an extender.
I saw this. I tried 1.3.8 but had the same result. I'm convinced it's an Octoprint communications issue with certain printers (my Prusa MK2 works fine with Octoprint).
I have tried a few different cables of varying length (6" to a few feet) with the same result.
It is definitely on circular patterns. Even on the benchy the artifacts are at the front where there is more curvature. I've printed objects with straight sides with no issue.
Doesn't seem to be a mechanical issue. Everything moves freely, and the printer has been replaced.
Looks like there's a Github issue opened on it. I'll comment on it as soon as I have a little time to gather all the needed information.
2 Likes
Hmmm. I thought for sure this was working in the previous version. Even the github ticket states that. Maybe we were just on the edge of failure with our rigs.
I am seeing exactly the same symptoms with my MPMD and OctoPrint.
Only difference in my case is that I'm running OctoPrint on a Pi 2, but the difference between OctoPrint and SD card results are essentially identical:
Center is the first cat print right out of the box, right is printed today from OctoPrint (3 weeks after getting the printer), and left was printed today from the SC card. All are using the exact same gcode (auto00.g).
I'm running firmware v43 on the MPMD, and OctoPrint 1.3.9 running on OctoPi 0.15.1.
I wonder if the issue might be specific to firmware v43 on this version of OctoPrint?
I had the problem on v43 and v44, two different machines. There's an issue opened on GitHub which seems to be relevant. It doesn't appear to be limited to the MPMD.
Glad to see it isn't just me, though.
1 Like
Amen to that! I was going nuts trying to figure it out...thought maybe nozzle damage, or possibly moisture in my PLA. Knowing it's a shared issue means I can at least focus on other stuff I need to learn.
Can those of you experiencing this please add to the ticket linked up there with a filled out ticket template, verify that the issue persists in safe mode and if so add a serial.log and a gcode file with which to reproduce? Right now I still don't even have an inkling of an idea what might be up here (and can't seem to reproduce it myself), so the more information the better.
Not able to test in Safe Mode, as I need the Malayan connection fix plugin to be able to connect to the MPMD.
I will print a simple cylinder model and provide the gcode and serial.log files on the issue, though.
Update:
I've updated the github issue with my gcode and log files, as well as a couple images of the issue. Hope that helps with identifying the issue.
Happy to help however I can, given my limited experience.
Just chiming in that I’m seeing this same behavior on my octoprint Set-up on my makergear M2. Been chasing this issue for a while, so I’m somewhat relieved to know I’m not alone.
Octoprint 1.3.8 running on OctoPi 0.13.0
I am also seeing this on my MMD with Octopi 0.15.0 and Octoprint 1.3.8, so it doesn't seem limited to 1.3.9.
I'm running the MMD at home, with OctoPrint 1.3.9 as well, but instead of a Pi I'm using an old Asus eeePC 4G
. It seems to be running fine for me, no artifacts from slowdowns, so to me that would seem to suggest the issue is Pi related not OctoPrint.
1 Like
I was going to add, I have 2 friends with MMD's using Octoprint 1.3.8 one on a Pi3B+ and the other on a Pi3B, and they're both seeing the artifacting. The one with the Pi3B+ says you can hear the printing speed changes on the Pi printing that ghost vs. printing it from the SD card.
It would be interesting to know at what point this started. I don’t recall when I started noticing this, but my best guess is about 5 months ago. Is it possible to go back and test previous versions of octoprint? If so, how does one downgrade?
Btw, I don’t see this on my monoprice mini, only on my makergear M2. Both are running the same version of octoprint.
Thanks! I guess reading is fundamental! 
I think rather than downgrade, I’m going to try and set up a new instance on a new microSD. That way I don't lose my current state. I'll poke around and see if Guy Sheffer maintains an archive of old octopi images.
I did notice that my monoprice mini is connected at 250000 and the makergear is connected at 115000. Perhaps this lends credence to the idea that it is a serial bandwidth issue? Unfortunately, I can’t change the makergear baud rate without a recompile and update of the firmware.
The problem is only visible when printing many small curves. Flat surfaces don't have gcode data large enough to bottleneck the serial connection.Try printing this in vase mode, and the problem can easily be demonstrated. /https://www.thingiverse.com/thing:2645563
I've already modified TH3D firmware, and increased the baud rate of Ender 3 to 250k, BLOCK_BUFFER_SIZE to 64, BUFSIZE to 32, DEFAULT_MINSEGMENTTIME to 50000. Still unable to improve the print quality to the same level as SD card.
Update: A rebuild of Octoprint largely fixed the problem. However, the older Octoprint, with all the plugins removed, still couldn't produce the same quality as SD card. Having to rebuild Octoprint every now and then is not a real solution.