by makeme

Posts Tagged ‘driver’

How Low Can You Go

In Uncategorized on 20, Nov, 2011 at 14:34

When it comes to 3D printing, the most expensive part of the system is the electronics.

Makerbot wants $370 for their Gen4 electronics. With their Gen6 stepper extruder (and the driver for it) costing $165, and a set of X-Y-Z motors costing $105, that puts the complete cost of electronics at around $640. I figure this is a good upper bound on what 3D printer electronics should cost since Makerbot’s electronics are probably the most professional and full-featured. I’m not going to include a heated bed in this comparison because it’s not strictly necessary to get started, it’s just a performance upgrade.

Obviously, when there are complete 3D printer kits starting at $500, $640 for just the electronics is unacceptable for my purposes.

The confounding thing is that when you move away from Makerbot (and complete kits in general) you start to have to source from multiple vendors. There is not, as yet, a clearing house for open-source 3D printer components. Sellers tend to focus on one or two options. Additionally, they tend to be located in Europe, so that whole “You want HOW MUCH for shipping?!?” thing gets reversed.

RAMPS and Gen6 are mid-range in terms of performance flexibility and cost. So, you know, whatever. All the electronics kits I know of use pretty much (if not exactly) the same stepper drivers, and they all use USB, and these days they all have an SD-card option, so unless one of them tends to spit out errors more often they all have the same 3D printing performance. 

Sanguinololu seems to be the strongest attempt to whittle the electronics down to just the bare necessities. eMakerShop sells the whole thing (including drivers & firmware tested) for about $170 shipped, they want $95 for the motors (shipped) and $75 for the extruder (shipped). That all comes to around $340. Solidoodle sells the whole thing (without drivers) for $105 (shipped), but doesn’t sell anything else. LulzBot can make up the difference with four Pololus for $65, four motors for $75, and a 12V 25A 300W power supply for $35. They have a hot end that they want $75 for. That all comes to around $350.

There are rumors of people pushing the electronics cost even lower. For example, something called GenL offloads most of the computation to the host computer by using more USB bandwidth. Another example is Repic by Mark Feldman, but I can’t find much information about it.

As you can see, the electronics is the most expensive part of the printer and the stepper motor/driver combination is the most expensive part of the electronics. The need for four bi-polar steppers and four microstepping drivers demands $120 minimum. You might be able to get that down under $100 if you get really lucky on sales or start salvaging parts. The biggest barrier is that these particular parts can’t be made much cheaper. The Sanguinololu board can be brought down to around $60 if you buy the bare PCB, then the components, then burn the bootloader with something you already had (or maybe you can find a chip that’s already burned). But the motors and driver prices aren’t going anywhere.

Some blue-sky ideas for lowering the cost even further involve basically starting from scratch and creating a new family of electronics. The primary reason steppers are so popular is that they don’t require any feedback for accurate positioning. It’s possible that coupling a feedback mechanism (linear resistor, optical encoder, whatever) with a standard DC motor to create a servo would be cheaper. It would also be possible to simulate the entire electronics board on an FPGA for a one-chip solution; just a PCB with the FPGA, its interface, and a bunch of transistors for amplification. Maybe the motors, and their complicated drivers, could be replaced with solenoids and some clockwork. Running all the high-power functions off of AC (out of the wall) might eliminate the need for a power supply (get logic power from the USB).

Advertisements

Easy 3D Printer Toolchain

In Uncategorized on 07, Jun, 2011 at 21:32

The software that controls open source 3d printers is still in a state of flux. It can be difficult to navigate your way through all the options to try to put together a toolchain that will do what it is supposed to do. I know, I’ve been doing just that for a while now.

Eventually I figured that I was only really helping myself because I was piling one patch onto another trying to make things work in my specific situation…and it wasn’t working all that well. So, I started over.

The primary factor in deciding what toolchain to put together is the operating system your computer runs on. Normally, this would seem to be an insurmountable obstacle, but these days it’s really not that big a deal. We can standardize on one single OS by creating a bootable flash drive. I have picked Ubuntu because it’s totally free. So, if you have a 2GB flash drive, or if you can scrape up the cash to buy one, you can simply boot your computer into a brand new OS without actually changing anything about your computer. This step ensures that you are starting from a totally clean install, and that your install is the same as everyone else’s install.

From that point forward all you have to do is download Java, which is free, and Python, which is free, and Arduino, which is free, and in this case I’ve choosen ReplicatorG (best and best supported), which is also free.

But don’t worry. I’m not going to leave you to figure out how to do all that. What follows is a detailed checklist that will guide you through this process. You don’t have to know ANYTHING about ANY of those programs. If you can click buttons (and can afford a 2GB flash drive) you can get your bot up and running.*

*I am sort of assuming you’re using RAMPS and Windows, but I can’t test this process with anything else at the moment.

How to do it (this process is largely based off of this set of instructions on the RepRap Wiki by Bristolalweb)

  • You will need:
    • a computer with 2 free USB ports (one for the flash drive and one for the 3d printer) and a wired internet connection (no need to mess with getting wireless working).
    • a flash drive (at least 2 GB)
    • an Ubuntu image
      • http://www.ubuntu.com/download/ubuntu/download
      • The Ubuntu site is pretty easy to navigate.
      • Getting the Long Term Support (LTS) version is recommended. New Ubuntu releases don’t have support for everything build in; people add that stuff over time. If you get the newest version you will probably find that it doesn’t support one or more of the things you want to do. For example, when you try to use the Universal USB Installer, the newest Ubuntu release might not support a protocol necessary to let the system treat a flash drive like a hard drive. The LTS version will.
      • Make a note of the version name and number: 10.04 Lucid Lynx
    • An installer
  • plug the flash drive in to the USB port and make sure the flash drive doesn’t contain any files you want to keep
    • make a note of the drive letter that identifies the USB key
  • quick format the flash drive
    • open windows explorer
    • right click on the drive letter and select ‘format’
    • select ‘Fat32’ and ensure ‘quick format’ is checked
    • click ‘format’
  • run the Universal USB Installer
    • select the version of Linux that you downloaded
    • select the file you downloaded
    • select the letter that represents your flash drive
    • select at least 1GB of persistent memory (so that you can save things)
      • if your flash drive is larger than 2GB you can select more, but leave 1GB available for Ubuntu
    • click ‘create’
  • restart your computer (or move the flash drive to a different computer)
  • at some point before your normal operating system shows up you should have the option to select a ‘boot menu’ (or something like that). If there isn’t a clearly labeled option or menu (which won’t be available for long, so move fast) then you can try ‘delete’ ‘F10’ or ‘F12.’ If none of those work consult your documentation or customer service representative. There most definitely is a way to tell your computer to boot from the flash drive in the USB port, so don’t give up.
  • When the Ubuntu menu shows up, select ‘boot from USB’.
  • get Ubuntu universe (not a program, this just tells Ubuntu to search a wider list of programs)
    • click ‘system’
    • click ‘administration’
    • click ‘software sources’
    • check the box next to ‘universe’
  • get python and java
    • click ‘system’
    • click ‘administration’
    • click ‘synaptic package manager’
    • click ‘reload’ in the upper right of the new window
    • in the search bar enter the package names and check the box next to them when they show up
      • “python” “python-tk” “python-psyco” “openjdk-6-jdk”
    • click ‘apply’
    • 10.04 seems to have python 2.6.5 by default
    • or, from the terminal (doing it this way didn’t work correctly for me)
      • sudo apt-get install python python-tk python-psyco
      • sudo apt-get install openjdk-6-jdk
  • get arduino
    • http://arduino.cc/en/Main/Software
    • after the download, move the file from the download folder to the desktop
    • right-click on the folder and select ‘extract here’
    • back in synaptic package manager
    • search for “avr-gcc” and “avr-libc”, mark for installation
    • or, from the terminal
      • sudo apt-get install gcc-avr avr-libc
  • get Teacup firmware
    • http://reprap.org/wiki/Teacup_Firmware
    • https://github.com/triffid/Teacup_Firmware
    • download the *tar.gz file (It’s actually a folder with a lot of compressed stuff inside it, not a single file)
    • move it from the download folder to the desktop
    • extract it to the desktop
    • rename the new folder “Teacup_Firmware”
    • open that folder, copy the “config.ramps.h” file and past a new one
    • rename that new file “config.h”
    • load Teacup firmware on to RAMPS
      • open the arduino folder
      • run the file named “arduino”
      • select ‘run in terminal’
      • select ‘file’ then ‘open’
      • click the ‘-‘ button in the upper right and navigate to the desktop directory
      • double-click the ‘Teacup_Firmware’ folder
      • double-click the *.pde file
      • click ‘verify’
        • you should get an error
        • open the Teacup_Firmware folder
        • find the file called ‘makefile’ and open it
        • scroll down to the ‘change these to suit your hardware’ section
        • uncomment the mega2560 line and comment out all the others (assuming you’re using the 2560 and not the 1280). It seems like some of the files use “/” to denote comments (stuff the program ignores) and others use “#” for the same thing. It should be obvious because all the instructions will be surrounded by whatever the symbol for comments are.
      • back in the arduino window
      • click ‘tools’ ‘board’ then select the mega 2560
      • click ‘verify’ and it should compile properly
      • click ‘upload’. Not only will the Arduino IDE tell you whether or not the upload worked, you should be able to watch the LED on the RAMPS board blink an awful lot. That’s a good thing.
        • it might prompt you to try the port ttyACM0 instead of COM1, click ‘ok’
  • get replicatorG
  • connect to the 3d printer
    • open the replicatorG folder
    • run the file called ‘replicatorg’ select ‘run in terminal’
    • wait for it to finish updating itself
    • click ‘machine’ ‘driver’ and select ‘teacup’
    • click ‘machine’ ‘serial port’ and select the ‘ACM0’ port
    • click ‘connect’ and the orange bar should turn green
    • make sure the temperature is updating and jog the axes

At this point you should have a bot that is registering temperatures and responding to the control panel. That’s all for now. I’ll put together another set of instructions describing how to properly tune the bot.

Anyone who tries this out on a system other than Windows, or on electronics other than RAMPS, please let me know. I’m sure it will work with only minor tweaking.

Makerbot Thing-O-Matic Extruder Relay Fix

In Uncategorized on 23, Jan, 2011 at 19:14

As I addressed previously: the Makerbot Thing-O-Matic has a few issues. Also addressed previously: why that’s half the fun!

The best way to troubleshoot something is to find where the problem is and gradually work backwards. At each step you try to confirm that a part works the way it’s expected to work. When a part fails a test, you either fix it or bypass it and see if that solves the problem. If it doesn’t, you make a note and continue moving backwards. Of course, it’s always preferable when you can just fix the problem. Or, maybe replace a part, that’s good too.

Plan C is usually to alter the design to compensate for something that simply can’t do what you’re trying to make it do. When it comes to the Generation 4 electronics and the Kysan DC motor on the extruder (all of them) … I’m down to Plan C.

I tried replacing the old Extruder Controller (EC) circuit board with a new one that Makerbot was kind enough to RMA (thanks Ethan!). I also tried replacing the actual motor driver chip (A3949) on the old board with a new one from Digikey (no joy, also, I’m not sure how happy support was about that). The closest I got to a solution was that the totally new EC would drive the motor for a little while (the old one wouldn’t put out any voltage at all). I backed out the delrin plunger’s thumb screw on the extruder so that there was no load on the motor, and just watched the multimeter. Sometimes it would work fine (11.98v), sometimes it would try (~7v) and sometimes it would give up (80mv).

For what it’s worth, by running through this failure mode several times I was able to find that when the motor stopped turning its resistance was basically shorted out  (1.4 ohms). When it was turning fine it was resisting fine (30-45 ohms). So, I suspect that it could very well be a problem with the motor (a bad winding maybe) that’s causing a problem with the motor driver. My guess is that the motor is basically shorting out while it’s spinning, which dramatically increases the current in the circuit, triggering the A3949 to shut down. It’s probably turning back on a microsecond later, applying 12v again, and shutting down again. Repeating that over and over again is probably what produced the 7v-ish reading.

At any rate, replacing the broken part didn’t fix the problem. It merely illustrated that the new part would probably break too. Several people seem to agree that the current design is beyond fixing. Time for Plan C.

“… I’m using the motor just fine to push plastic , powered from the 12v rail of the power supply in the TOM, using a relay connected to the usual motor control to turn it on and off. There hasn’t been a single glitch in this setup.” – ScribbleJ

Instead of connecting [the EC] to the motor (which fails just as described in these posts), I connected it to a couple of relays. This works in both directions…” MakeALot

The relay kit did it for me. Motor started working perfectly.” – g00bd0g

I didn’t feel like waiting for  support to maybe send me a relay kit, so I cobbled something together from Radio Shack. I am happy to report that I just got through 20 minutes of printing without a single problem (that hasn’t happened in weeks). What I did is basically like what rwensley did, but with only one relay (forward or stop).

Parts list:

Steps:

  1. Figure out where to mount the new components. I cut a small piece off the perf board and drilled 1/8″ holes so that I could mount it in between the EC and stepper driver using the existing mounting points.
  2. Test fit the components. I then elongated the holes because I’d mounted the board too close to the edge of the bottom panel. Remember that the outside edge of the electronics are butted right up against a wall when the bot is closed.
  3. Mark the perf board. I suggest, if you mount the DIY relay board underneath the two existing circuit boards on the same bolts, that you mark it with a sharpie to show where you have room for components. Remember to connect the RJ cable.
  4. Cut the female Molex connector. I left a couple inches of wire, then stripped a half inch off of the end of each.
  5. Drill holes for the Molex connector wires. I used a 5/64″ drill bit to enlarge four of the holes (at least one hole apart).
  6. Hot glue the components in place. You don’t have to do that, but the perf board I used didn’t have any copper on it, so I wanted a better mechanical connection then just soldered wires. It doesn’t take much hot glue, tho.
  7. Wiggle everything. The idea is that things aren’t going to fall apart when you start connecting/disconnecting things and trying to stuff them inside the bottom of the bot.
  8. Wire it up. Wiring a relay is pretty straight forward. Remember to put the stripped end of the diode on the positive wire.
  9. Test it. Not strictly necessary, but it’s good to make sure you got polarities right. I plugged everything in like it was finished, except that I left the two control wires free and just hooked them up to an external 12v source. This simulated the motor controller sending 12v to the motor (actually the relay now).
  10. Connect everything and close the bottom. Yay!

TOM relay

Makerbot Extruder Mystery

In Uncategorized on 05, Jan, 2011 at 18:23

Now that I’m an established blogger 🙂 I think it’s time to tackle the elephant in the room. I’m referring, of course, to the Makerbot extruder “issues.”

I’m not claiming to have a solution, not yet, I just want to try to inject some structure into the problem solving process. There are a lot of references to this problem spread around the interwebs, most of which are speculation. I’m not much use when it comes to electronics, but I can at least compile everything into a coherent troubleshooting process … and then add my own speculation!

First, lets hear from the community:

“I’d try that, but since my last post, the extruder motor stopped spinning altogether.  can’t get it to spin in a build or in the control panel. Ugh.” – Rich

Then I was trying some raftless objects and the extruder drive died 1/2 way through my 20mm cube and I was like “WTF”?” Gabe

I am experiencing something odd with this motor as well.  I was able to complete about 3 prints without any issues.  However recently, the extruder motor stops responding in mid print.” – GodfatherUr

After Makerbot fixed the stop button bug in ReplicatorG, and after so many people reporting that their extruder motors still spin when they apply an external voltage to them, I think it’s safe to discard the theory that there is something wrong with the motors themselves. So, while that’s the thing that most obviously stops doing what we want it to, it seems like it’s just not getting what it needs from lower down in the chain.

That leaves the extruder controller (EC), the motherboard, or the power supply (PS). Lets work backwards, starting with the PS.

According to Makerbot the Thing-o-matic (TOM) ships with a “500w Hercules ATX power supply” which has slightly different specs depending on where you look (17A or 22A on +12V for example)* mine says 22A on the side. I can’t find anyone who admits to manufacturing the thing, although I did learn just how many products are called “Hercules.” So, I did what I always do … I swallowed my pride and consulted wikipedia. The Hercules claims to have over current protection, which should shut down the whole PS if something drew too much juice. Additionally, I didn’t have any trouble finding +12V at pins 8 & 9 (power and ground on the schematic), even when the motor was failing to spin, so it doesn’t look like there’s too little juice either. I followed (in as much as they apply) some troubleshooting guides like these 1, 2, 3 and didn’t find any problems. Replacing the PS seemed to work for G00bd0g but not for Ryan9. I don’t think the PS is the problem.

Ditto for the motherboard. Mostly, I just can’t think of how the motherboard COULD cause the kind of problems we’re seeing. It’s not responsible for extrusion.

The EC, on the other hand, not only controls extrusion but has its own set of firmware. Hooking the motor up to a dedicated power supply demonstrates that there’s nothing wrong with it. The very next thing in the chain is the EC or, more specifically, the A3949 motor driver. As you can see from the schematics, the motor driver connects directly to the motor, supplying everything it uses to function. More specifically, the motor driver takes in a logical signal (distinguished by two LEDs) and power from the +12v rail, then outputs a PWM signal that controls the motor’s speed by turning on and off really fast. To make a long story short, I could never find anything going wrong with anything besides the part of the circuit that connects the output of the motor driver with the motor. Ergo, I think it’s the motor driver that’s causing the problem.

My suspisions regarding this phenomenon is best explained by James, one of Allegro’s (the A3949 manufacturer) technical support reps. After I described the problems to him he replied, “The symptoms you describe are typically related to electrical overstress in the motor driver chip … One risk area is that some applications will use a connector between the motor driver and the motor.  If the connector is disconnected when there is significant amount of current flowing in the inductive load then there will be an out of spec. voltage spike that will damage the motor driver.  As with an ESD event the device may only be weakened by the voltage spike and subsequently fail after 10-20 more hours of operation.”

When I provided the link for the schematic he observed, “I see from the schematic that clamping diodes are in place to prevent excursions of outA and outB from going below ground.  I do not see similar clamping diodes in place for holding the outA and outB to VBB(+12V).”

That’s what I’ve got. Since I suspect a problem with either the chip or the circuit I’m going to have to lean on the technical expertise of EE guys (more of an ME guy myself). My guess is that the design of the circuit is allowing damaging spikes to come back to the motor driver. I don’t know where the first spike comes from, but it sounds like a single bad spike can degrade the chip enough to guarantee failure eventually. I suspect this would account for the interesting variety of failures (or lack thereof) reported by the community.

Personally, I was planning on moving to a stepper extruder anyway. So now I’m just planning on doing it faster. Maybe better electrical isolation of the ICs would solve the problem, maybe not, but at this point it looks like DC extruders are outclassed by steppers even if the extruder problem is solved.