> printing so fast that I am causing buffer underruns on the processor?!?! Here's the deal with that. When you have a part with lots of direction changes the uC is required to feed the g-code buffer as quickly as possible. On 8-bit uCs this can be challenging, especially if reading the g-code from something like an sdcard reader. This is one reason why prints can be faster with the use of octopi, as reading from serial is much faster than the sdcard interface. Resulting in less CPU overhead. Less chance for stalled movement. This, in of itself, is one of the reasons the 32-bit uC boards can make printing faster. This is because they frequently have larger memories and faster clocks/instructions, which allow for larger gcode buffers and faster consumption/calculation of them. Plus, they can calculate the moves faster, providing more time for things like card reading. These larger buffers prevent movement stall, as does the faster calculations. In doing so, both speeds the print and slightly increases print quality. Explained in another way, for whatever reason the slicer developers decided they wouldn't use g-code arc commands and simply make all curves n-line segments. So if you have, say, 270' arc, that can be expressed with a single g-code. Or if you have n-line segments, you might have 60-line segments, resulting in 60 g-codes. Where only 40 of those may actually fit in the g code buffer. The later is why in the video you see slight pauses when it's consuming the line segment version of the arc. Though the high speed amplifies the issues. Practically, IMOHO, for most typical printers, you're unlikely to see those types of delays. But you are likely to see a slight improvement in print durations. As anytime you reduce the number of fetches on an 8-bit uC, you're likely to see a slight performance boost. But we're talking something of maybe 2% in time. Which on a 20 hour print is a around 30 minutes. With a for profit setup, that does add up. Realistically, depending on the nature of a print, could be more than that. > But most of the printing I do is small detailed parts and the name of the game is super slow and a tiny layer height... like 30mm/s and 0.05mm. This is what I do for printing figurines for table topping etc... You're definately in a minority group here with these fine resolution prints. BTW, what size nozzle are you using for this? 0.2? What extruder? Your area here is especially interesting as your small sizes means you're likely losing precision in every arc you print. See cura's Max Resolution and Max Deviation settings. So for your use, you might just see a very nice improvement in quality. This is because of the curve fitting. Though you may have already adjusted your slicer to make this a none issue. But... If you do, that means you've hugely increased the number of segments for a given arc. Which takes you right back up to the first part of my comment. Especially since you are using an 8-bit processor. Conceptually, this might be a really nice win for you, even including in performance (not holding my breath). So please share your results. If you don't mind, would love to see some of your print results. I really need to get my printers running again. I have a Tarantula and a Chiron. I'm mid way moding the Chiron with an upgraded extruder (Voron's Mobius geared) and drivers.