Gears

October 9th, 2008 § Comments Off on Gears § permalink

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:

Captured Gear Drive

October 7th, 2008 § 1 comment § permalink

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.

 

RepRap Arduino Firmware refactor

September 27th, 2008 § 3 comments § permalink

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.

Hercules Extruder

September 26th, 2008 § 10 comments § permalink

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

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.

Fabr at Seattle Robotics Sept 20th

September 18th, 2008 § Comments Off on Fabr at Seattle Robotics Sept 20th § permalink

Just some quick notes:

Fabr will be at the Seattle Robotics meeting on September 20th. For more information about the meeting, visit http://www.seattlerobotics.org/.

I’ve been posting updates to my twitter feed instead of posting incremental updates. You can follow me via http://twitter.com/ooeygui.

I am working on a couple of major changes to the RepRap driver software, a post about using Programming Patterns with the Arduino, and more about the Fabr extruder. Stay tuned…

Adrian Bowyer Talking about RepRap

August 18th, 2008 § Comments Off on Adrian Bowyer Talking about RepRap § permalink

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

Check it out:

Drive Components

August 10th, 2008 § 1 comment § permalink

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.

Stepper Motor Driver v2a

July 23rd, 2008 § Comments Off on Stepper Motor Driver v2a § permalink

One of the side effects of using 80/20 for the structure of a 3d printer is that it weighs significantly more than the reprap design using rods and plastic joints. I became concerned that a 600ma Stepper may not drive that much weight or overcome the friction of the linear motion bearings. I started designing the ‘super driver’ which was capable of driving up to a 2.5 amp Stepper which would easily handle those issues.

After Fabr’s appearance on Hackaday, Zach from the RepRap research foundation contacted me about collaborating; we were going down parallel paths. I deeply admire the foundation’s work, and Zach’s contributions seriously rock. Needless to say I was very enthusiastic about this collaboration.

Zach was interested to see if we could use the ‘super driver’ as the next generation stepper driver board for the RepRap, and offered suggestions for unifying the projects.

The first iteration of this collaboration has been checked into the RepRap source forge project (and the fabr subversion project will be retired). It is looking pretty sweet!

Here’s the start of the new board:

Notable Differences:

  • License changed to GPL
  • Name change (no more super driver)
  • Uses the RepRap standard IDC header for communication
  • Uses the RepRap standard power supply connector (vertical instead of horizontal)
  • Min/Max end stops route through the motor controller using Headphone Jacks (to be implemented)
  • Uses the new RepRap .156″ headers for the motor connector (similar to the ones I was using, but non-removable and less expensive)
  • Stepper mode (full/eighth) is a jumper instead of software settable
  • Opto-isolated (to be implemented)
  • SR is jumper configurable (needs the diodes to be completed)

More on 80/20

July 18th, 2008 § Comments Off on More on 80/20 § permalink

Fabr is built using the 80/20 T-Slot fractional building system. ‘New Stock’ items were purchased from the 80/20 Garage Sale on eBay. The service was excellent. Just make sure when you purchase that you wait for the invoice as they combine shipping.

The Fabr frame is a 1″ profile ‘1010’, 12 total, each 14″ in length. I paid $2.75 each, for a total of $33.

I used 8 three-way nylon connectors to complete the cube – each was $2.85, for a total of $22.80.

(Similar to these 2-way connectors; couldn’t find a 3 way image at the time of writing)

$60 or so is very reasonable for the superstructure of the printer. I’d certainly use this system again.

The ‘linear bearings’ are ‘h’ shaped extrusions with a sandwich 3 ultra-high molecular weight shims between it and the t-slot extrusion.

I assumed that these bearings would glide smoothly over the t-slot. After assembly, I discovered that the bearings were very tight which required more than an acceptable amount of force to overcome the friction.

Disappointment set in. 

I attempted some minor changes to the bearing pads in order to reduce the size. Sanding nor scraping were successful (too much fuzz was generated causing more friction). However, removing a single pad reduced the friction to acceptable levels, but the loose fit could result in a loss of precision.

The bearings themselves were very expensive compared to the other components – $34 each x 3 = $102.

I also purchased an additional extrusion for the X-Axis, connectors and t-nuts.

The total with shipping was $192.90.

If I had to do it again, I would use the 80/20 super structure, but would investigate other options before buying the bearings. It seems that from time to time, the garage sale offers a ‘build your own bearing’ which may affect the final cost, but ymmv.

(naked bearing pictured here is $8. There is also ‘overstock’ UHMW material in the bearing profile for $7 at this time.)

 

I’ve been playing around with the idea of using an ACME lead screw with a traveler which not only engages with the screw, but also uses the screw as a guide rail (2 birds one stone). This would need to be fixed at both sides using a bearing block. (sorry, just idea at this point).

Fabr is a RepRap

July 14th, 2008 § 4 comments § permalink

I became intrigued by the concept of ‘renewable manufacturing’ – owning the life-cycle of everyday things. This idealism was captured by the RepRap project; who’s tag line is ‘Wealth without money’.

In the early phases of the construction of Fabr, I ran into the classic RepStrapping problem – how do you build a device intended to be built using a 3D Printer without a 3D printer? I had attempted to use the printing services at the TechShop in Menlo Park, but was unsuccessful. After that failure, I decided to designed and build Fabr using commonly available materials and few custom parts.

Over the last year, the RepRap organization has made changes independently which amusingly coincide with some Fabr design decisions, and Fabr has changed to be more like the RepRap in order to better leverage the software and firmware from the RepRap team.

In essence, Fabr is a RepRap.

Since my last post, I’ve been working on the following parts of the project:

  • The TextMate plugin was nearly rewritten in order to remove the Processing toolchain, and require the AVR MacPack from Objective Development.
  • Using the new Mill & Lathe, I’ve improved some of the articulation points
  • Implemented a multi-screw Y axis to compensate for unacceptable racking. I wish I could say that 80/20 is an asset, but the linear motion bearings are woefully inadequate and excruciatingly expensive. 
  • I smoked my motor shield while debugging a stepper problem, and switched to using 4 EasyDrivers from SparkFun.
  • Started building a ‘Super Driver’ which can drive steppers to 2.5A, as well as software configurable Full Step or Microstepping.
  • Ported the RepRap gcode interpreter to the TextMate toolchain and adapted it for the EasyDrivers (Need to unify this work with the trunk, and submit my updates to the RepRap team).
  • Implemented a Ruby gcode uploader; hopefully to be used in the Sketchup exporter.
  • Acquired materials and Building RepRap Opto Endstops for home positioning
  • Acquired materials and Building the Temperature controller for the extruder