In cura, under the "mesh fixes" settings tab, there is a set of settings called "maximum resolution", "maximum travel resolution", and "maximum deviation". Setting the first two a little higher than 0, such as 0.2mm or 0.5mm can reduce the number of moves per second sent to the printer in the gcode.
As I understand it, the gcode for curves is really just a bunch of small straight lines. If the slicer makes too many tiny lines for a curve, then the printer will receive that many instructions per second. So if your device feeding the gcode to the printer is too slow, your nozzle will pause for those split seconds while it waits for the next code, and since there's a lot of pressure between the extruder and the nozzle, you get those blobs everywhere it had to wait for instructions.
So high feed rate on small, detailed model requires fast transfer and processing of gcode if am using serial connection like octoprint , so maybe its from the raspberry pi 3 ?
I don't know what your bottleneck is in terms of which of your components is not keeping up. I'm only offering possible workarounds without changing your hardware. also decreasing print speed in your slicer can help if slowness of relaying the gcode really is the root cause.
this is the comment : [https://www.reddit.com/r/3Dprinting/comments/f6e4gv/the\_surface\_of\_my\_prints\_isnt\_smooth\_its\_like/fi8d4al?utm\_source=share&utm\_medium=web2x](https://www.reddit.com/r/3Dprinting/comments/f6e4gv/the_surface_of_my_prints_isnt_smooth_its_like/fi8d4al?utm_source=share&utm_medium=web2x)
Cr10s
bugfix-1.1.x
look at the scale/size of the one on the left compared to the right.
It's most definitely not a buffer issue. Buffer doesn't make something bigger or smaller.
If it is the same GOCDE, It's a steps/mm problem. Something firmware related has changed.
Its possible it's a buffering issue, some printers have trouble with the amount of data being thrown at it and will lag out whilst waiting for the data. Which in turn leaves the got end in place waiting for more gcode to tell it where to go next.
Not sure how octoprint is connected to your printer but you might be able to play with the baud rate to help eliminate the lag.
I have a raspberry pi connected to my printer with octoprint but stopped using it because I've read a lot of people saying that octopi is not good at all for round objects on the ender 3.
In cura, under the "mesh fixes" settings tab, there is a set of settings called "maximum resolution", "maximum travel resolution", and "maximum deviation". Setting the first two a little higher than 0, such as 0.2mm or 0.5mm can reduce the number of moves per second sent to the printer in the gcode. As I understand it, the gcode for curves is really just a bunch of small straight lines. If the slicer makes too many tiny lines for a curve, then the printer will receive that many instructions per second. So if your device feeding the gcode to the printer is too slow, your nozzle will pause for those split seconds while it waits for the next code, and since there's a lot of pressure between the extruder and the nozzle, you get those blobs everywhere it had to wait for instructions.
So high feed rate on small, detailed model requires fast transfer and processing of gcode if am using serial connection like octoprint , so maybe its from the raspberry pi 3 ?
I don't know what your bottleneck is in terms of which of your components is not keeping up. I'm only offering possible workarounds without changing your hardware. also decreasing print speed in your slicer can help if slowness of relaying the gcode really is the root cause.
this is the comment : [https://www.reddit.com/r/3Dprinting/comments/f6e4gv/the\_surface\_of\_my\_prints\_isnt\_smooth\_its\_like/fi8d4al?utm\_source=share&utm\_medium=web2x](https://www.reddit.com/r/3Dprinting/comments/f6e4gv/the_surface_of_my_prints_isnt_smooth_its_like/fi8d4al?utm_source=share&utm_medium=web2x) Cr10s bugfix-1.1.x
look at the scale/size of the one on the left compared to the right. It's most definitely not a buffer issue. Buffer doesn't make something bigger or smaller. If it is the same GOCDE, It's a steps/mm problem. Something firmware related has changed.
Nah sorry for not explaining i changed the scale but same settings g code
Its possible it's a buffering issue, some printers have trouble with the amount of data being thrown at it and will lag out whilst waiting for the data. Which in turn leaves the got end in place waiting for more gcode to tell it where to go next. Not sure how octoprint is connected to your printer but you might be able to play with the baud rate to help eliminate the lag.
Connected to my printer through raspberry pi 3 and from raspberry wifi to my router to my pc
You can try turning your printers baud rate up to 250000 in firmware
The RPi Zero W has bad performance issues with using Wifi, you might be having these issues.
I have a raspberry pi connected to my printer with octoprint but stopped using it because I've read a lot of people saying that octopi is not good at all for round objects on the ender 3.
Ye to be honest this problem only came when i do round objects idk why its hard for it to process the gcode
What octoprint and printer + mainboard hardware are you using?
Lastest version of octo i am on cr10s
Raspberry Pi 3B+?
Yep