Watch the print. If the printer is periodically pausing/stalling in places then this will result in what you're seeing.
I'm using a Raspberry Pi 3 B. It was previously used on a MP Select Mini without issue. Gcode is attached.MMD_3DBenchy.gcode (3.2 MB)
Printing with Repetier (and the same USB cable plus an extension) from my PC seems to work fine.
Speed doesn't seem to be a factor. I've tried everywhere from 30 to 100mm. I'm printing one at 20mm now to check.
I do not see any communication errors in the log. There may be some tiny pauses during the print (difficult to tell). It would certainly explain the blobs if this is the case. I considered interference or noise but there are no communications errors that I can see in the terminal (I could be wrong).
Is there a preferred baud rate? It detects and connects at 112500.
Keep the suggestions coming!
That's interesting, but you didn't say whether or not it either has ferrite cores or an internal metallic shield. Ferrite cores are pretty obvious. They're either there or they're not. Since you didn't just say that, I'll assume that it doesn't have any. As for internal metallic shielding, you can reasonably tell if you attempt to bend it, it will oppose you since the aluminum foil or the braided metal sheath is stiffer.
That seems to have fixed the problem! I didn't think that was it since it worked with the PC and I had replaced the cable previously with another MP cable to no effect. I had a better cable on hand and so far so good!
Thanks!!
Well, it worked for less than a day. I have no idea what changed, but it's back to blobby prints even with the new cable. I'm going to send it back and get a different one to see if it makes any difference.
Check your power:
Great suggestion! I had considered a power issue, even going so far as to try another 2.5A Pi power supply (no help).
The problem is intermittent and it is working correctly this morning, but I'll do more testing this evening. The Throttled flag is currently 0x0. I'm not sure when I last rebooted though.
Meanwhile, I've tried:
Another MP Mini Delta
A different PI 3 B
Different USB cables
Different speeds
Fresh OctoPi install
Disconnecting Delta base cooling fan
I have a Pi 3 B+ on order, but I don't have high hopes for that solution.
It could be the power in your home. Is all this plugged into a UPS?
It's not. I'll give it a try.
I'm usually "the local electrician" at most places. You'd be surprised at how poor the building's internal wiring is. Turn on the air conditioner, the voltage goes down by ten volts. The refrigerator's condenser pump kicks on, the voltage goes down by five volts. Turn on the microwave oven, the voltage goes down by eight volts.
So this is literally the same g-code?
Yes. Exactly the same. One printed from Octoprint, one straight from the SD card.
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:
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.
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?
