Poor quality Octopy print's compared to SDCard prints

What is the problem?

3D prints stored in raspberry pie and sent with octoprint to the printer, creates zits (blobs) due to the head lagging (more pronunced when the speed is increased).

What did you already try to solve it?

Printing the same file but from the sd card solve entirely this issue but I need to launch it directly on the printer.

Have you tried running in safe mode?

[EDIT] yes

Did running in safe mode solve the problem?

no

Systeminfo Bundle

octoprint-systeminfo-20230605160619.zip (289.0 KB)
[EDIT]
octoprint.log (2.8 MB)

Additional information about your setup

OctoPrint version : 1.9.0, OctoPi version : 0.18.0, running on Raspberry Pi 4 Model B Rev 1.5, Creality CR10S PRO V2, firmware : Tiny machine DW7.4.6, browser : chrome, operating system : windows 11

Hello,
I'm new to this forum, please take good care of me.
I have an issue that I think is comming from the buffer.
I tried the " Speed & Max Flow Tuning" from the : Teaching Tech 3D Printer Calibration web site to 3d print a speed tower. I had many blobs on it. But I figured it out that, when I launch the file from the sd card directly, my print is very good with no blobs.
Is it comming from my firmware tiny machine ? Because the buffer on the sd card is good whereas the usb receiver is badly setup ?

Do try safe mode to rule out issues with plugins etc. from interfering with the print. It might make a difference, but you won't know until you try it.

I'd think this is less likely the issue as I'm pretty sure @InsanityAutomation increases the buffer available on these machine, so unless there's just an extreme amount of short segments in the print I don't think the buffer would be the cause here.

As Charlie stated, make sure to test in safe mode, because I have also seen these kinds of blobs with plugins like Display Layer Progress that injects a bunch of M117 commands into the data stream which can increase the amount of buffer that is filled up while printing.

thanks for your inputs. I just tried in safe mode... no luck there. the results is the same with a lot of blobs compared to the sd card print who run smoothly.
[EDIT]
Hummmm... after some thoughts, is it normal to transfer some gcode file extremely slowly to the sd card from octoprint ?
For exemple I have a file : cube.gcode on my computer and it weights 1mo. How long should it take to transfer to the sd card (using octoprint in chrome on my computer) ?
Because for me it is extremely slow! is it a clue ?

in the end, for a 1,3MB file, it took 10 minutes !

Yes, this is normal as the process for transferring/uploading to SD card is done as if it's printing by writing a single line at a time through the firmware.

I have upgraded my firmware for the last version of tiny machine (for creallity cr10s pro v2) and updated my raspberry pie.
No luck there... I have changed the usb cable (with tape on the pin). Still no luck... I don't understand. How can I have such a clean print with the sd card and those ugly blobs with my octoprint.

Today I will try removing display layer progress
[EDIT]
nop, removing display layer progress from my plugin did not solved it. I did not saw any M117 commands. The prints still has the exact same issue.

is this normal ?

after disabling DLP plugin did you re-upload the file? I'm pretty sure DLP plugin modifies the file itself.

So I tried uploading the file again with octoprint in safe mode (just in case).
Same bad result...
I'm honestly out of ideas.

Tried a firmware from a different source?

I find it hard to believe that InsanityAutomation's build (that's what Tiny Machines 3D uses) aren't optimized for OctoPrint. I'm pretty sure he's at least set HOST_ACTION_COMMANDS and related settings in Marlin, just not sure how much buffer he's included. Can you share an example file @momodaron that is showing this behavior? I suspect something simple like a calibration cube wouldn't have this issue, and you're printing something with a lot of small movements or high-definition arcs?

1 Like

my file is a simple tower speed test from the web site of the youtuber teching tech : https://teachingtechyt.github.io/calibration.html#speed
here is the file
towerspeed.gcode (1.3 MB)
here is the result : (good on the left side (sd card), bad on the right side octoprint)
20230605-150349 hosted at ImgBB β€” ImgBB
I actualy have found out that my screen was turn on even with my printer electric plug turned off...
My usb cable wasn't enough protected (not enough tape on the last pin) on the 5 volt pin (so the printer was receiving electricity)! So I just triple taped it. I will test tomorow if this change anything. good night. and thank you for your continius help :slight_smile:

I am also getting this issue. I am ruining octoprint from a vm on proxmox and figured I was just struggling on a hardware front but I get the exact same issue as this.

Bobbling of filament on the outside of the print. I get it particularly on the outside of fairly right corners (diameter around 8-10mm)
If I take the same gcode file, download from octoprint and copy to sd card then it prints perfect.

Sorry to hear that @Squashyware !
In the end my issue with the usb cable was not the solution... So I'm out of ideas here. Maybe I will have to switch to octoklipper ... sounds a pain in the neck though...

The USB serial communication speed is dependent on the baud rate supported and may not have the same maximum transfer rate as the SD card accessed directly by the firmware.

For a large percentage of gcode files, this is not an issue but gcode files with lots of very short moves-extrudes (G0-G1) can cause the blobs and zits you are experiencing because the firmware can process the gcode faster than the serial connection can provide it.

Of the approximately 36,000 lines of gcode in the file posted by @momodaron, around 12,000 are less than 0.5mm and another 12,000 or so are less than 1.0mm.

There are a couple of ways to improve gcode files that have a similar distribution of commands. Probably the simplest is to use something like Arc Welder. This software is available as a plugin for OctoPrint. The printer firmware needs to have support for G2-G3 commands for this option.

Another is to simply slow down the speed(s) in the slicer. Unfortunately, this does increase the print time.

A third option that is only available if you have access to the model before it was converted to an .stl file is to specify a lower density of triangles used to model the curved surfaces.

Since I mentioned baud rate, make sure that the firmware is configured for the highest speed that the underlying hardware can support (while still providing reliable communications).

Thank you for this explanation ! :smile:
I have zits appearing already at 25 mm/s so it makes a 50 mm/s max for (overall) printing settings.
I think it's a bit to slow for me and I will most probably print with my sd card or upgrade for octoklipper. I will have to teach myself how to do that but I heard that it wasn't that hard thanks to the plugin. @Squashyware , I hope this answer helped you too. I will tag @b-morgan 's message as the "solution" even though it's not really a "solution" per say but It is a great answer to my questions.
:+1:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.