OoeyGUI

Having moved past the pinion gear, I focused on the extruder barrel mount. It is fairly simple in design – a block of aluminum, bored to accept the barrel, slit, then drilled and tapped.

I attempted to cut a pinion gear again, with no luck.

I’m using a 24 pitch 14.5o involute gear cutter on a Sherline gear cutting arbor. I want to cut a 12 tooth gear. I turn a 3/4″ round bar stock down to 37/64.

(Teeth + 2) / pitch = Outer Diameter
(12 + 2) / 24 = .5833 ~ 37/64

I then transfer the chuck to the rotary table. I lower the headstock so that the bottom of the gear cutter touches the blank. I then divide the cutter height by 2, and lower the headstock by that much:
Cutter width = 15/64, half = 1/8.

The radius of the blank is 19/64.

And somewhere I’m off by a 1/64 of an inch which blows the tooth geometry…

I much be sloppy somewhere and am just missing it.

I’ve always loved gears. Who doesn’t? Since getting the lathe and mill, I couldn’t wait to try to make gears. Slowly, over the last year, I’ve acquired the components to make a gear – from the rotary table, the angle plate, the gear cutters, the arbor, the threading attachment so I could make a gear cutting mandrel… I was finally able to make my first set of gears:

These will eventually be the cord engagement gears. I need to mill the 1/8 grove which will capture the cord.

I had much less luck with the smaller pinion gear:

As you can see the teeth aren’t formed correctly. This is actually the 3rd attempt. On my first attempt I accidentally attempted to cut 24 teeth instead of the 13 I was shooting for. I decided the second attempt to cut 12 teeth because it divided cleanly, but forgot to adjust the blank diameter. The third attempt, it looks like I forgot to center the cutter, so it is off… Too late to start a new blank, so left for another night.

For kicks, here’s my gear cutting setup:

During the Seattle robotics meeting, I ‘crossed the streams’ (reverse polarity) and destroyed the motor controller (and presumably the motor, don’t want to take changes). Given that I wanted to standardize on the 12v motors I was using for the Axis, this seemed like a good time to incorporate this motor into the extruder. 

While building the new motor mount, I decided to look into a different type of extruder drive, similar to the pinch pulley, but built with gears. Two drive gears have a 1/8 channel milled into them. The gears with the channel ‘capture’ and hold the plastic cord. I wasn’t sure how long the urethane pulley would last, so this is an experiment.

 

To teach the Karate kid how to defend himself, Mr. Miyagi used repetitive mundane tasks that mimic various defense maneuvers. This repetition created muscle memory for the moves which ultimately lead to victory during competition.

Patterns are the muscle memory of programmers. They are time tested generic solutions to generic pervasive problems. Patterns provide terminology, improve maintainability, are relatively self documenting, and improve reusability. While not appropriate in all situations and difficult to build in at design time, I’m very much a fan of refactoring to patterns.

I love Wiring. It’s a cute API which enables more people of diverse backgrounds to enjoy playing with Microcontrollers. Wiring as an API doesn’t enforce a design model on users of Microcontrollers, which I believe is both a strength and a weakness. As a strength, the lack of structure is more approachable to developers. As Wiring projects become larger and subject to more uses than hey originally built for, the lack of structure becomes a weakness – It becomes harder to share or reuse code.

Fabr uses a stepper motor for the extruder instead of an brushed motor. This has caused me problems integrating the RepRap code directly into my project. With the support of Zach, who created the original RepRap firmware for the Arduino, I’m going to attempt to refactor the code base to use patterns and implement device abstraction.

RepRap today

The RepRap code is currently broken up into multiple functional groups:

• The Main Loop (GCode_interpreter.pde) – This component is responsible for initializing the other components, servicing the serial port, and driving the Gcode processor.
• The GCode Processor (process_string.pde) – This component is responsible for breaking command strings into constituent parts, and driving the Stepper manager or extruder as required by the command (such as setting temperature).
• The Stepper Manager (stepper_control.pde) – This component is the guts of the interface to the reprap. It manages the axes, and turns on and off the extruder motor.
• Extruder Manager (extruder.pde) – Manages the extruder motor, heater, and temperature feedback mechanism.

This design has a few limitations which I hope to address:

• There are several blocking loops (Main, Axes Stepper, Extruder)
• Each component has internal knowledge about the other components
• Tight coupling between the hardware implementation, the code to drive it
• The code assumes that hardware is local to the microcontroller

Pattern Discussion

Here are several patterns which would be useful to microcontroller firmware.

Event Loop Pattern

An event loop is a critical component of event driven programming. The loop waits for work (such as a mouse event), and delivers that work to the appropriate component (such as a window).

Steppers need to be stepped at a specific frequency in order to move. A trivial method of driving a stepper would be to sit in a tight loop stepping the motor. What if you need to drive multiple steppers? Traditionally the additional stepper control would be integrated into a single stepper loop, creating a tight coupling between the driving logic and the attached devices.

To remedy this using the Event Loop Pattern, each stepper could register for a timed callback, which would pulse each stepper. There are several benefits to this:

• each stepper could be driven at different speeds (by setting different callback rates)
• driving code for a stepper is decoupled from the other steppers in the project
• because the code is decoupled, an individual stepper could be replaced with a different device

Additionally, the Event loop could be used to drive periodic events such as servicing a serial port, checking stop conditions, managing temperature, etc.

Observable Pattern

When I first heard about this pattern, I thought ‘This has a name?’. An object which has state can be observed by one or more objects. When that state changes, the observers are notified and that state change can be acted upon. The state can change due to an interrupt firing, a polling event (during an event loop), or state being set by a another component.

There are several cases where this is interesting for microcontrollers – End stops, encoders, temperature changes, serial data available or command completion. When the state changes (like an end stop triggering), the observers are notified (An axis object observing the stop now knows it is at the extent). This can in turn fire new events (the axis object notifies the command interpreter that home has been reached).

Interface Pattern

An interface is an abstraction which generalizes a class of functionality. In C++ this is done using an abstract base class. Typically interfaces implement some form of interface discovery mechanism (like Microsoft COM’s QueryInterface) and maybe memory management (AddRef/Release). This use of this pattern will become evident in future pattern discussions.

Device Pattern

A device is something attached to the microcontroller. It can have a custom interface which more closely matches the reason for its existence, rather than how it exists.

A stepper device could expose the generic motor interface which has properties like ‘rate’ and ‘direction’, and methods like ‘stop’ and ‘start’. This motor interface could be implemented using a stepper or brushed motor, or even a linear motion device. However, an Axis mechanism need only be written to the motor interface.

Mechanism Pattern

A Mechanism is an opaque collection of devices with a custom interface for the composite mechanism. Consider a Cartesian mechanism – which is the component that the GCode interpreter is written to use. The Cartesian mechanism has an interface which includes properties like ‘rate’, and position properties like ‘x’, ‘y’, ‘z’, and maybe even spherical properties like ‘zenith’, ‘azimuth’, and ‘radius’. The cartesian mechanism could be built using 3 Axis mechanisms, or even a rotary table and longitudinal axis (although the naming breaks down; work with me here). Each axis could be implemented with different physical hardware, but exposed with the Axis interface to the Cartesian mechanism.

Behavior Pattern

A Behavior is a decision making component which responds to external input and drives mechanisms or devices. An example of a behavior would be a GCode interpreter, which listens to a serial device, and executes commands on a Cartesian mechanism and Extruder Mechanism.

Proposed Design

RepRap Design Discussion

At Startup:

During the initialization phase of the firmware, objects are created which represent each device, behavior and transport in the system. These objects are initialized with either persisted data, compiled data, or delay discover the bounds of the system. The initialized objects are then hooked into the appropriate components. Observations are made as objects are inserted into their mechanisms or applied to the behaviors.

Executing a Command:

The gcode behavior observes the serial transport. As the Event loop services the serial transport, there will come a time when an end of line is reached, and the serial port will notify its observers, then remove itself from the event loop until the line is flushed.

When the gcode behavior receives the line available event, it processes it, and acts appropriately:

If the command references the Extruder mechanism, the appropriate interface method is called; currently this means setting the desired temperature. In response to this interface call, the Extruder mechanism will register for periodic servicing from the event loop – This periodic event polls the temperature device, and adjusts the heater appropriately.

If the command is a positioning command, the gcode behavior will call the interface method on the Cartesian mechanism to instruct it to position itself to a specific point. The cartesian mechanism will then set the rate on each axis, and notify each axis of its intended position. This feed rate is calculated by the gcode behavior based on the maximum feed rate of the extruder and the maximum feed rates of the X-Y axes.

The gcode behavior will then flush the serial transport so that it can buffer the next command.

At this point – the serial transport, extruder and axes are independently performing their operations as the event loop is servicing them. The next command is held buffered until the gcode behavior receives the cartesian mechanism’s ‘destination complete’ notification.

When the cartesian mechanism has been notified by each axis that they have reached their destination, then it can notify the gcode behavior the cartesian mechanism has finished its command, allowing the gcode to service the next command if available.

When the position of an Axis is not at the destination location, it sets the motor direction and instructs it to ‘move’ at a certain speed. If the axis is built using stepper motors, the motor device registers for periodic notifications from the event loop, the period is defined by the feed rate and stepper configuration. During each trigger from the event loop, it will step the motor.

The End stops are an interesting device. This device could be implemented with an interrupt or poll using a periodic event on the event loop. In either case, when the end stop triggers, observers are notified – in this case the axis. In response, the axis will pause the motor and notify its observers of an ‘axis end reached’ event.

Switching it up

While this may seem like tons of overhead, the benefit comes from the ability to switch out portions of code for new mechanisms or devices which conform to the interface.

The Axis mechanism could be augmented with a position sensing device (like an encoder), which enhances the accuracy of the axis, but is an independent improvement that does not fundamentally change the interface or require changes elsewhere in the code base.

The Axis mechanism could be completely redesigned with a linear actuator – an independent improvement which negates the need for the majority of the devices of a traditional axis, but does not require changes to other parts of the code base.

Similarly, an Extruder may be implemented using an brushed motor, a stepper motor, or linear actuator. Since it is up to the device implementation to conform to the interface, the extruder mechanism need not manually manage the details of the motor itself.

Off Chip

One benefit of using the interface pattern, is that the interface implementation can be local to the microcontroller, but the device implementation can live off chip. With the event driven design as recommended here, the interface can communicate asynchronously with the off chip devices without disturbing other components in the system.

Next Steps

I’m currently building the support systems and generic pattern implementations for the Wiring, which is independent of the RepRap code base. I’m building a suite of tests which verify the implementation, as well as emulating portions of the Wiring APIs. I’ll check these into my user area in the RepRap source tree. I’ll continue to post portions of the code as they come online – First the Dynamic array implementation, then the event loop with timers and callbacks, then device abstraction, and finally the RepRap refactor.

When I began working on an extruder, I spent quite a bit of time working on a screw based drive, attempting to engage the plastic in order to push it into the heater barrel. Turns out – plastic is slippery. I’ve seen lots of problems with screw based extruders, so I looked into using a pinch pulley. It works beautifully!

There are a few nice side effects of the pulley – The extruder is very simple, doesn’t require much fabrication, and can be reversed instantly to stop plastic extrusion (there are no plastic fuzzies). Unfortunately, since I use a stepper, this extruder cannot be directly used by the reprap firmware without modification. I’m currently refactoring the reprap firmware to enable device abstraction which will allow either a stepper or dc motor.

Hercules Extruder

Download Sketchup

The heating element is 8 inches of insulated nichrome wire, purchased from RepRap Research Foundation wrapped around an 1/8 inch brass plug. The brass plug was turned to a point (or filed to a pyramid). A .01″ hole was drilled in the tip (very carefully!). The brass plug is threaded using a 1/4″-28 pitch tap. (The brass plugs from home depot are hollow, so it is easy to tap; otherwise it needs to be drilled out).

This is a previous implementation with a brass coupler. The extra brass was acting as a heat sink which was causing problems keeping the extruder up to temperature.

The extension barrel is a 0.375″ OD x 0.12″ WALL x 0.135″ ID T-316 stainless steel tube from Online Metals. Half inch of the tube was turned down and threaded to mate with the heater element. I’ve been asked what the resulting heating characteristics are of the new barrel – I’m happy to say that the brass element holds temperature well, and the stainless does not conduct much heat (the top barely tops out at 115F)

The Sketchup presented differs slightly from the implemented extruder. This was simply due to resource limitations (material on hand). The Sketchup includes a better mounting bracket for the heater barrel and uses a single piece of aluminum for the mounting wall.

Herk? Before my father retired from the Air force, he flew a C-130 transport nicknamed Hercules. He currently uses the name “Herk” as his handle in various games. I named the extruder for him as a small form of thanks.

Adrian Bowyer is the father of RepRap. Here’s a presentation he did about the RepRap and its potential.

Check it out:

There are 4 stepper motors on the 3d printer: one for each axis and another for the extruder. I wanted to user a motor that could be powered with a computer power supply, was under 750ma (A3967 compatible), had a small step angle and maximized the torque. I evaluated many (too many) options, but settled on the 162027 from Jameco:

This motor is 600ma, is compatible with the A3967, has a .25″ spindle which fits without modification the sprockets from electric goldmine, and has plenty of torque to handle the

                  

RepRap uses a toothed belt which engages plastic pulleys. The toothed belt and pulleys are fairly expensive and require precision gluing. I was intrigued by the idea of using ‘ball chain’ and am considering milling custom sprockets eventually. In the mean time, Electronics Goldmine has rollerchain and sprockets for very cheap – $1.25 per sprocket, and $2.50 for 23″ of mini-chain. I used 9 Sprockets and 5 sets of roller chain. They are fairly quiet and you can’t really beat the price.

SparkFun.com sells a stepper driver based on the Allegro A3967. This chip is a microstepping stepper driver capable of driving a stepper up to 750ma. It requires lots of tuning to drive the stepper correctly (varying parameters such as step frequency, current limiting via a pot, etc). It is also subject to motor noise.
I’ve been working with Zach on from the RepRap research foundation on a higher power stepper driver based on the A3977 which will drive 2.5a and is dip switch configurable for full step or microstep. You can follow the project on SorceForge. Until that project is completed and available, this combo seems suitable for light duty FDM extrusion.

I remember the day the new font rasterizer was turned on in Safari for Windows. I couldn’t believe my eyes; something was wrong with text rendering. I was caught off guard when my manager said “Its supposed to look like that”. I had to prove the others that this was wrong, so I fired up Safari on the Mac, took screenshots, loaded them in Photoshop – only to discover they were the same. How could this be?

The reason I was shocked was because it didn’t look like Windows. After about a day of use, the shock wore off, I decided I liked the the new text rendering better.

The Antigrain team recently ran an article about their Font rasterization research. It is totally is worth the read.

Over at the Rogue Amoeba blog, there’s a fantastic article about the “Delicious generation”. The moniker refering to a generation of application developers that are using the successes of  Delicious Library as a template for their own success. The author argues that these applications choose style over substance.

Is he right? Given the choice between two equality capable software products, the one that looks the best will win – every time.

But what if the software that looks the best is less capable?  For example, compare Apple’s Pages product with Microsoft Word 2004. Pages really is a pretty application, well laid out and very easy to use. Compared to Word, Pages simply is less capable – it has fewer features and lacks document compatibility. Yet I choose Pages for every new document I write.

When writing an application, a developer should strive to balance Style and Substance. Eye candy by itself serves to “tickle the user’s brain” as Furrygoat puts it. It can be used to enhance the experience; giving the users the “I rule” feeling. The application must function as expected, be stable, and be responsive otherwise the user gets the “This sucks” feeling.
Style is as important as Substance.