Hi folks,
I think I've read most of the threads with the similar issues and I've tried the recommendations proposed without luck 
I got a CR10s PRO, and soon I added a Bondtech DDX kit and upgraded the board to an SKR 1.4T with TMC2209 drivers. Everything went OK, printed perfectly callibrated XYZ cubes, but as as soon as I printed models with curves I saw blobs. Lots of them. Reducing the temperature did not solve anything, but printing from the SD did... so after checking the logs and seeing some timeouts while printing (suspiciously a similar number to the blobs in the surface), the issue should be on the communications between Octoprint and the firmware.
What is the problem?
Blobs because the nozzle does some imperceptible stops at some points when printing from Octoprint
In the image you can see part of the body of a benchy (scaled 200% and then cutting to have a 3mm tall part), 0.2mm layer height, 3 perimeters, 0 infill. Using PrusaSlicer.
Checking the resulting GCODE after using the ArcWelder plugin, there isn't seem to be any weird movements around those points
What did you already try to solve it?
Have you tried running in safe mode? Did running in safe mode solve the problem?
Yes. No effect at all.
Complete Logs
serial(2).log (210.0 KB) octoprint(6).log (23.3 KB)
Additional information about your setup
- OctoPrint 1.5.2
- Python 2.7.16
- OctoPi 0.17.0
- PrusaSlicer 2.3.0.-rc2
- Raspberry Pi 4 Model B Rev 1.2
I don't know what else I should try from here.
Thanks!
Just to clarify, is the same arc-welded gcode being sent from the SD card and through OctoPrint?
Yes, it is.
Couldn’t successfully compile the ArcWelder lib for OSX, so the Gcode it’s processed in Octoprint and either printed through it or downloaded and copied to an SD card.
Also, couldn’t upload more images being a new user, but I’ve checked the generated code viewing it in Simplify3D and there isn’t any strange movement or delay in the parts affected.
I've continue researching on this:
Increasing the RX_BUFFER_SIZE from 128 to 1024 made a difference and I got like half of blobs, but surprisingly none in the first layers.
Then I increased it even more to 2048 and the TX_BUFFER_SIZE from 128 to 256. The results were worst at sight, but in both cases I only got 10 timeouts during printing, so I think the in that case I got the timeouts near or at the most external perimeter, but there were also blobs on the first layers.
Testing again in case I was producing some regression due to these modifications, printing from the SD directly caused no issues.
I'm attaching the serial of the TX256-RX2048 print if that helps: serial.log-TX_256-RX_2048.log (199.6 KB)
From this point on I don't know where to continue researching on this issue 
As far as I knew, the buffer size did not contribute to serial timeouts - it's a different issue.
Buffer underrun is when the serial communication cannot keep up with the rate of commands, meaning that there is no command for the printer to process in it's queue.
I don't think that's your issue here - and your buffer sizes are ridiculously high from what I have seen is the default. It's a well known thing with serial interfaces that you can have stuttering or slowdowns, but still I don't quite think that's the case here.
Now I might be wrong, that is not uncommon. But timeouts are usually a firmware side issue, where it is either taking too long to process things, or bugs where it forgets to respond to commands etc. Usually I have two suggestions for fixing this. One is a different cable, the second is to upgrade the firmware. You mention you've bought a new cable, so for now we can assume that it is good. If you happen to have other cables, try them too, but not a high priority.
Second thing is try upgrading the firmware. You are using Marlin 2.0.7.2 which is the newest release, but it is not without it's issues - just have to take a look at the number of issues and PRs to fix things there to find out. Try the bugfix branch, to see if there is an improvement.
That was a lot of extra words for one suggestion, but it felt like it needed it. Hopefully something useful is hidden there.
1 Like
@Charlie_Powell
I've tried with at least 3 cables, and the one installed now has been manufactured with shielding and ferrite cores at both ends. None made a difference. Also I haven't seen any garbled characters in my logs, so I have no reasons to consider researching more on that front.
Following your suggestion I tried an upgrade with the latest -bugfix. No changes
I'm starting to think that this is not at all related to Octoprint, but on how Marlin does ingest data while printing that generates a different behavior than when printing from an SD.
Or perhaps, that I have activated a non-critical feature in Marlin while editing the config files and that feature is causing this... I'll continue digging into this. Thanks!
