I just saw this video posted and it might fix some of the blobbing...
4 Likes
I stumbled of that parameter in Kisslicer days ago.
I set it to a high resolution there, because with the low resolution the output was quite minecraft style 
In the end, the used value depends on what you print.
so... Im a noob here. I got an octoprint last week, and I print gyroid infil at 60mm/s, Im noticing that it seems like its sort of varying its speed, maybe even stuttering slightly, not running smoothly.
probably should just test if its better printing from SD, but I guess I am seeing the effects of this issue?
And a better USB cable or anything else will not fix it and I should just print from SD card? (which prevent Octolapse from working)
Is that the current state of things?
Sorry if this has been covered, its a long thread with a lot of technical stuff.
2 Likes
It has finally arrived / i think i will re-solder the power terminals because they are not straight.
But its there: DHL 5-6 days to Germany.
PostNL: mi mi mi we sent it back!
Reason?
No reason just because we can. :-/
You going to top that on a 3B or 4B? I'm wondering about the ability to properly cool the 4B in this scenario.
I love that warning message in OP right at the beginning of this.
hehe yeah unsafe ^^
First i will use it on a half dead rpi3.
Later i will hopefully use a rockpi4 or a tinkerboard
Let me know how that works. I might buy an Ender 3 and take that route to play with it.
currently building marlin 2.0 pandapi test
It feels like it will compile forever ;D
Send: M115
Recv: FIRMWARE_NAME:Marlin 2.0.x (GitHub) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:0
Recv: Cap:Z_PROBE:0
Recv: Cap:LEVELING_DATA:0
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Send: M155 S2
Recv:
Recv: ok
Recv:
this is how it looks like when you build the firmware
It seems like nothing compiles cleanly these days.
1 Like
Just to throw my slab in the pond :
The one thing @fossel mentioned and nobody seem to acknowledge in their account of the phenomenon is the number of plugins they are running.
If the proof is in the pudding: Prusa ships with a RPi0 tutorial on how to setup with OctoPrint. The UI takes eons+2 eternities to load but I did see any jerking or blobs while doing this.
On my end, with low amounts of plugins (2 more than the vanilla install) I never encountered those problems. I might try and install a bunch of plugins see if I can recreate.
I just created this post regarding a plugin I created to hopefully deal with these stuttering issues. I do not have any stuttering/blobbing issues myself, so it's difficult for me to know if works. If anyone has repeatable stuttering/blobbing issues and is willing to help me test, please see that link. Thanks!
As the guy who started this thread ... whoa! Great replies.
Someone inquired about Plug Ins. I have the Bed Analyzer and OctoPrint Anywhere. That’s it.
I’ve gone back to printing via the SD card for a while now. I don’t print terribly fast, 40 mm/sec is my default and 50 mm/sec is about as fast as I push my luck. (Much of what I print are 40-50 hour long prints so I defer to quality over cranking it and hoping for the best)
My printers are mostly MKS 8-bit controller cards (1.4) ... Creality CR-10S, Folgertech FT-5/FT-6, and Tevo Tornado There’s also an Ultimaker 2+.
I’m still curious what work arounds are available for SD quality printer via USB.
Thanks, I’ll check that out!
The answer unfortunately is yes and these can be quite significant. I'm using an Ender 5 + with a RPi4 printing the Prusa RC3 Covid-19 headbands in bulk and there are significant artifacts with OctoPrint that don't occur with the SD card. This was disappointing as this isn't really a particularly demanding design, complexity-wise. However yes I think the problems occur with a lot of movement commands occurring in short timeframes, where the problem is likely to be the 8 bit controller in the printer struggling. Having said that, I note that using a Pi Zero W created really awful artifacts on the same print - this was without any webcam or plugins at all - so there still could be some kind of timing issue at the sending end as well.
I would be interested in taking a look at the gcode file you are having problems with. I have been examining lots of files generated from many slicers, and have noticed that some files have an extremely high number of points with very close separation (as low as 0.006MM I've seen, which is nuts).
I note that using a Pi Zero W created really awful artifacts on the same print
Using Pi Zero is highly discouraged. You can get by triggering SD prints this way, but not streaming.
Also, if you are having lots of artifacts using a Pi 4, perhaps you'd be interested in helping me test a plugin designed to hopefully reduce this issue? Be forewarned, I've discovered a lot of firmware issues that still need to be worked out with some printers. G2/G3 commands are rarely used, so there are still kinks with various firmware versions and configurations. The typical issue is, unfortunately, stuttering, even when printing from SD. There is an issue for this within github, and only a fraction of the users have encountered it.
In your research, have you reached out the the software developers of, say, Cura? Simplify3D or others?
I’m really curious if they could explain why so many points? Could they optimize the gcode for those using Octoprint or other programs that drop code via USB and have to compensate for the slower IO?
Just thinking out loud. 
PrusaSlicer and maybe cura (I am pretty sure) already have features to limit the max segment lengths, so I have not contacted them. I believe the G2/G3 method would actually work better since 99% of the time these points cluster around curves. See this comparison I did yesterday. Clearly there is more detail in that file than can be printed on any consumer machine. I believe many printers would have difficulty printing that file on SD (slower SD memory or board with a small buffer). I haven't notified the creator, but suggested that OP do that. I may well reach out, but most of my research is being used to develop the ArcWelder plugin, which combines these points into smooth arcs.
It's the Prusa RC3 Covid headband. I'm cranking these out for the health services in the UK on an Ender 3 and 5+. The 5+ is connected via Octoprint. Yes, I had terrible artifacts originally with a Pi Zero W so purchased a Pi 4 and fitted a CPU heatsink just to be sure it didn't thermally throttle.
You can clearly see the issue which occurs after each 'nub' on the headband. Bottom one is printed from SD. Print speed is 60mm/sec. Happens regardless of filament brand, incidentally. Sliced to 0.25mm layers with Cura 4.6, no weird options selected, retract 6mm at 25mm/sec, 3 walls, 30% infill and a 5mm brim at 250 degrees on PETG
Without seeing the gcode I can't comment on the nubs, but I would suspect a high concentration of points. SD will always have an advantage here, of course, since it doesn't have any serial processing overhead. However, I've been printing face shields as well, and have no artifacts at all. Since I've been testing my plugin, I've done comparisons with SD prints, and for the most part they look identical. There are many many documented reasons why this might not be the case for everyone, and it varies according to many things from the gcode file, the quality of the USB cable, the firmware version and configuration, the host hardware, even the PSU and heatsinks (as you mentioned). This is exactly why I have been trying to develop a general solution to the problem. There are many possible reasons for sutttering, but reducing the lines of gcode per second sent to any given printer should help in almost all cases.