Scott Lahteine
patreon
Optimizing Marlin
🕑 Added 2017-11-03 02:54:28 +0000 UTC Even though Marlin 2.0 is going full blast incorporating support for the latest, greatest, and fastest 32-bit boards and micro-controllers, I haven't forgotten about 8-bit AVR! I'm always looking for new ways to optimize Marlin so that it can run faster, smoother, and cooler on the majority of 3D printers.Last year I took a stab at optimizing graphical display updates to prevent stuttering (caused by a "starved" planner). Within hours of posting that update, there was a sudden influx of help that brought even more significant improvements. As a result, today —even with a graphical display and fast print speeds— your delta will rarely stutter.
While that was an important milestone, for a long time I've had an ambition to better handle the workspace offsets that come with G92 and M206 and have the machine always operate internally in "native machine space." I thought it would be very difficult to accomplish, so I took an interim step to optimize the way workspace offsets are applied but left everything else fundamentally the same.
This afternoon —prodded by someone familiar with CNC— I finally decided to see whether this would be possible to do without melting my brain. So I locked and barred the doors, drew the shades… And as it turned out, it was not only possible but relatively painless. I couldn't be more happy to finally have this out of the way.
I haven't done any benchmarks yet, but this much I know: This change eliminates at least 6 float additions / subtractions for every planner move. The savings will be especially significant with Delta machines and with the bilinear mesh bed leveling systems, because these split up every move into smaller segments — often dozens of them.
This change will be included in Marlin 1.1.7 (coming soon!) and Marlin 2.0 (coming pretty soon!) I can't wait to get this out to everyone.
Fixed-Point Integer Planner
Are we all out of optimizations now? Oh no, not by a long shot!
The next significant improvement on the docket is the inclusion of a "fixed-point integer planner" in stock Marlin. This feature is already included in a few Marlin forks, including the Prusa MK edition. I wanted to wait until the main project was more stabilized and mature before incorporating it, and today's Native Machine Space patch was a vital piece of that puzzle. It means that we can have our cake and eat it too.
In short, one of the main bottlenecks of AVR processors is the lack of a floating point unit (FPU) to handle maths operations on real numbers. Every time you multiply, divide, or add on one of these processors it incurs the overhead of a function call. For this reason it's important to do as much work as possible using integers, which are significantly faster.
So-called "fixed-point" math is a way to make integers behave like decimal numbers by treating some number of bits as "right of the decimal point." You add, subtract, multiply, and divide them just like ordinary integers, but you throw away the low-order bits when you want to take the whole part. So, for example, the (8:8) fixed-point number 0x221E will be equal to 34 + 30/256 when converted to decimal. (Hex 22 is 34 decimal, and 1E is 30). To get the whole part, we can just take the first byte or shift the value right by 8 bits.
As you can imagine, switching to fixed-point saves an enormous amount of computation. And as we know, computation doesn't just cost time! It increases the heat generated by your board, the energy consumption of your board and cooling fans, and adds up real dollars on your energy bill after hundreds of prints. It might even shorten the life of your electronics.
So, if you don't mind, I'll just get back to the project now. I'm anxious to get this stuff integrated and take some real-world benchmarks!
See you soon!
Comments
Hi Andreas! TMC2130 is fully supported, including stallguard-based endstops. We'll have TMC5130 (and Trinamic TRAMS) support in Marlin 1.1.8 and 2.0.0.
hi scott is tmc2130 full supported ?
Gary Tolley
Accurate FPU calculations, as far as I was aware, the biggest annoyance. And had been one of the reasons for people to switch to 32bit. Keep up the excellent work. Always a pleasure to read through the various bugfixes and added features, and the migration to 32bit.
