Nov 022014

The Innovation First VEX line of robotic components consists of a wide range of structural, sensing, and motion actuating elements. All of these sensing and actuating components are driven by the one and only control component, the Vex Cortex.

The Vex Cortex is the controller, or the brains, for a VEX robot. The Vex Cortex sports an ARM processor for user programs, 8 12 bit analog inputs, 12 digital input output ports, 2 UART ports, a single I2C port, 8 3 wire RC servo motor compatible outputs, and 2 H-Bridge 2 wire DC motor driver ports.


Today we’re going to walk through the first part of a tear down of the Cortex controller. The reason we’re doing a tear down is that as nice as the Cortex is it suffers from at least one well known weakness, the built in H-Bridge motor driver ports are undersized and prone to burn out under normal use.

The 8 RC style motor drivers rely on external plug-in H-Bridge motor drivers. If a motors stalls or over currents the external bridge can burn out but it is easily replaced. If the built in H-Bridge drivers burn out the Cortex is permanently damaged. Innovation First, the makers of the VEX Robotics line, including the Cortex, will disavow all responsibility after the warranty period runs out. Even if, in my opinion, the weak design of the internal motor drivers is the root cause of the failure.

VEX Forum\Official Technical Support\Cortex started smoking

VEX Forum\Official Technical Support\Possible Cortex Motor Controller Burn-Out?

With the right tools the internal H-Bridges can be replaced and the Cortex brought back to full functionality. The repair of the motor drivers will be covered in another post.

Keep in mind that opening the Cortex probably voids your warranty, and modifying the Cortex surely makes it ineligible for competition. Given that caveat, here we go.

Disassembling the Cortex is straightforward, flip the Cortex on it’s back and you will see four philips tip screws, one in each corner.


After removing the four screws gently pry apart the front and back covers. The circuit board will likely stay with the back of the housing with the front cover lifting off easily.



With the top off of the Cortex the main circuit board is exposed.


After removing the top gently pry the circuit board off of the bottom part of the housing. The circuit board is just wedged into tabs on the bottom of the housing and is not fixed in place.


The Cortex has two thermal overload breakers inline with the motor control circuits. If the motors draw too much current the breakers overheat and reduce current to the motors, effectively putting the motors, and your robot, out of action until the breakers cool down. The breakers serve to protect the Cortex but pose a serious issue in a competition. The breakers take up to tens of minutes to cool down, effectively putting your robot out of the match you are in and potentially out of the next match as well depending on how fast and furious the matches are coming.


The major components of the Cortex are shown below.


The main system processor that controls the Cortex is an NXP LPC2458FET180.


From the NXP website for the LPC2458.

"The LPC2458 microcontroller is ideal for multi-purpose communication applications. It incorporates a 10/100 Ethernet Media Access Controller (MAC), a USB full-speed Device/Host/OTG Controller with 4 kB of endpoint RAM, four UARTs, two Controller Area Network (CAN) channels, an SPI interface, two Synchronous Serial Ports (SSP), three I²C interfaces, and an I²S interface. Supporting this collection of serial communications interfaces are the following feature components; an on-chip 4 MHz internal precision oscillator, 98 kB of total RAM consisting of 64 kB of local SRAM, 16 kB SRAM for Ethernet, 16 kB SRAM for general purpose DMA, 2 kB of battery powered SRAM, and an External Memory Controller (EMC). These features make this device optimally suited for communication gateways and protocol converters. Complementing the many serial communication controllers, versatile clocking capabilities, and memory features are various 32-bit timers, an improved 10-bit ADC, 10-bit DAC, two PWM units, four external interrupt pins, and up to 136 fast GPIO lines. The LPC2458 connects 64 of the GPIO pins to the hardware based Vector Interrupt Controller (VIC) that means these external inputs can generate edge-triggered interrupts"

The datasheet for the LPC2458 is here.

The system processor runs the Cortex system firmware, as opposed to the user uploaded robot control program. The system processor manages the wireless link and the bulk of the communication with the joystick.

The user processor, the processor that runs the user uploaded code, is a STMicroelectronics STM32F103 ARM Cortex-M0 processor.


From the STM32F103 datasheet:

"Medium-density performance line ARM-based 32-bit MCU with 64 or 128 KB Flash, USB, CAN, 7 timers, 2 ADCs, 9 communication interfaces including up to 2 x I2C interfaces, up to 3 USARTs, up to 2 SPIs, a CAN interface, and a USB 2.0 full-speed interface."

Four particularly interesting chips are the drivers for the internal H-Bridge motor drivers. The internal motor drivers form an H-Bridge consisting of an International Rectifier IRF8313PbF HEXFET Power MOSFET coupled with a Fairchild FDS4935BZ Dual 30 Volt P-Channel PowerTrench MOSFET.



The top half of the H-Bridge motor drivers are found on the bottom side of the circuit board.



The Top Half / Bottom Half nomenclature of the H-Bridge comes from the way H-Bridge circuits are typically drawn. The positive voltage to motor control FETs (P-Channel) are typically drawn above (nearer the top of the drawing) and the motor to ground control FETs (N-Channel) are typically drawn near the bottom of the drawing, top half, bottom half.


That pretty much wraps up the interesting chips. The VEX Cortex controller is not a particularly complex board but it is almost all surface mount components which makes it just this side of impossible for most robotics clubs to work on when it fails. At $250 USD each burning up a Cortex is not a cheap proposition.

In an upcoming post we will cover how to replace the motor driver FETs when motor ports 1 and 10 fail.

Nov 012014

One of our favorite meals is a vegetarian vegetable curry soup over rice, with or without grilled chicken. We like this curry for multiple reasons; first it is delicious, second, it lets us use up vegetables that are on the brink, and third, it freezes well and lets us pop out a dinner on very short notice.

When we first started making this curry we would make a standard soup pot full, about enough for a dinner and maybe a left over. Once we discovered how much we liked it we started making bigger and bigger pots. Now we are using our big canning pot and making about three and a half gallons at a time. This soup freezes well and heats up to a quick and delicious dinner.

The soup is mostly a mix of vegetables and fruit, curry spices, and coconut milk. The flavor is a mix of sweet, spicy, and creamy. We usually pick a mix of vegetables and fruit that end up being sweet when tasted alone, then we add enough curry to give it a bite, and then mix in coconut milk to give it a delicious creamy flavor.

In our curry we usually start with a base of onion, cauliflower, carrots, and apples. Then we mix in whatever extra vegetables we have in the crisper that we want to use up before they go bad. Historically we have tried adding peppers, spinach, broccoli, kohlrabi, cabbage, and pears. The recipe is not exact, use what you have, or keep it simple if you want a simpler taste.









Step one is to wash, sort, and trim the produce. I usually wash all of the vegetables and fruit, then I trim off the ends and any bad spots. I core the fruit and toss out any obviously bad leaves or stems. I usually leave the skins on and cook them into the soup. I do not add in the greens from the vegetables.

Step two is to dice up the produce, mostly just to have it pack in tighter and cook quicker.









Step three, add all of the chopped fruit and vegetables into an appropriately sized pot and add water to just under the level of the produce.







Step four, boil the produce for anywhere from a half an hour to an hour and a half depending on the quantity and mix of vegetables. Soups heavy on carrots and other root vegetables will likely need to boil a bit longer. Test the softness of the vegetables every ten minutes or so after the first half hour to get a feel for the progress. You should be able to easily stick a fork into the produce when it is cooked.




Once everything is nice and soft it is time to blend it. Turn down the heat from high to a mid range temperature. You want the soup to stay hot and continue to simmer but not to fully boil.

To blend the soup you MUST use an immersion blender. Do not try to use a mixer or counter top blender. You are working with a pot of boiling hot vegetable paste. You really need to keep all of the hot soup in the pot and bring the mixer to the pot, not the other way round. I happen to use a Kitchenaid Variable Speed Immersion Blender. I like the extra length, the metal construction, and the variable speed. We used to use a simple all plastic immersion blender when we were making smaller pots of soup but the larger batches really need the extra length of a bigger blender.





The soup will start out chunky and lumpy but will eventually blend down smooth.



Once the soup is blended you can taste it to see where it stands. We typically add in a pinch of salt to get the flavors to pop.

At this point the soup is probably very vegetable, or possibly apple, tasting and is probably a bit on the sweet side. Between the carrots and the apples the base has a very sweet natural flavor. Now you are ready to add the curry. We use a curry paste we buy at our local Asian market. You should be able to find a bunch of different flavors. We tend to like the Red Curry Paste best with Masman or Panang next. Once you’ve opened the paste you need to store it in the refrigerator. This step, the adding of the curry, is a very personal thing. Add in a little bit of curry at a time, maybe a tablespoon at a time depending on the size of your batch of soup, and mix it thoroughly into the still simmering soup. Use the immersion blender to make sure the curry is well dispersed. Keep adding curry until you get the bite you want. The three and half gallon batch we just made took almost a full cup of curry paste. Remember you will be adding coconut milk which will mellow the flavor. I like to go a bit on spicier side and then mellow it out with the coconut milk. Be careful though, it is easy to let the curry get away from you and make a batch with a bit too much bite.



As you mix in the curry taste as you go. Add curry until the soup has the bite you want. Besides the coconut milk keep in mind what you will be serving the soup with. If you are putting the soup over rice the rice will also act to buffer the spice.

After the soup is spiced to taste turn off the heat. We are about to add the coconut milk and you don’t want to cook the coconut milk. You want the coconut milk to melt into the hot soup but you don’t want to over heat the milk. Again, turn the heat off under the soup and then add the coconut milk. The amount of coconut milk will depend on the size of your batch of soup and your taste.


After the coconut milk is mixed in the soup is ready. If you just made enough for one meal your dinner is ready, serve and enjoy. If you made extra let it cool and freeze it in appropriately sized batches. When you need a quick dinner grab out a frozen batch of soup, put it in pot to heat while you make the rice. If you make long cook rice your soup should be hot about the time your rice is done. You can have a hot delicious meal in about a half hour.



Here is the recipe. Remember this soup is done to taste. Add in more or less curry and more or less coconut milk depending on your taste. Pick vegetables and fruit that you like or have handy.

Our soup:
1 to 2 heads of cauliflower
5 to 12 carrots
5 to 24 apples
1/4 to 1 sweet onion

Optional vegetables and fruit:
other readily available produce to your taste

Wash, trim, and chop the produce.
Add the produce to a pot, add water and bring to a boil.
Boil the produce until soft to a fork.
Blend the produce using a hand immersion blender until smooth and well blended.
Add a pinch of salt to taste.
Blend in curry paste a little at a time to taste.
Remove from heat.
Stir in coconut milk until well mixed. Add coconut milk to taste.

Mar 242014

I have two 3D printers, both are the FDM types that squirt out plastic filament and build up an object layer by layer. My first printer is MendelMax 2.0 cartesian printer I built from a kit a couple years ago and the second is a RostockMax delta style printer I’m in the process of building.

The MendelMax has been a good printer but I’ve always had mixed results. I get good prints one time and horrible prints the next. I built the printer on a table in the family room, so I could work on the printer but still be around the family, and did all of my test and tuning prints sitting on the same table. Results were consistently inconsistent. Eventually I got frustrated, and tired of having the printer sitting in the family room so I moved it downstairs to my workroom. My workroom is a bunker style room in the basement with no windows, no vents, and only one door. I immediately noticed a huge improvement in print consistency. Prints might have errors but the errors were repeatable and reproducible. The number of errors were significantly smaller when printing in the basement than in the family room and the errors were consistent. It finally occurred to me that being in the family room the print nozzle and print surface was subject to the whims of breezes and temperature changes that come with people entering and exiting the room, windows and doors being opened and closed, uncontrolled variations that changed the print quality every time the environment changed. Being in the “bunker” in the basement the environment was mostly stable and undisturbed. With no windows or vents and only one door the basement room is a pretty consistent temperature and there are very few random breezes. A more stable environment led to more stable printing.

After moving the printer to the basement I could finally get consistent prints, not error free prints, but repeatable prints. When I did have a recipe for an error free print I could print the same object again and again and finally expect the same results. Yahoo! Life is good! But, you know the old saying, if you give a mouse a cookie…. Anyhow, now that the major obstacle was overcome, just being able to get a repeatable print, it was time to start looking at secondary failures.

The next biggest class of failures I experience are the saggys. Saggy prints, bridging that droops, overhangs that fall and loop, glooping and bumps, all failures indicative of printing too fast, that is, not letting the material cool before trying to lay down another layer.

Here are some images of the Pink Panther Woman printed with one or two perimeters, in ABS with 0 to 40% infill. Mostly with one perimeter and 0% infill.


You can see multiple places in my prints where the filament sags and droops when trying to print an overhang.






I found that if I print really slow, like really really slow, I could get a great print. The nozzle takes so long to traverse the print the previous layer had time to cool before being visited by the printhead again. This worked but the print time was increased by a factor of 3 to 10. That was clearly unacceptable.

The next solution was to add a print cooling fan. The kit I bought was the MendelMax from I have been super happy with the kit, it is well made, well supported, and super complete. All of the parts needed to assemble the kit, plus extras was included. A nice organizing case was provided for the screws and small parts. Cables came pre-terminated. I had to do a little soldering but for the most part the kit was plug and play. A very clean build and with what seem to be quality parts. I’ve not had a bit of trouble with the printer to date.

One thing the kit did not ship with was a fan duct for filament cooling at the printhead. It did ship with the fans, RRD Fan Extender, and cables to add up to two filament cooling fans, but no fan duct.

The first step in figuring out how to add a fan was deciding if my software and electronics could support an extruder fan. I’m running Marlin as the printer firmware so a quick google search confirmed Marlin’s support for an extruder fan. Now how about the electronics. The printer is driven by a RAMPS 1.4 on top of an Arduino Mega clone with Pololu style stepper drivers. All in all a good electronics platform but it turns out the RAMPS 1.4 out of the box does not support an extruder fan as a standard option. Some might take issue with this last statement given the unused D9 port, but D9 was intended for a second extruder, not an extruder fan.

In order to drive a fan a high power output is required, higher than can be driven by the bare io pins from the Arduino. The RAMPS board provides three high power outputs, D8, D9, and D10.


D10 is used to power the heater on extruder 1, D8 is used for the hot bed, and D9 is intended for extruder 2. On a single extruder printer D9 is unused, and therefore could be used to power and control an extruder fan, and indeed there are multiple internet responses supporting doing just that, wiring a fan into D9. So indeed it is reasonable to say that the RAMPS board supports an extruder fan out of the box…. assuming you never want to add a second extruder. For those who think they might want to have a second extruder D9 is off limits and another solution is required.

Obviously I’m not the first guy to want dual extruders AND extruder cooling fans on the RAMPS electronics. To satisfy the limitation in the RAMPS board of no high power outputs for extruder fans some enterprising souls created the RRD Fan Extender board. The RRD board mounts directly onto the RAMPS board and adds two channels of mosfet controlled power output. These two channels are not nearly the current capacity of D8, D9, and D10, but are more than enough for running a fan. The RRD board is able to take input power from 5V or 12V so it can support 5 or 12 volt fans. The RRD board has two channels of output supporting two extruder fans for dual extruder setups.

Something to keep in mind when buying a RRD Fan Extender. The servo port brings out pins D11, D6, D5, and D4. Some RRD boards bring D11 and D6 out to drive the two fan mosfets and some RRD boards bring D4 and D5 out to the mosfets. You need to check which RRD board you have because the printer firmware, Marlin in my case, needs to be configured properly to tell it which pins the fans are on.

If your RRD board uses pins D4 and D5 no software changes are required because the stock Marlin configuration for a RAMPS 1.4 (motherboard 34) is already configured to use D4 as the extruder fan 1 control. If your RRD board uses D11 and D6 you will need to edit pins.h and change your FAN_PIN assignment.

Like I mentioned above, the 3DPrinterTek kit shipped with a RRD, multiple fans, and all of the cabling required, but no fan duct. Not really a big deal, there are plenty of fan duct models out there, just download one, print it, and wa-la, instant extruder cooling.

Step one was find a fan duct compatible with my printer. A quick search of Thingiverse turned up this duct for a MendelMax.


I printed the duct, mounted a fan to the duct with 3mm screws and nuts, zip tied the duct to the print carriage, and wired it up. The RRD mounts onto the servos port of the RAMPS and power is jumpered from either the 5V or 12V aux power. My fans are 12 volt so I jumpered to the 12V aux power pins.


The RRD supports up to two fans but I’m only using one so I only have one of the outputs cabled.

Here is the printed fan duct zipped tied to the printer carriage.





Notice the fan only points at the back of the print so I expect I may still have problems with the front side of the print.

With the fan duct installed, the RRD on the RAMPS servo port, and Marlin configured to use pin 4 as the FAN_PIN I ran a test with the same model.



Notice the sagging on the back of the butt is nearly gone and the sagging on the upper back is completely gone. The quality of the prints, at least from the back, has jumped tremendously. The next step is to either get a fan pointed at the front of the print or print a wrap around cooling duct.

Maybe like this wrap around fan duct.


Feb 282014

Progress is being made on the hardware. The motors are mounted, the EggBot controller board is mounted, new spools are printed and installed.

Here is the overall mounting scheme so far


I ended up printing these small spools from thingiverse.


I used a screw specifically made for screwing into plastic. It has deep coarse threads that bite well into the soft ABS plastic. We’ll see if it holds long term but it seems to have a good grip right now.

The EggBot board has an issue where the upper and lower copper planes are one power and one ground. The problem is the mounting holes do not have copper pull backs so if you put a metal screw or stand off through the mounting holes the power plane and ground planes are shorted together. So that’s no good. Mounting the EggBot board requires using non conducting mounting hardware. I decided to print a mounting platform and hold downs.

I printed reliefs in the mounting platform for the pins that protrude from the bottom of the EggBot board. The four pins in the corners go through the EggBot board mounting holes to align the board and keep it in place when held down.






I’ve done some simple tests communicating with the EggBot board and moving the motors, making sure everything is still in working order and nothing got crimped or crushed.

Next steps are to string the gondola and get some code working.

Feb 282014

I’ve combed through enough of Wilba’s code to understand the fundamentals. I’ve done some cleanup and added comments and a bit of debugging functionality. I’ve uploaded the latest updates to github.

Searching the web for drawbot stuff I came across a post by Wilba on XKCD’s forum with some pictures and comments describing his drawbot geometry. This was a big help when trying to understand the code.

Wilba’s drawbot code supports using a larger spool and calculating the tangent point of the cord from the spool when calculating the pen position. The drawbot I’m making is much simpler. I’m using fishing line through an eyelet which fixes the cord origin regardless of the spool diameter or angle to the pen. Using a string around a spool does have the issue of the spool diameter changing due to wrap up of the string around the spool, but I’m using fishing line on a reasonably sized spool so the diameter change should be small.

At this point I’m going to fork the code from DrawbotWilba to DrawbotOne. DrawbotOne will be simpler to start with since it will only support the cord entering the drawing space from a fixed point at the eyelet.

Feb 212014

I’ve taken Wilba6582’s eggbot drawbot code and cleaned it up enough to build under Processing 2.0. It requires grabbing the latest controlP5 library and I’ve removed the gamepad control.

I haven’t tried running it against an EiBotBoard yet but that’s the next step. The code builds and runs, it rasterizes an image, and brings up a gui with the ability to drag the pen around.

I’m in the process of organizing and cleaning up the code and I’ll continue to push changes to github.

We’ll see where this goes but it gives a nice starting point for jumping off, a big thanks to Wilba6582 for doing the initial work.

Here’s the interface up and running from the barely modified code.


Feb 182014

I mentioned in an earlier post I had found a video on youtube of someone else using an EggBotBoard to drive a drawbot. That was pretty exciting because most of the drawbots out there (and maybe we’ll find later for good reason) are based on the Arduino / Adafruit motor shield combo. Since I decided to use the EggBotBoard it was good to find a kindred spirit that had already blazed a trail.

I left a comment on the video asking about what software was used and Wilba6582 responded and sent me a bit of code. I’ve just started to look at the code but from Wilba’s comments in the email he sent the code is targeted for the Processing environment and as shown in the video actually parses a file and drives the drawbot.

I’m posting the code here along with Wilba’s release. As I dig more into the code I’ll decide how much can be used as is, how much needs to be updated, and how much needs to be re-written wholesale. Part of my problem is that I’m not fully familiar with the Processing environment so I’ll need to take a moment or two to figure that out.

In the meantime I’m working on mounting the motors and electronics on a portable rigid surface (think piece of wood) so I can place the whole package above the surface I want to draw on, plug it in, and draw away.

Feb 172014

As mentioned in an earlier post I have decided to use the Eggbot control board (EiBotBoard) to drive my drawbot. I’ve gotten the electronics up and running, mostly just plug it in, screw down the stepper motor wires, and plug in the pen lift servo motor. Here are some videos of the EiBotBoard in action.

Some commentary on why I am using the EiBotBoard. The EiBotBoard is a nicely integrated dual stepper motor, multi servo motor driver that accepts high level motion commands over USB from a serial console.

Description of the motors selected for the drawbot. A couple NEMA 17 stepper motors I had laying around in my parts box. They are 0.8 amp motors, well within the 1.25 amps the EiBotBoard can supply.

Motion demo of the EiBotBoard driving two steppers and a pen lift servo. The script that is running is posted below. I am using a cygwin command window to echo the commands to the USB virtual comm port. Keep in mind Windows enumerates the COM ports starting at 1 and cygwin enumerates /dev/ttySxx starting at 0. In the script below I am echoing to ttyS18 because Windows enumerated the COM port at COM19.

Finally more commentary on why I like using the EiBotBoard.

Commands running in a cygwin shell script. Script with comments below.
echo "v" > /dev/ttyS18
echo "sm,500,500,500" > /dev/ttyS18
echo "sc,4,6000" > /dev/ttyS18
echo "sc,5,26000" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "tp" > /dev/ttyS18
sleep 1
echo "em,3,3" > /dev/ttyS18
echo "sm,1000,2000,2000" > /dev/ttyS18
sleep 1
echo "sm,1000,-2000,2000" > /dev/ttyS18
sleep 1
echo "sm,1000,2000,-2000" > /dev/ttyS18
sleep 1
echo "sm,1000,-2000,2000" > /dev/ttyS18
sleep 1
echo "sm,1000,2000,-2000" > /dev/ttyS18
sleep 1
echo "sm,1000,-2000,2000" > /dev/ttyS18
sleep 1
echo "em,0,0" > /dev/ttyS18

Send the version command to the board, establishes communication with the board.
echo “v” > /dev/ttyS18

Move both steppers at 1/16 size steps (the default) for 500 steps each and take 1/2 second to move (500 msecs)
echo “sm,500,500,500” > /dev/ttyS18

Set the pen lift servo min and max values, 6000 and 26000, determined from experimenting with this servo
echo “sc,4,6000” > /dev/ttyS18
echo “sc,5,26000” > /dev/ttyS18

Each TP command toggles the pen position from up or down
echo “tp” > /dev/ttyS18

Set the stepper fraction to 1/4 sized steps.
echo “em,3,3” > /dev/ttyS18

Step the motors for sm, duration in msecs, number of steps motor1, number of steps motor2
echo “sm,1000,2000,2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18
echo “sm,1000,2000,-2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18
echo “sm,1000,2000,-2000” > /dev/ttyS18
echo “sm,1000,-2000,2000” > /dev/ttyS18

Disable the motor drivers to avoid over heating the motors.
echo “em,0,0” > /dev/ttyS18

Feb 092014

Not a huge amount of progress on my drawbot but I’ve stumbled across a couple interesting ideas I want to capture as part of this build stream.

I have printed a gondola and a couple spools. I printed this gondola and it looks good.



It holds a sharpie marker great, tight with just the right amount of tip poking out. It has good mount points for the cords and a place to put some weights on the bottom. The problem is, and I didn’t think about it before printing it, there isn’t a way to mount a pen lifter servo. I could probably rig something up that would work fine, but I’d rather have a designed in solution. So I’ll likely be printing a new gondola soon. This gondola will probably work fine for a TSP single line art but I want a pen lifter so I can do pointillist style images.

I also printed out some spools, the ones I mentioned in my earlier post, the ones makerblock recommended I shouldn’t use. They printed fine and I think I can glue them together to avoid the coming apart and unspooling problem. But they aren’t ideal, for a lot of the reasons makerblock pointed out. They press fit onto the motor shaft, no set screw, they are kinda narrow so you get cord build up changing the spool diameter. They looked good on paper but after printing and holding them in my hand I can see some of the issues makerblock pointed out. So I’ll be printing new spools.



On to the interesting part. I found a link on youtube to a guy who made a drawbot using the Eggbot hardware. So far I haven’t found any more details but at least someone tried, and succeeded, at this before.

Second, and I think more cool. I stumbled across a video for building a drawbot on the cheap. This guy uses some super cheap stepper motors, less than $5 USD each with motor drivers, simple 3D printed spools, and cup hooks for cord guides. No motor mounts, he just screws through the motor mounting tab into the wood drawing surface. Doing a quick BOM using the cheap motors and drivers, a super simple bare bones arduino clone, 3D printed spools, cup hooks or eyelets for guides, a cheap wall wart power supply, and a hand made or 3D printed gondola I think you could make a drawbot for less than $50 UDS, maybe less than $35 with some searching.

To me this is a super exciting way to introduce robotics to newbies. The drawbot itself is cool, people just seem to like watching the drawing appear physically. The cost is pretty cheap, it seems within the range of a learning or science project, and it’s super simple to build. I think a high school or middle schooler could easily assemble a simple drawbot in a day. Build up some kits and sponsor a build a drawbot day at your local school.

Drawing board, melamine coated shelf board from HD
Stepper motors with drivers
A cheap arduino clone, preferably already assembled to avoid soldering
Cables and wiring harness, preferably already assembled for plug and play
3D printed spools and gondola
Cup hooks and screws
Some fishing line
A sharpie marker

The software would need to be developed to drive it but that problem is being worked. I think this is a cool idea that could be pretty interesting for young wanna-be nerdlings.

Search DealExtreme for stepper motors, I’ve found some motors with drivers for less than $4 USD each.

Feb 032014

I built my 3D printer from a kit a couple years ago. It is a MendelMax style and it came with a modified version of Marlin as the firmware and printrun as the host app.

One of the first things I did after putting everything together was update the firmware to the latest version of Marlin and printrun. That was a couple years ago. New versions of both the printer firmware and host software have come and gone and I’ve largely ignored them. My printer has been working fine and no need to mess with what works.

I’m in the process of building a polar plotter and I’m using my 3D printer more heavily to create many of the parts. After using the printer to print a couple parts, and remembering many of the little irritations that always bothered me, I decided to look around and see what new firmware and host apps are available.

I tried a couple different firmwares but eventually settled back on Marlin. I forked and cloned the latest from ErikZalm, created a branch for my printer mods, updated the Configuration.h, pushed my branch back to my fork, and pushed the changes to my fork. The changes for my printer are pretty minimal but pushing them to github gives me a place to stash them off box and makes them available if anyone else finds them interesting.

I added ErikZalm’s original github repo as an upstream repo so I can continue to fetch and merge his latest changes.

Fork ErikZalm’s Marlin repo into my github – do this on github.

Clone my fork onto my desktop.
git clone

Add ErikZalm’s repo as an upstream remote.
git remote add upstream

Create and checkout a branch for my feature work (support for my MendelMax)
git checkout -b bhunting_MendelMax

Fetch and merge upstream (ErikZalm’s repo), not really needed right now since I just forked and cloned it.
git fetch upstream
git merge upstream/Marlin_v1

Push my feature branch to my repo
git push origin bhunting_MendelMax

Modify the code as needed…..

Add, commit, and push
git add Configuration.h
git commit -m"configuration changes for MendelMax 3D printer - BAH"
git push

After the mods I built the firmware using Arduino 1.5.2 and flashed it to my printer.

First off I like that the annoying beep when using the rotary encoder has been toned down. Much more palatable now. I like the new menu system. Not a lot has changed but it does look cleaner and I like the wording better. But how does it print?

I upgraded to the latest version of printrun but at the same time I wanted to try Repetier Host. Printrun seems to work fine with the latest Marlin but Repetier has a more full featured interface. Repetier provides both host side software and printer side firmware. I was unsure if Repetier Host would talk to Marlin firmware but it turns out Repetier Host is more than happy to drive the Marlin firmware. In fact the two get along just dandy.

I’ve only done one print using Repetier Host and Marlin firmware but one thing I did notice, other than the improved user interface on both the printer and host side, is my print started and completed in one pass, no hiccups or restarts. It might be an anomaly but at least it didn’t crash and burn right out of the gate. So far I’m happy and looking forward to trying more prints with this combination.