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.
gcode is too large to upload unfortunately, it's about 9M. I tried loading it into ncviewer and that just garbled - is there a utility that will render g-code and show layers at the same time. Cura will replay layers but not show the g-code and I don't think Repetier does either. Then I can zero in on where it does the nubs
sample.gcode (3.1 MB)
this is the first 100,000 lines from the file which is about the most I can upload, but it should well and truly have gotten to the nubs by then I guess.
I just search for layer changes and cut out individual layers manually. It is a pain, but not too bad. And, no, there is no built in support. I will take a look at the gcode when I have a few spare moments, tyanks for posting!
You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead. Hey uh, you want a drink?
2 Likes
take the blue pill!!! the red pill leads to shitty food.
and a blinding headache!
Hello,
So I have a Ri 4b and I am planning on installing it via the GPIO pins (like on the Prusa guide where they use a Zero) and a cable. Has anyone testing is transfer latency/speed is better using GPIO vs USB?
In both cases (GPIO and USB), the communication protocol is serial (i.e. one TX/RX pair and bits are sent one at a time) so there will be minimal differences in the latency/speed.
1 Like
Agreed that the protocol is serial in both cases, but you will get rid of the USB to Serial step, which might give some performance enhancement. I have been experimenting to connect my RBP4 via Serial instead of USB but not to a stage that I actually tested it with printing. And, to be totally honest, my motivation wasn't the speed but the fact that I wanted to get rid of the USB cable on the outside of my electronics housing. in this document I described the proof of concept. (Never mind the red wire, it's not connected!). You would have to use shielded cable in a working setup between the pi and the Creality mainboard to prevent noise. When time allows it I will test this out in a working environment and perform some testing to see if there is any difference in print quality.
Please let us know if you see any differences.