Step one was to find a way to get the output of the firmware. Using my newly acquired logic analyzer it was straight forward to hook up the leads, send the gcode, and convert the captured data to a SVG of the resulting idealized path.
Here is a zoomed in section of a Sells Mendel frame vertex processed on these firmwares.
Teacup
Tonokip
Klimentkip
Grbl
EMC2
 |
| Teacup |
 |
| Tonokip |
 |
| Klimentkip |
 |
| Grbl |
 |
| EMC2 default planner tolerance |
 |
| EMC2 0.05mm planner tolerance |
Teacup suffers from some small geometric distortion on the ends of a move, while Tonokip has the most issues. Klimentkip looks very good. Grbl is shown as a reference of the best looking movements.
The biggest surprise was EMC2 in its default configuration. I knew that it took some liberties with the path to allow for higher cornering speed, but this was unexpected. It has the byproduct of making the segmented circles round again. The planner tolerance can be adjusted by doing "G64 PX" where X is the max distance the planner can deviate.
Accuracy? I suppose that's one test.
ReplyDeleteTeacup is known to do "some small geometric distortion" this is due to the internal representation of floats - it's all fixed point rather than true floating point. This should make it much faster, (and smaller, fits on a atmega168) and was part of the reason for writing it. The standard firmware does true floating point math - some of it in interrupt context even. This makes it slow.
*Much* more interesting would be a look at maximum step rates, command turn around times, segment pausing between "queued" commands, and error response stuff. I.E. if you send an invalid command in a string of valid commands, does it correctly ask for the invalid one, and does it still execute the commands in the correct order? That's a tricky one!
On maximum step rates, the standard firmware should be the bottom of the heap, due to floating point math in interrupt context. Teacup is probably the best, as that's one of the things it's optimized for.
On command turn around times, I'd think all firmwares will be about the same b/c it should be mostly delay introduced by the USB buffers.
On segment pausing, the teacup firmware should come out on top. There's not even a hesitation between consecutive moves, the step timing shouldn't miss a beat between moves going the same direction.
On correct error response, I'd not be surprised to see every firmware failing to one degree or another. It's a tricky problem, and introduces a lot of latency. If the firmware drops all subsequent commands it'll have to ask for a resend on the ones it missed. Otherwise it'll have to queue those "not yet" commands up somewhere, and dump them into the real queue when the invalid command is resent. One is very complicated (thus error prone), the other involves resending lots of stuff, and the third option (accidentally printing out of order) would really screw up your print!
How was this data generated? Some fancy logic probe and plotting the resulting lines?
I'm looking forward to further results!
Step logic was captured using http://www.saleae.com/home/ probe and then a awk script just converted that based on the logic transitions to a SVG file. I simply took a screen show at max zoom level in Inkscape. The process could be improved, but got the job done for the first pass.
ReplyDeleteI agree that many other things also factor into the performance of the firmware and this is just eh starting point. Most of the other tests require the step captures as a starting point.
Doing tests on max step and command rates is straight forward. I am struggling on a good way to represent step timing and the jitter caused by the common algorithms.
On the issue of inter command pausing, most didn't have this but Tonokip had 500ms pauses because there was no command queueing. So it is a factor when using older firmware styles.
@jv4779: great article! I hope to see more of these comparisons in the future.
ReplyDeleteBTW, Klimentkip and caruKlip now merged in a new fork, and the firmware is now called Sprinter.
@JohnGilmore: I don't know what you mean by standard firmware, but Sprinter doesn't do any floating point math in interrupt context. So we are obtaining both geometric precision and high max step rates, maybe a little at the expense of command turn around time. It would be interesting to see a comparison on the latter too, but as you say most of it should be serial lag.
This is really interesting work!! I would also like to see something like the color or thickness of the line segment be in proportion with the time it took. This way you can visualize latency problems. I wonder what complexity G64 S... suport would add when implemented in firmware. Sounds like a great feature to use instead of using more segments, especially since most STL files don't have the detail and always result in straight line G-Code....
ReplyDeleteI'm quite supprised by the differences that you have shown.. Very interesting plots..
ReplyDeleteGiven the nature of the print material sagging into its final shape. I wonder we could start to define the optimum accuracy that is needed to get the best print. Any higher accuracy could be wasted by natural sagging of the molten plastic.