Pen plotters

A recent eBay purchase of a broken Roland DXY-1350a gave me a project to fix and a new medium to explore.  Fixing the plotter took a few weeks as something heavy was dropped on the pen arm breaking some guide tabs and two bearings broke free and were lost.  I machined a nylon sleave to adapt a standard bearing to the size needed, eploxied the tabs back on, and it was back in business.

I threw together some adapters to fit Stabilo Point 88 pens into the plotter.  Many others have posted showing details on this processes which helped me get them working quickly.

Here are my first creations using my code to produce DXF files that get converted to HPGL by V-Carve Pro.

Laser projector playing MAME vector games

I enhanced XMAME to output vector games to an RGB laser projector using OpenLase,  OpenLase doesn't currently support RGB mode so it was added to my version of the code.  All the XMAME compatable vector games work with varying degrees of performance.  Some just have too many lines to display flicker free.  Star Trek has just enough to make a good game and not too much flicker.

Multi tool turning on a cnc mill

Greg at TX/RX Labs hacker space asked me to make him some prototype Delrin wheels for his tripod 3D printer.

Word War VI zoetrope

An edge-lit acrylic zoetrope based on the linux game Word War VI. The game was written by Steve Cameron, a fellow member of hackerspace TX/RX Labs. I was looking to do a zoetrope project and his vector based game was perfect for a straight forward laser etched animation.

The display is a series of 12 frames on a spinning acrylic disk with a ring of LEDs around the edge that are flashed every 1/12th of a revolution to make the animation appear. A stepper motor directly drives the disk which is being controlled by an Adafruit motor shield on an Arduino UNO. The LEDs are switched by one of the extra h bridges on the motor shield. All the timing is done open loop with the Arduino just counting nanoseconds between when to flash and when to step the motor. (code)

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.

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.