Software accelleration
Bernhard, an Ultimaker power-user at MetaLab Vienna, has gotten the Sprinter firmware working on an Ultimaker. Sprinter is written by Kliment and Caru, based on Triffid Hunter’s codebase, based on FiveD [update]oops, it’s based on the Tonokip firmware[/update]. It has undergone some serious rework over time.
Inspired by his impressive results, I’ve also experimented with this a bit more. The travel speeds you can get out of this are a little better. Without accelleration the max speeds are around 333 mm/s (FiveD firmware) and with accelleration they were up to 533mm/s (Sprinter firmware). Somehow the firmware doesn’t seem to step the motors any faster. When you set the FiveD firmware at travel rates above 333 mm/s it actually goes slower than at 333mm/s. So somehow there’s some microcontroller congestion or it’s possibly a bug. The benefits of smooth acceleration are especially important for machines with a lot of moving mass. The Ultimaker isn’t the most spectacular example for acceleration because it already can reach the high speeds without software acceleration. For the Ultimaker, the biggest benefits of Sprinter firmware are expected to result from an increased buffer size.
Anyway, to show you the speeds we’re now talking about, this is the result:
With the help of Bernhard we finally made a few discoveries as to what causes a less smooth print at higher speeds (becoming noticeable at 70+ mm/s). When using ReplicatorG, the print results were not really much different, except when fillet is enabled in Skeinforge. Fillet is meant to smooth out sharp turns, but it turns out that it smooths out any kind of line segment also lines that nearly have the same orientation. Perhaps this behavior should be change with an angle limit. But Fillet causes the buffer to run dry because there are too many small pieces of G-Code that succeed each other in a very short amount of time. About every two visible segments, four lines of GCode are actually sent. This is, not coincidentally, also the firmware of the FiveD software.
All Sprinter prints were done from ReplicatorG, which now also has an Ultimaker Sprinter machine profile in the newly released ReplicatorG version at: http://software.ultimaker.com/. Note that: This Ultimaker release is not a fork of the normal ReplicatorG, it just undergoes some more testing and has the latest, tested Ultimaker drivers. All Ultimaker commits are publicly visible and offered for integration upstream.
Hi, sprinter is based (via a longish chain of forks) on tonokip. it has no relation to teacup or FiveD on Arduino. They are totally separate codebases 🙂
As for why sprinter doesn’t step faster when you tell it to go faster, it generates steps in a busy loop, so there’s a particular speed where it /wants/ to go faster but has hit the atmega’s processing speed limit and can’t run the loop any faster.
This is a limitation of the atmegas we’re using, and can be fixed only by getting more MIPS, or fewer clocks per 32 bit mathop, both of which require a different/bigger architecture like mips or arm.
Thanks for correcting me and clearing this up. I updated the post. I knew it was related to the 16MHz. We’re currently looking into ARM cores for future developments. But it’s great to see that we’ve been able to crank so much more out of the litte AtMega 2560.
With less microstepping, we could break the sound barrier probably…
hi erik are you italian?? if it possible can i have your private email , i would to ask you some question if it possible
Not Italian, I’m Dutch, hence the .nl in my domain. Use my domain name to make up any e-mail address.