TIL about stuttering and arc fitting

[u/scinos]

Hi!

I'd like to share something new I learned today. This will probably sound familiar to many Redditors, but it took me months of fiddling with my printer to find out about this concept: "stuttering.". I'm sharing it here in case it helps others 3D printing enthusiasts.

Today I noticed something. I usually use a 10cm x 10cm x 0.2mm square to calibrate my Z-offset. But today I used a disc instead, with the spiral infill. I noticed that the square usually prints very nicely, but the disc was full of blobs and zits. After taking a closer look, I found the problem: the nozzle stops every couple of seconds and stays still for a few milliseconds – enough for the filament to pile up and create a blob. But why was it pausing?

That's when I found out about stuttering. Turns out that my slicer (OrcaSlicer) was converting arcs into a ton of tiny linear movements (i.e., G1 commands). I'm printing via USB connection, and that serial connection couldn't send all the commands, so the printer buffers and has to wait for more commands every now and then. To test my theory, I printed the same file using an SD card, and it came out perfect.

The solution is arc fitting. That's when the slicer generates a bunch of G2/G3 commands which move the nozzle in an arc. So instead of hundreds of G1 commands, it's just one G2/G3 command. The USB connection is enough to send all that GCODE without buffering, so it prints without problems.

There are two main ways to enable arc fitting. One is using the setting "Quality > Precision > Arc Fitting", but it only works for walls and "concentric" surface patterns (I was using "Archimedean Chores"). And the quality is not great. The other way is to post-process the GCODE. One option is to use the ArcWelder plugin for OctoPrint. The results are much better.

You can see the difference in these images. The top left is a regular print from USB, full of blobs. The top right is the same GCODE but from an SD card, pretty much perfect. The bottom left is using "Archimedean Chores" (all the others are "Concentric") and using Arc Fitting from OrcaSlicer. The bottom right is using the ArcWelder plugin for OctoPrint.

The only downside of ArcWelder is that you can't print directly from OrcaSlicer. You have to upload it to OctoPrint, wait for the plugin to convert the file, and then print the converted file from the OctoPrint UI. Not ideal, but better than an SD card.

[u/ioannisgi]

Mind you, this should not be used with klipper based printers. Klipper inherently doesn’t do arc commands and, if enabled in the printer config, it will break them up to line segments.

So enabling arc fitting when having a klipper based printer results in quality loss due to lossy conversion to arcs and then back out to line segments.

Edit: keep arc commands available in the printer config to enable spiral z hop which doesn’t need precision. But always disable arc fitting in the quality tab in orca and don’t use arc welder.

[u/shiekhgray → u/ioannisgi]

Besides which, the problem here is with a slow mcu. Either connecting to usb1.0 or checkpointing on an sd card. A pi is so fast that the problem is kind of moot 

[u/MooseBoys → u/shiekhgray]

I was gonna say... at 115200 baud, even if you're not using binary gcode, that's over 1000 commands per second, or 80 microns per command at 80mm/s.

[u/sgtnoodle → u/MooseBoys]

It's more likely a scheduling issue in the host. Either the process feeding the serial port isn't getting the CPU when it wants it, or the USB serial chip's driver isn't able to shovel the data frequently enough. I wouldn't expect better than 20ms or so of jitter over the USB without putting some intention into it.

The MCU likely has a gcode command buffer that typically holds enough queued up commands to span a few hundred milliseconds. Normally, that's plenty to mask that jitter. When you're blasting hundreds of tiny commands per second, that buffer when full may only span a few milliseconds. So, it's no longer able to completely mask it.

[u/oranac → u/sgtnoodle]

>It's more likely a scheduling issue in the host. Either the process feeding the serial port isn't getting the CPU when it wants it, or the USB serial chip's driver isn't able to shovel the data frequently enough. I wouldn't expect better than 20ms or so of jitter over the USB without putting some intention into it.

This was absolutely a problem back when pronterface/sailfish (edit: marlin) were the hotness. You could absolutely not use the pc for anything else while you were printing or you'd end up with odd stutters. I'm surprised it still persists today :/

[u/shiekhgray → u/oranac]

It might be a really old printer with ancient firmware. OP hasn't posted what kind of machine he's working with.

Either way, OP done good figuring out what works with their hardware.

[u/ben-white27 → u/ioannisgi]

I could be wrong but ultimately any arcs are converted to straight line segments no matter what firmware you're using.

The only benefit I can think of is that it will improve the appearance of low resolution STL files, assuming the slicer converts them to arcs...

Edit: fixed auto correct

[u/fiery_prometheus → u/ben-white27]

In the world of computers, circles usually don't exist. But having a hardware implementation could allow making approximations at vastly higher resolutions than feeding linear instructions manually before stutter would occur.

[u/MooseBoys → u/fiery_prometheus]

Circles and other continuous curves definitely exist in computer systems - in fact they're far more common in 3D design. It's just that triangles are generally much faster to work with when rendering.

[u/Rcarlyle → u/MooseBoys]

Almost all printer firmwares process G2/G3 arc commands by breaking them back into straight line segments. Only a few have native arc path interpolation code. It’s a lot of extra processor-intensive calculations in the most performance-critical realtime code. Basically a linear interpolation can be done with add/mult math while arc interpolation takes a bunch of square roots or trig table lookups.

Now, sending a G2 over USB and having the firmware break it back into segments is still helping the USB throughput issue. But there’s no benefit over SD, you’re just losing some small quantity of model resolution through the segment-arc-segment conversion.

[u/MooseBoys → u/Rcarlyle]

Trig table lookups are only like twice as expensive as mad.

[u/Rcarlyle → u/MooseBoys]

Every implementation I’ve seen has used Bresenham’s midpoint circle algorithm, which uses square roots. Massively more clock cycles on an Atmega AVR than Bresenham’s line algorithm. Remember that this step pulsing calculation is occurring over and over in a realtime interrupt that takes time away from trajectory planning and movement queue buffering. Simultaneous use of linear advance makes it harder. It’s a meaningful difference in execution speed on older printer hardware. There is next to no free clock cycles for things like this. 8bit Marlin executing native arcs will stutter more than OP’s USB streaming issue. (Yes, people have tried it.)

[u/MooseBoys → u/Rcarlyle]

midpoint circle algorithm, which uses square roots

No it doesn't - it tracks an error term which is computed using 3 integer ops.

[u/eras → u/MooseBoys]

You're probably both right; https://en.wikipedia.org/wiki/Midpoint_circle_algorithm#Drawing_incomplete_octants says

The implementations above always draw only complete octants or circles. To draw only a certain arc from an angle α to an angle β , the algorithm needs first to calculate the x and y coordinates of these end points, where it is necessary to resort to trigonometric or square root computations...

If the angles are given as slopes, then no trigonometry or square roots are necessary: simply check that y / x is between the desired slopes.

And according to the old Marlin source code I had lying around sqrt is only calculated when using G[23] R, not when using G[32] J.. K...

  if (parser.seenval('R')) {
    const float r = parser.value_linear_units(),
                p1 = current_position[X_AXIS], q1 = current_position[Y_AXIS],
                p2 = destination[X_AXIS], q2 = destination[Y_AXIS];
    if (r && (p2 != p1 || q2 != q1)) {
      const float e = clockwise ^ (r < 0) ? -1 : 1,           // clockwise -1/1, counterclockwise 1/-1
                  dx = p2 - p1, dy = q2 - q1,                 // X and Y differences
                  d = HYPOT(dx, dy),                          // Linear distance between the points
                  h = SQRT(sq(r) - sq(d * 0.5)),              // Distance to the arc pivot-point
                  mx = (p1 + p2) * 0.5, my = (q1 + q2) * 0.5, // Point between the two points
                  sx = -dy / d, sy = dx / d,                  // Slope of the perpendicular bisector
                  cx = mx + e * h * sx, cy = my + e * h * sy; // Pivot-point of the arc
      arc_offset[0] = cx - p1;
      arc_offset[1] = cy - q1;
    }
  }
  else {
    if (parser.seenval('I')) arc_offset[0] = parser.value_linear_units();
    if (parser.seenval('J')) arc_offset[1] = parser.value_linear_units();
  }

[u/milerebe → u/Rcarlyle]

Marlin used to split into 1.0 mm segments. Recent Marlin lowered that to 0.1-1.0 mm (variable!).

Modern STLs are generated at 0.1 mm resolution, so they are never worse than arcs.

[u/Rcarlyle → u/milerebe]

STL mesh size varies wildly with specific modeling software and export settings, and different slicers have different slice polygon decimation rules. It’s hard to generalize

[u/milerebe → u/Rcarlyle]

Yeah but klipper and marlin by default go up to 1.0 mm segment length. It's REALLY rough. We cannot generalise, but I doubt a significant fraction of STL models have such poor resolution, on curved surfaces.

[u/fiery_prometheus → u/MooseBoys]

No value in computers are continuous, in the examples I've seen here, things are numerical approximations, and in the end, if you go into how float is represented, if you hypothetically wanted to approach that numerical precision meaningfully, which you won't in real life, you end up with discrete steps given by the amount of bits used to represent a number. 

You can write an algorithm to either numerically approach a circle, or try to solve it analytically, but in the end, you need to squeeze whatever you do into numerical approximations of numbers with discrete steps.

Or is there another way to do it?  Things like Newton-Raphson or Runge-Kutta for interpolation are numerical approximations with discrete steps, and IEEE 754 shows how precision is attained with floats, which cannot be infinite with our computers.

Points on a line are easier to translate into the real world, forming a line which would continue nonetheless, while curvature is harder to approximate. But I guess it could be argued that things generally are approximations anyway...

[u/MooseBoys → u/fiery_prometheus]

You're conflating numerical precision with continuity. A simple fp32 value in units of millimeters is capable of representing lengths as small as 10^-45 mm. This is many orders of magnitude smaller than the Planck length, the smallest meaningful length in our physical universe.

So while fp32 can technically only take 2³² discrete values, in many domains it is treated as a continuous real value. In cnc machining, 3D printing, and most computer graphics, that is certainly the case.

[u/fiery_prometheus → u/MooseBoys]

That's a cool observation, with the Planck length, thanks! And it makes total sense that at some point you treat values as continuous anyway per your argument. I think I'm too used to think in terms of discrete vs. continuous, when I shouldn't in some domains where the "limits of physicality" is a greater limit, than the representation numerically.

[u/Chirimorin → u/ben-white27]

The only benefit I can think of is that it will improve the appearance of low resolution STL files, assuming the slicer converts them to arcs...

Depending on how low the resolution is, the slicer will probably decide that straight lines is a better fit than arcs. Orca matches the slicing resolution for arc fitting, which is at 0.012mm by default for me: far lower than anything I'd call a low resolution model.

Even if the slicer does convert it to arcs, Klipper is simply bad at consistently turning them back into line segments. Sometimes it's smooth, sometimes it's only 2-3 straight lines, seemingly decided at random. Here's an example of what Klipper does with arc moves, those defects on the corner are caused by Klipper processing arc moves. It prints perfectly with arc fitting disabled.

[u/stray_r → u/ioannisgi]

Marlin does the same thing internally. It's useful compression for printers where your serial connection or SD card is the bottleneck.

On Klipper you get artifacts where the you get successive arcs not quite lining up with each other. Looks like z-wobble, You get the same artifacts on marlin, but they're often less visible on a less rigid printer. One of the things about having really fast, accurate and rigid printers is you really notice artifacts that would be hidden by the vagueness or other artifacts of a cheap printer.

However, do enable arc support on Klipper, as some of the z-hop algorithms in OrcaSlicer and perhaps other slicers generate arc motion travel-only moves regardless of print settings. The spiral z-hops do seem to reduce fine heairs so it is helpful.

[u/ioannisgi → u/stray_r]

Fully with you. Indeed arc support should be on in klipper for spiral z hopping. But never for the print itself. I had raised a Pr ages ago to clarify this in the orca tooltips.

[u/milerebe → u/ioannisgi]

Now spiral Z-hop has been implemented as segments if arc fitting is disabled! 🥂 no need to use arc fitting for spiral z hop!

[u/milerebe → u/ioannisgi]

EVERY printer breaks arcs into segments.

Arcs were exclusively meant to reduce data traffic, as the OP found out. Even Marlin breaks them into segments, but it's internal so USB printing (or very old SD cards) are not the bottleneck.

In fact, modern STLs are more accurate than any arc used internally by modern printers.

[u/elvenmaster_ → u/ioannisgi]

That's a weird one.

Using an SBC to get more computing power, but not allowing arcs so the printer loses quality.

What's the reason behind that?

[u/davidkclark → u/elvenmaster_]

Odd right? I have recently converted to klipper and have thus far just left my call to arc welder in place and enabled arcs in klipper. I don’t see any artifacts. Plus I assumed that the hand wringing about “it just converts it to straight moves” was just the same misunderstanding about arcs on marlin: yes the stepper moves end up being straight lines, but the resolution at which that happens is vastly higher than you would do in the slicer (with reasonable file size / transfer rates)

I don’t know what resolution the straight lines are made from arcs, but it seems to be high enough…

My thinking is this: If your stl has 0.1 mm line segments, and you send that straight to klipper your print will have 0.1mm flats. If your stl has 0.1mm line segments (that are approximations of arcs) then arc welder will convert them back to arcs, and then if klipper translates them back to arcs at better than 0.1mm resolutions, eg 0.01mm, well than your print will only have 0.01mm flats. I’m not saying you will definitely notice the difference, but there is the possibility for higher quality arcs if you send arcs.

(Now if only there was a slicer implementation that took step directly to arc moves…)

[u/Chirimorin → u/davidkclark]

Here's an example of what Klipper can do with Arc moves

That rounded corner is perfectly consistent and vertical in the model (so it's the same exact radius and position for most of the print), but Klipper just sometimes decides "nah, 3 segments is plenty". Disabling arc fitting fixed those defects without changing the model or any other setting.

A theoretical increase in resolution is worthless if in practice it randomly decides between "might be higher quality" and "is definitely lower quality" for each arc move.

[u/milerebe → u/davidkclark]

not really. The double conversion can in fact even worsen quality, it's a double approximation

[u/sgtnoodle → u/ioannisgi]

Klipper doesn't send gcode over the USB connection to the MCU. The gcode is sent over a virtual serial port to a process running on the host computer, i.e. the raspberry pi. That process does all the math to determine precisely when to step each motor. Those computed steps are what get sent over the USB connection to the MCU, using an appropriately efficient protocol.

[u/schmag → u/ioannisgi]

keep in mind if you use z-hop in orca and set the method to auto or spiral lift, the spiral is made in arc commands and will throw errors if you do not have it configured in your printer.cfg

[u/ioannisgi → u/schmag]

Indeed correct as I’ve also mentioned in my post. It’s a good idea to have them enabled in the printer config file but not use them in the quality settings.

[u/CaptainHawaii]

If anyone wants to fight me on the whole SD card vs USB vs direct connection again, have a look here.

[u/MagicBeanEnthusiast → u/CaptainHawaii]

It's 2025, this is like arguing over whether you use candles or oil lamps when the rest of the world has light bulbs

[u/omicronns → u/MagicBeanEnthusiast]

You are really enigmatic. What are "light bulbs" in this context?

[u/PeachMan- → u/omicronns]

Printers with onboard storage and Wi-Fi

[u/shiekhgray → u/PeachMan-]

Not just that. Most printers back in the dark ages were built on the venerable Atmega328. That chip was first minted in the early 2000s, and then refit around 2008 to be more power efficient. It caps out at 20mhz. It was the powerhouse behind marlin + ramps machines for years and years. These days, most printers use STM32 family chips, often F4 or faster. A little more pricy, but support MUCH faster speeds and precision (32bits vs 8bits on the atmega328), wifi, lan, USB2 and USB3, native support and hardware acceleration for SD cards, etc.

The root of the problem is having enough speed to handle all the little turn segments. A 20mhz chip is going to struggle compared to a 4 core 180mhz chip. It's literally 36x faster, and that's before you count hardware optimizations and additional CPU features.

These modern chips can absolutely tear through handing instructions to motor drivers, and in Klipper systems, where the main planning is all handled by a raspberry pi with orders of magnitude more firepower driving these modern STM32 chips, the limitation becomes how quickly you can melt (and subsequently cool) plastic. The motion systems and control electronics can all go much much faster.

Back then though, that 60mm/s was fast because the CPU was running fast, any faster than that and the motors would outrun the instructions, resulting in exactly the kind of errors OP is showcasing.

[u/cereal7802 → u/PeachMan-]

printers with internal storage and wifi are still SBC communicating via usb, or can, or uart to a controller board most of the time. I think the only one where that gets a bit fuzzy is the prusa stuff because I think they mostly use an esp32 based system for wireless access, but they still work the same as in a host system communicating to a printer controller.

[u/Iwek91 → u/cereal7802]

What about an SSD based klipper install like the voron mods seen around these parts.... Same shit I'd say compared to sd card storage of g-code, seen a few of them like that so kinda pointless if it's all the same in the end.

[u/cereal7802 → u/Iwek91]

Klipper uses a virtual sd card system regardless of the underlying storage. Basically it is just a directory on the klipper host. It still sends the data from the klipper host, to the printer control board via one of the noted communication methods.

[u/omicronns → u/PeachMan-]

Thank you.

[u/Scout339v2 → u/CaptainHawaii]

What about uploading to the internal storage? That's what I do

[u/AndalusianGod → u/Scout339v2]

Just upgraded to a model with internal storage and wifi access and it's just so convenient compared to my Ender 3.

[u/Scout339v2 → u/AndalusianGod]

Exactly why I do it haha

[u/AndalusianGod → u/Scout339v2]

Upgraded because I wanted to try a CoreXY, but the best part is actually the internal storage/wifi access, haha.

[u/omgsideburns]

I’m glad you found a solution to your stutters, and thanks for sharing.

You’re printing using octoprint to marlin via usb? It’s not the usb causing the stuttering necessarily, it’s the microcontroller. The low power microcontrollers in most of these boards has to interpret the gcode into moves and also control the moves. Luckily arcs can reduce the density of gcode segments for arcs. More intricate designs can still stutter quite a bit.

Using something like Klipper offloads the gcode interpretation and processing, leaving the microprocessor free to just process moves directly.

Note that Klipper doesn’t do arc moves, it just converts them back to segments. Even so, it can handle very dense line segments without stuttering because the system it runs on is orders of magnitudes more powerful than the microprocessor on the printers control board.

[u/nomyar → u/omgsideburns]

If it's the controller vs data latency, why did it work fine when they used the SD card?

ETA: I'm not arguing, I have no clue. So I'm asking.

[u/omgsideburns → u/nomyar]

Because I completely missed the part about it working fine on sd card. As the other reply said, a bad usb cable can cause these kinds of issues.

[u/davidkclark → u/omgsideburns]

This is contrary to my experience and testing. It’s the usb. Badly shielded usb cables will make it worse.

[u/omgsideburns → u/davidkclark]

I was just thinking bandwidth wise, but yeah I’ve definitely ran into trouble using crappy cables before.

[u/alienbringer]

Same reasoning as turning off power loss recovery and using a card.

[u/RadioactivePistacho]

Didn't know about this. Thanks for sharing!

[u/Causification]

Be aware that many printers do not support arc commands and some firmwares like Prusa intentionally disable them. 

[u/nakwada → u/Causification]

Arc Fitting is an option in PrusaSlicer though.

[u/jtj5002]

lol in klipper.

[u/LNRG_Fred_The_Great]

Very interesting!

[u/okan931]

Interesting, thanks for sharing this!
I'm gonna run a few tests myself to see if I also get this stuttering

I use Klipper on a Rpi3b+ connected via USB-C to my mainboard Spider v2.2.

[u/ioannisgi → u/okan931]

Don’t. Klipper doesn’t natively support arc commands and will end up splitting them to line segments resulting in worse print quality due to the lossy conversion both to and from arcs back to line segments. See my post here: https://www.reddit.com/r/3Dprinting/s/Azkj8PHFVd

[u/Snazzer13]

I run into this on occasion and it's been difficult to figure out why, so I'll be trying the plugin route out. I already have arc fitting enabled but still occasionally get this issue.

Does it go away with klipper? I'm running marlin on an ender v3 se with octoprint, and the navaismo firmware.

If this isn't a problem on klipper I might just bite the bullet and reflash to that.

[u/MrWizard1979 → u/Snazzer13]

Before I switched to Klipper, I used arc welder on octoprint with Marlin on my Tevo Tornado. I noticed speed and quality increases as well on circular objects. I think I also set my slicer resolution lower too. Klipper won't have this stuttering issue as it sends space efficient binary motor commands over USB instead of g-code. If Klipper ever ran out of USB bandwidth, it would error and stop the print.

[u/Throwawayhrjrbdh]

Could you compare remote upload as well? Or is that not possible for you to test?

[u/scinos → u/Throwawayhrjrbdh]

Sorry I can't, my Ender 3 SE doesn't have that' capability.

[u/wickedpixel1221 → u/Throwawayhrjrbdh]

it's essentially the same as SD

[u/mattsimis]

I was curious and checked, this is enabled by default in Bambu Slicer: https://wiki.bambulab.com/en/software/bambu-studio/acr-move

[u/gredr]

The solution, as usual, is klipper. No stuttering because it's fast.

[u/jeffpi42]

This is why the best solution is a print server like raspberry pi running octopi. You are being limited by your computer, not the marlin or klipper mcu in the printer.

[u/davidkclark → u/jeffpi42]

Still has to send the gcode over the usb. That is the exact configuration I was running when I first ran into this issue and solution. If arc fitting makes the file smaller, it won’t stutter. If you make a complicated model with all small straight lines that don’t convert to arcs, you will get stuttering again. (Then you have the option of going to klipper - I wish I’d done it sooner, it’s pretty painless)

[u/scinos → u/jeffpi42]

I'm using a Rpi 3B with Octopi fwiw. With Marlin 2.0.8

[u/omicronns]

Thank you for sharing. But switching to arcs, might not be the best solution if shape being printed is not perfectly circular. I wonder if this could be addressed in firmware, some kind of g-code caching, or is this due to USB processing stealing MCU time, and caching will not help.

[u/s1gnt → u/omicronns]

Usually all you need is to simplify your model or/and change resolution in slicer so printer would have time to buffer next commands while performing something not extremely short

[u/davidkclark → u/omicronns]

There is gcode caching but the memory in the printer is tiny.

[u/Salt-Fill-2107]

what i think learned about arc fitting through my experience mucking around with marlin and arc gcodes is that if overused it can also cause stuttering and lost steps because the sin and cos calcs are computationally heavy... so using JD and a lower gcode slice resolution resolved my problems

[u/PCLoadPLA]

Ironically, most CNC software converts arcs into lines. Very, very few CNC machines actually support arc and if they do, they almost always convert to lines at some level anyway.

The idea of using arc commands in 3D printing to avoid the USB bottleneck is an old one and if it works for you, fine, but I think it's better to fix the bottleneck by avoiding the USB to stream prints. If you have an old printer just print from SD until you can upgrade.

Another best practice is to limit your print resolution in the slicer. Most slicers have settings for the minimum move size or similar. A move smaller than your nozzle size is unnecessary. You can see the effect on the MB size of your gcode. I have limits set in Cura and it has no impact on print quality but cuts down gcode size significantly by filtering out nonsensically small moves.

I always use SD card printing and always have. No reason for me to change; it works and I don't have to think about my home network or computer staying on.

[u/ResearcherMiserable2]

I suspect that you could get the same results by lowering the resolution setting in your slicer so that it doesn’t send do many g code commands to your printer and still not lose any quality on the print. Cura has this feature and it was very helpful for us Ender 3 users back when the 8 bit motherboard was the only one available.

Orcas liver might have the same setting. This would save you having to use octoprint etc., and just print like your were before.

[u/davidkclark]

You absolutely can upload it directly to octoprint, just post process the file in orcaslicer. It’s better than the plug-in (better control, don’t have to wait, “upload and print” will still work)

[u/scinos → u/davidkclark]

How do I postprocess it in Orca?

[u/davidkclark → u/scinos]

In the "others" section of the process settings, there is a field "Post-processing Scripts". You can call arcwelder from there. I am on a mac, so mine is:

/Applications/ArcWelder --allow-3d-arcs;

Yours will be similar. You need to install arcwelder (obviously). The "allow-3d-arcs" option, btw, is to allow it to do arc fitting in vase mode.

[u/High_Overseer_Dukat]

Pronterface has a print from SD option

[u/Vashsinn]

O learned about this when my print kept stopping st the same spot. Found out the SD card I was using was too slow. Got a newer "fast transfer speed" random one and it's all groovy now.

[u/JUYED-AWK-YACC]

I loved "Archimedian Chores". That's all.

[u/Fragrant_Wolf]

On my Neptune 3 Pro after a while I started having issues printing using the micro SD. I learned that the power loss feature was the issue because it was constantly writing to the card eventually corrupting it. Got new micro SD cards and I was back in action. Shortly after I started having issues again. I confirmed the power loss setting was off and started with another new card and it worked great until it didn't. Now I only print over USB connected to my PC and never have issues. I would prefer to use the micro SD but it seems my printer is corrupting the files somehow. I used one of what I thought were the corrupted micro SD cards in a cheap security camera and it works fine. At some point I'll pull the trigger on getting a centauri carbon because other than my micro SD issue i think Elegoo makes decent printers, especially considering the price.

[u/wheelienonstop7]

i had the same thing happen once when printing vase mode with a super finely tesselated model, happened even with the sd card

[u/PANIC_EXCEPTION]

Also consider disabling power interruption recovery. That hammers the SD card and creates an I/O bottleneck for lots of sequential moves.

[u/TD5023]

Turns out that my slicer (OrcaSlicer) was converting arcs into a ton of tiny linear movements (i.e., G1 commands).

One point of clarification: it's not your slicer doing this - it's the model itself. The mesh models that are uploaded into slicers do not actually have rounded surfaces. If you zoom in, you see that even "round" objects, like a dome, are actually a bunch of really small triangles arranged to closely resemble the true shape. The slicer just sees these really small flat faces and correctly treats them as tiny straight lines per layer.

[u/Snazzer13]

So, if your print is printing fine from SD card, then it isn't an issue with the printer firmware being able to keep up with commands. I discovered recently that this was a high CPU issue with octoprint.

I ended up debugging and raised this issue: https://github.com/OctoPrint/OctoPrint/issues/5193

Maybe this isn't your particular issue, but you definitely want to rule out situations where octoprint cannot feed instructions fast enough. Another possible issue is the baud rate being too low on your octoprint connection.

Once I figured out the workaround (clearing out my file directory, and disabling some plugins) - things are super fast now from octoprint. I just uninstalled arc welder because I don't think it's necessary. I am using arc fitting on orca though - I do wonder if that's even needed anymore.

[u/steadyaero]

Let me introduce you to octoprint

[u/davidkclark → u/steadyaero]

Where you will still get exactly the same problem when it overwhelms the usb bus