Monday, May 2, 2011

Firmware print quality: Part 2

This is a follow up to part 1's look at accuracy.  To expand on this I will be showing both accuracy of the steps take and how they match to the input gcode.

The test systems were Arduino Mega and a PC running EMC2.  All firmwares were configured with 100.0 steps/mm on X, Y, and Z; and 10.0 steps/mm on E/A.  E/A was also configured with as near to infinite speed and acceleration so its timing wouldn't dominate X and Y.  This results in each step being a nice round 0.001mm and all gcode moves are exactly divisible info steps.

Step pulses were captured using a Saleae logic analyzer at 4 Mhz rate.  For a step to increment in both X and Y in a diagonal the timing needed to be faster than the capture frequency.  Almost all firmwares set step bits for each axis sequentially and would not show any diagonal steps, Grbl and EMC2 being exceptions to this.

Each output image is an extreme zoom into the bottom center hole of a Mendel frame vertex.  The green segments represent the input gcode and are 0.01mm wide.  The alternating blue/red lines are the actual step path, each step is 0.001m and the step line itself is 0.0005mm wide.  The blue/red alternation shows where the firmware stops and starts the next G1 move.

FiveD official firmware

Tonokip

Teacup

Sprinter

EMC2 G61 (no path optimization)

EMC2 G64 P0.05 (0.05mm max optimization)

EMC2 (default path optimization)

FiveD official firmware and EMC2 (G61) are pretty much prefect.  Even steps following the gcode lines and G1 moves align to the steps.

Teacup and Tonokip show less than optimal step patterns, but the start and end of the G1 moves do align.

Sprinter shows an off by one rounding error on its move start and endpoints.  This is a non-cumulative error and doesn't get worse as the print goes on.  This is not a defect in the graphing or step pulse capture.  Over the entire print each transition is randomly are off by one on the plus side of X and Y.  Could be off by plus one on X or Y or both or none.

Overall all the firmwares were very accurate.  The errors seen were in the range of less than 0.01mm and is unlikely to cause any problems in a print.  Using EMC2 on its default path optimization probably would show defects in a well dialed in skeinforge profile.




Friday, April 29, 2011

Firmware print quality: Part 1

I have been working on a method of measuring the quality of the different Reprap firmwares.  Most of the firmware projects start out with the goal of being better than X, but there must be a way to determine if that goal was meet.

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.