Posts Tagged makerbot

Thu Feb 24

Thing-a-Day 2011 #24 - Hershey Fonts in JS, now sized for Unicorn Plotting!

This post used to be on Posterous. I rescued my posts before Posterous shut down and am now sharing them here.

I tweaked my little Hershey Fonts in JavaScript toy a bit. Now, the SVG data that it produces is at the right size and scale to plot on a sticky note on a MakerBot Unicorn.  Save the SVG content, load it in Inkscape, and save it as .gcode using my Inkscape extension for Unicorn.

At long last, after a bunch of little thing-a-days, I can write out a sticky-note:

Belaird
Save the SVG data and open it in Inkscape:
Belaird-inkscape
And save it as G-Code for plotting on the Unicorn!
Belaird-gcode
Matt Griffin was kind enough to plot it for me on one of the Thing-O-Matics at the BotCave:
Belairicorn

... sorry for the Bel-Air... :)

You can play with it here: http://schmarty.net/hershey_js_demo/

Sat Feb 19

Thing-a-Day #19 - Cube Gears!!

This post used to be on Posterous. I rescued my posts before Posterous shut down and am now sharing them here.

Today I finished and assembled the awesome Cube Gears by Emmett from Thingiverse!

They are so much fun to turn. Printable working gears for the win!

http://www.thingiverse.com/thing:6073

Photo
Mon Feb 14

Thing-a-Day 2011 #14 - Sticky Note Tweet template for Unicorn

This post used to be on Posterous. I rescued my posts before Posterous shut down and am now sharing them here.

I’ve been toying with the idea of cool automatically generated plots for the Unicorn pen plotter. This one is an experiment in laying out a tweet for plotting on a sticky note.

It should be possible, layer, to use this as a template for creating new plots! Could be kind of fun.

Feel free to grab the file on Thingiverse.

http://www.thingiverse.com/thing:6425

Tweet

Wed Feb 9

Thing-a-Day 2011 #9 - Plots of the 2-color Baltimore Node logo!

This post used to be on Posterous. I rescued my posts before Posterous shut down and am now sharing them here.

I made this version of the Baltimore Node logo the other day in Inkscape, but wasn’t at home to test it. Here are the resulting plots on both EggBot and Unicorn!

The Unicorn version came out a little messed up due to my sizing the file wrong - the pen went off the edge of my sticky note pad and mussed everything up. I resized the plot to fit the sticky note fine, but had some pen registration issues with the now-crumpled sticky note pad. I’ll probably try this again later with some nicer stock.

New files and more detailed description over on Thingiverse.

Node-2-color-eggbot
Node-2-color-unicorn

Wed Feb 2

Thing-a-Day 2011 #2 - New features for inkscape-unicorn: pen registration and homing support

This post used to be on Posterous. I rescued my posts before Posterous shut down and am now sharing them here.

Today I made some improvements to the inkscape-unicorn plotter extension that I released yesterday.

Inkscape-unicorn-reg-and-homing

Specifically, I've added two things:

  • The option to do a pen-registration check at the beginning of each plot, taken from mifga's original.
  • The option to set where "home" is, for people who like to start their plots with the platform anywhere other than in the center.

This should help make some nice plots!

Tue Feb 1

Thing-a-Day 2011 #1 - Unicorn Pen Plotter extension for Inkscape!

This post used to be on Posterous. I rescued my posts before Posterous shut down and am now sharing them here.

I spent some time this weekend making this plugin and today went through the process of releasing it via GitHub and posting it to Thingiverse: http://www.thingiverse.com/thing:5986

Inkscape-unicorn

One problem that has often plagued users of the MakerBot Unicorn is the long and confusing chain of tools required to go from a nice vector drawing to a G-Code file that can be plotted from ReplicatorG.

mifga did an awesome tutorial that made it possible to understand the steps needed to work all of these tools, but it was obvious that something better was needed.

So, I made a mashup of scribbles.py and the Egg-Bot Driver for Inkscape to bring you the inkscape-unicorn extension for Inkscape!

Once installed, this extension allows you to save files in “MakerBot Unicorn G-Code (*.gcode)” format!

Learn more, download, and contribute at the GitHub page for this project:

https://github.com/martymcguire/inkscape-unicorn

If you’re desperate, you can also download the zip file attached to this thing, but please consider getting the latest version from GitHub. :)

Thanks to langfordw for the original Unicorn Logo used as an example on this Thing.

Sun Oct 24

Experiments with PLA 4043D

Bottle Opener made from PLA 4043D

As I said in my last update, I finally upgrade MakerBot #131 with a MK5 extruder because it reportedly works great with the new PLA 4043D.

I’ve been having fun printing with the various colors of ABS that MakerBot offers, but have always been somewhat envious of folks that have been printing successfully with PLA. I bought 5lb roll of the original 4032D that MakerBot sold, but ended up putting it on the shelf after reports from other operators that it was destroying their MK4 extruders.

Getting the new PLA printing was surprisingly easy, given the challenge of using a new extruder (which needed temperature, PID, and flow rate calibration) and it’s the first non-ABS plastic I’ve printed, so it will have different optimal printing temperatures and more.

I haven’t carefully calibrated the thermistor on my MK5, and I wasn’t sure of the right temperature to extrude PLA, so I started by setting the temperature to 180ºC and attempting to push some filament through by hand.  I raised the temperature slowly until it became easy to push through by hand, around 195ºC.  I had not yet locked down my PID settings, so I was getting some wild temperature swings.  To be safe, I set the temp to 200ºC and started printing my favorite bottle opener from Thingiverse.

It turns out the flow rate for the MK5 is a lot higher than it was for the MK4.  After putting down the raft, I was having trouble with the filament stripping inside the MK5 due to backpressure.  Still, by paying attention to the print and tightening the thumbwheel whenever the filament slipped, I was able to get a completed bottle opener.

It was then that I noticed two things:

  • The top two layers of the object sagged deep into the honeycomb fill layers below, giving a terrible finish on top.
  • PLA has no give, so there was no way that a penny would fit into the slot.  I have some nice bruises from trying to make it fit. :)
To fix the stripping and sagging problems, I figured that I should increase my Feedrate - the speed at which the platform moves to catch the extruded plastic.  I figured that a too-low Feedrate would cause some back pressure when printing the raft (leading to stripping), and would contribute to sagging overhangs.  I also guessed that the sagging is due in part to the high thermal mass of liquid PLA allowing it to sag before it cooled, so a lower extrusion temperature would let it solidify sooner, leading to less sagging.  I still use skeinforge-0006, so these settings are in “raft.csv” (various temperatures) and “speed.csv” (Feedrate), respectively.

So, some calibration prints:

Bottle opener calibration prints with PLA

Starting with my first successful print in the upper-lefthand corner, with the temp of 200ºC and a feedrate of 26.5mm/s (which was working for my MK4), I slowly lowered my temp and increased feedrate.  At 180ºC I had a failed print due to the PLA freezing up, so I am going to stick with 185ºC going forward.  Increasing the feedrate by 25% immediately solved my filament stripping problem, but still left a pretty nasty top layer.  Increasing beyond that smoothed out the top pretty well, and left clean enough slots that I could actually insert some coins, albeit dimes rather than pennies.

I may try increasing my feedrate further, but I found an odd result when going from 36.4375mm/s (slower, should have thicker walls) to 38.26mm/s (faster, should have thinner walls). Namely, they both seem like very solid objects, but the dime slid nicely into the slower-printed version using the edge of a desk, while I had to take a hammer to the faster-printed version, and actually ended up bending the dime rather than driving it into the plastic (PLA is tough stuff!).  I would have expected the opposite.

Anyway, I hope these results are useful for some folks.  I hope to improve my calibration a bit more, and trying out the MK5 with my old roll of PLA 4032D.

MakerBot #131 Gets a MK5 Plastruder!

MakerBot 131 w/ MK5 extruder and PLA 4043D

Actually, all sorts of new and exciting nonsense has happened to MakerBot #131.

I was excited to order get my MK5 Plastruder kit and join all of the cool people who have left the pinch-wheel and nichrome behind.  Unfortunately, I ran into some problems early on, and after buying some cool thermocouple parts to try calibrating everything, finally determined that I had a bad thermistor.

So, I decided to put the MK5 aside and moved on to some entirely unrelated projects.  I assembled a Cyclops 3D scanner (I need more practice, but it’s promising!), and printed a pink, printable version of the Unicorn pen plotter (with some better-than-expected results - hence the Post-It Notes all over the ‘bot).  I had generally decided that the MK4 was Good Enough, and would come back to the MK5 when it died.

That was all, of course, before the new MakerBot PLA 4043D came out.  Once I got my hands on it, I had to go for the upgrade.  So, MakerBot #131 is now running the MK5, with the new relay board mounted with the official mounting kit, and the extruder controller mounted with donutman_2000’s awesome printable mount.

Stay tuned for details about my experience with the new PLA!  I am excited.

Sun Jul 25

Automatic MakerBot Camera Pt. 4 - Updating ReplicatorG

In the previous posts in this series, I hacked up a Canon camera to take pictures with an electronic trigger, built a cable to connect the camera to my MakerBot, and hacked the MakerBot’s firmware to enable it to trigger the camera in response to commands from the controlling computer.

The final step was to hack the desktop software that controls the MakerBot - ReplicatorG.

What is ReplicatorG?

From the ReplicatorG website:

[ReplicatorG] is the software that will drive your CupCake CNC, RepRap machine, or generic CNC machine. You can give it a GCode or STL file to process, and it takes it from there. Its cross platform, easily installed, and is based on the familiar Arduino / Processing environments.

For my purposes, ReplicatorG provides two things. First, RepG is a user interface for controlling the MakerBot hardware:

Second, RepG reads G-code files describing how to build an object, and transmits them to the MakerBot over the USB:

Of course, ReplicatorG is open source, and the code is available on GitHub! So, it was simple to clone their repository and start hacking on it myself.

Camera Control via ReplicatorG

While it was relatively simple to update the extruder controller firmware to make it camera-aware, ReplicatorG is a bit more complicated. My first goal was to hack a new “Camera” checkbox into the control panel. Whenever the box was checked, the camera would take pictures. Whenever the box was unchecked, the camera would be idle.

You can find the code required for these changes in this commit on GitHub, but I will try to briefly break them down here:

  • Define a new machine. In the machines.xml.dist file, I defined an experimental MakerBot configuration named “EXPERIMENTAL - Cupcake CNC w/HBP and remote camera”. It is essentially a copy of the typical MakerBot configuration with a heated build platform, but in the <tool> definition, I also added a camera=“true” attribute.
  • Update the tool model. In ToolModel.java, I added code to represent whether the tool has an attached camera, whether the camera is activated, and how to parse the camera attribute out of machines.xml.
  • Update the machine driver model. In Driver.java, DriverBaseImplementation.java, and Sanguino3GDriver.java, I added the definitions and implementations to triggerCamera() and stopTriggeringCamera(). This is the code that actually sends the TOGGLE_CAMERA serial command to the extruder controller, which I also defined in ToolCommandCode.java.
  • Update the control panel interface. In ExtruderPanel.java, I added the code to draw a new label and checkbox named “Camera”, if the machine is configured for a camera, and to respond to check/uncheck events by calling triggerCamera() or stopTriggeringCamera().

Compiling and Running the new ReplicatorG

Compiling ReplicatorG is pretty simple, so long as you have a reasonable JDK environment and have Ant on your path. There are basically two steps:

  1. Copy machines.xml.dist tomachines.xml`.
  2. Run the proper dist-linux.sh, dist-mac.sh, or dist-windows.sh.

ReplicatorG will be compiled and packaged up into the dist/ directory in two forms: an installable package for the chosen platform, and an unpacked version that you can run directly.

Opening up my modified version of ReplicatorG, I selected the “EXPERIMENTAL - Cupcake CNC w/HBP and remote camera” profile from the Machine -> Driver menu, opened up the control panel, and was happy to see this:

After hooking up my camera to the extruder controller’s D9 port, and starting the Remote Button script on the camera, I was able to take pictures by quickly toggling the camera checkbox on and off. I could also leave the checkbox activated to make the camera take pictures continuously.

Automatic Triggering with G-codes

Being able to trigger the camera by hand is all well and good, but my goal was to take pictures automatically at the end of every layer. To do this, I needed to be able to embed camera trigger commands in the G-code for building each individual object.

Looking at the ReplicatorG G-code docs, and the (machine-specific) M-code docs, I chose two codes for working with the camera:

  • M150 - Trigger Camera
  • M151 - Stop Triggering Camera

I may have to change these in the future, as the main ReplicatorG development team claim G- and M-codes for other features, but these work for now.

Modifying ReplicatorG to accept these M-codes (GitHub commit here) was straightforward: update GCodeParser.java to recognize the codes, and call the appropriate triggerCamera() and stopTriggeringCamera() methods.

I could now construct a G-code file which, when “built” in ReplicatorG, would take a picture on demand:

M150     (trigger the camera)
G4 P700  (wait 0.7 seconds for the camera to activate)
M151     (stop triggering)
G4 P1300 (wait 1.3 seconds for the camera to finish)

Finally, it was time to edit up the G-code for the models I want to photograph.

Typically, G-code is generated by taking a 3D object in STL format and running it through the Skeinforge tool. Skeinforge is a set of Python scripts, which means it is not too difficult to insert your own code.

For now, however, I decided to make a simple hack using a Perl script I wrote called add_camera_events.pl. It works by looking for (</layer>) comments, which signal the end of a layer of printing, and inserts lines to:

  1. Move to a standard pose (X=0, Y=-45),
  2. Trigger the camera and wait for it to finish, and
  3. Move back to the original position

You can find the source for this script in the add_camera_events.pl gist. The source for all of my changes to ReplicatorG are on GitHub, in the “schmarty-camera” branch of my fork of ReplicatorG.

And with that, the computer aspect of this system was finally done!

Wrap Up

Phew! So far I’ve hacked a camera, wired it to the MakerBot, updated the MakerBot firmware to trigger it, updated ReplicatorG to trigger it, and written a script to update G-code files with camera triggers at the end of each layer.

So… does it work? You bet! Stay tuned for more examples and a breakdown video of this whole project in the final post in this series!

Fri Jul 16

Automatic MakerBot Camera Pt. 3 – Updating the MakerBot Firmware

In the previous post in this series, I figured out how to wire up my hacked Canon SD300 with CHDK. I chose to use the “D9” port on the Extruder controller board, thinking that should make the software as simple as setting pin 9 to “HIGH” for a brief time whenever I wanted to trigger the camera.

The next step was to update the software on the extruder controller so that it could activate (and deactivate) the camera, in response to commands from the motherboard.

An aside on MakerBot communications

The MakerBot electronics ecosystem is comprised of 3 parts: your computer, the MakerBot’s motherboard, and the extruder controller board. Your computer talks to the motherboard via a USB<->TTL interface (such as this FTDI cable from SparkFun). In turn, the motherboard communicates with the extruder using another serial protocol, RS-485, over an ethernet cable. Finally, the extruder triggers the camera via the custom cable I made in the previous post.

The software for all three components is available on the indomitable GitHub. The software for your computer is called ReplicatorG, and the source can be found in the MakerBot ReplicatorG GitHub repository. I’ll talk more about ReplicatorG in the next post in this series. For now, we want to focus on the MakerBot G3Firmware GitHub repository, which contains the code for the motherboard (in the SanguinoMaster subdirectory), and for the extruder (in the ArduinoSlaveExtruder directory).

Browsing through the code, we see that these components use their serial interfaces to send packets, where each command is represented by a number. The commands for the motherboard can be found in the SanguinoMaster/Commands.h, and those for the extruder can be found in ArduinoSlaveExtruder/PacketProcessor.cpp.

To send a message to the extruder - in this case, to activate or deactivate the camera - we must create a packet for the motherboard. The HOST_CMD_TOOL_QUERY code allows us to send the motherboard a packet which it will then pass along to the extruder controller.

That’s great, because it means the motherboard part of this software hack is done!

In fact, we’ve already hacked the camera, as well, so we’re halfway there!

Hacking a camera into the extruder controller

Since the motherboard already does everything we need (passes along packets from the computer to the extruder controller), we only need to update the ArduinoSlaveExtruder code.

To get this to work, I ended up changing the following files: ArduinoSlaveExtruder/Configuration.h.dist - added in configuration options for enabling the camera and setting the pin on which to activate it. ArduinoSlaveExtruder/Extruder.h - added function definitions for turning on/off the camera. ArduinoSlaveExtruder/Extruder.cpp - actually implemented turning on/off the camera. ArduinoSlaveExtruder/PacketProcessor.cpp - implemented the serial command to toggle camera.

Building and uploading

If you followed the 4 links above, you’ll notice that they go to my own G3Firmware GitHub repository. You can download it yourself to play along by cloning the repository and checking out the ECv2.3rc0-camera branch.

To build the firmware and upload it to the extruder controller, we need some common development tools (make, in this case), and the Arduino development environment. With those things installed, we can compile everything by setting the ARDUINO_HOME environment variable to the path to our Arduino install’s java directory (e.g. on OS X this would be /Applications/Arduino.app/Contents/Resources/Java/), and simply run make.

Once the firmware has been compiled, we can upload it to the extruder controller by using the USB<->TTL cable that usually connects the motherboard to our computer. Plug the cable into the extruder controller, and run the make upload command. You’ll need to make sure that ARDUINO_HOME is set, and you will probably need to alter the Makefile to specify the correct serial port, and maybe to update the call to avrdude to include the path to the Arduino avrdude config file. You can see an example of that in this commit.

Once the firmware is uploaded to the extruder controller, the MakerBot is all set to take pictures!

… Of course, we still have no way to tell the MakerBot to take a picture, so stay tuned for that information in the next update: