Reprap Visit

From Splatspace
Jump to: navigation, search
RepRap Visit Prusa Mendel.jpg




Splat Space is working on getting a 3D printer! W00t! The first step is that we are borrowing one from Neil Underwood of Fablocker (the Winston-Salem hackerspace). This came about through a series of discussions that culminated in Alan and Neil talking at the Maker Faire NC 2011 and working out the details.

The specific type of RepRap is a Prusa Mendel. Here's a cool video overview of both 3D printing and Mendel operation: OhmEye's Introduction and Orientation for 3D Printing with the Reprap Prusa Mendel.

Neil says the Prusa is one of the simplest designs, straightforward to build and maintain, and pretty robust. It's also one of the cheapest in parts and effort to build. For about $400 in parts, we could have one. Once we had one built, we could use it to print parts for more.

The Prusa that Neil loaned to us arrived in not-quite-working condition, although he has used it to successfully print in the past. So the first steps are to get it working. See #Current State section for the current state of the printer and #Day by Day section for the details of the debugging effort.

Email Threads

There have been a few e-mail threads about getting and setting up the RepRap. They are archived on the Splat Space Googlegroup:

Prusa Mendel 3d printer for space
Reprap contest?
Prusa: The Arrival
please call neil if you work on reprap

Current State

Swapped out the old filament drive bolt with a new one by JC. Need to test and check operation. Drew 12:46, 14 July 2011 (MDT)

Day by Day

Saturday 9th

Team: Alan, Drew, Skippy, and the other Jeff (add yourself as appropriate)

Sunday 10th

Team: Drew, Skippy, Mike, Lisa, Jeff

Problem: extruder not consistently extruding plastic; plastic getting stuck and gouged out by the knurled feed bolt.

Phone call to Neil Underwood.

Took apart extruder assembly and hot end, melted out plastic. (Expected to find glob of PLA from the day before. Only found ABS from today.)

Noticed that skate wheel in extruder was not mounted on an axle and was not turning. Cut off a section of smooth rod to use as an axle, took apart extruder assembly, mounted skate wheel on axle, put it all back together. Wheel turns freely now.

Flossed the teeth of the extruder knurled bolt. It was gummed up with PLA from yesterday and ABS from today. Used Jeff's dental tools for the flossing.

Changed feed rate from 300mm/min to 100mm/min. With the freely-turning skate wheel and a rate of 100mm/min, can get plastic feeding through the extruder consistently. Feed rate is about 5% off from what the software thinks it is feeding. This needs to be updated in the software.

Set the X,Y,Z limit switches again. Re-leveled the build platform (and marked the location of the feet on the table since the table is not level).

Details of the debugging session are captured at Reprap_Visit_Sunday_10th_Details.

Tweeted picture from the debugging session.

Mike 07:37, 12 July 2011 (MDT)

Monday 11th

Team: Drew

After an email exchange with Neil today found out that the length fed into the machine is based on a volume calculation done in the firmware. This was not my understanding of the machine's operation. We need to get a copy of the firmware on the machine, update it per on of the following.

Also there's an IRC channel on freenode, #reprap. I'm told that they're helpful. Drew 17:31, 11 July 2011 (MDT)

Tuesday 12th

Team: Drew, Skippy, Mike, others? (add yourself as appropriate)

Splat Space open meeting with an unusually large crowd. Not sure how much debugging Drew and Skippy managed to do early on with all the people coming by to spectate and ask questions. (Feel free to update with any details.)

The Firmware running on this Prusa is Sprinter.

Internally, Sprinter is doing volumetric measurement/calculations of the amount of plastic being extruded. Drew is annoyed (nay, angry!) that the driver software shows a linear measurement (mm/min) for the extruding rate.

Looks like the default volumetric calculation constant for Sprinter is 700. Can modify this value using the M92 G-code command. Drew and Skippy followed steps to calculate the volumetric constant and came up with 717.5 (e.g. M92 E717.5). Unfortunately, it still wasn't giving consistent feed results.

Mike and Skippy tried a test print of the 10mm calibration cube after converting the STL file to G-code using Skeinforge. The Prusa seemed to do everything right ... except extrude. The extruder stepper never moved. After walking through the G-code and translating it, it looks like Skeinforge put in feedrate (F) commands but not extrude (E) commands. We were able to get a single line extruded by manually sending the following:

G1 F100
G1 X20 E22

Looks like either Skeinforge might need to be tweaked for output that matches the Prusa/firmware or the firmware isn't correctly handling the case of only being feedrate specified.

Mike 12:18, 13 July 2011 (MDT)

Wednesday 13th

Present, really late at night: Drew, Me (J Crews)

We have a couple of options for fixing the irregular extrusion problem. On a lark I made the "alternative drive bolt" which has teeth cut into the threads of an M8 bolt. While installing that, Drew and I discovered that the idler block was installed upside-down so that A. the idler bearing was too far away from the drive bolt and B. it was rubbing on the frame and binding. -facepalm-

We have labeled it so we can't do that again. So: either the new bolt will work better, or the old bolt will work just fine with the new and correct idler bearing alignment. I believe Drew is testing this tonight. -- Jeff

Tested the new bolt and noodled about with temperature and feed settings. I'd recommend that the next person to take a crack at this, start with the PLA at a fairly low temperature (ie 180) and low speed (ie 100). If that works, ramp up the speed till we find where it stops providing consistent feeding.

On the subject of the new bolt, there's now a bit of an issue with the filament wandering back and forth across it, and this can lead to inconsistency with feeding. This explains why the original bolt was only knurled across a short segment (Jeff's replacements have large toothed sections). This issue could be solved with a constraining guide hole at the top of the extrusion assembly, and might explain why the original extruder design we're using (Wade's) was set up that way. Drew 12:42, 14 July 2011 (MDT)


Present: Skippy, J Crews

JSC had previously replaced the original drive bolt in the extruder. We decided to try to print a test cube, our reasoning being that perhaps the seeming irregularity in feed was actually not significant.

Each time we sent the Gcode to the machine, it would move Z+ for several cm, while verrrry slowly drifting X+. This is NOT in agreement with the Gcode that we were looking at. Unplugging the cable did not stop this behavior. Neither did resetting the board, nor exiting the software, powering down the printer, and trying again.