MakerBot Industries

Can you tell me, is your motor working for a bit - then all the sudden it will stop.

When you use the control panel, and stop/reverse/forward - do the LEDs light up correctly? That would be left LED for stop, right for reverse, and both for forward?

Anyway - if that's your problem, it's mine too…

although I've also got
- a heater that stops working similarly to the motor stopping
- and getting lots of errant 0.0° C spikes on the temp readings.

all components check out ok when disconnected.

That is exactly what I'm seeing. I finally reuploaded all firmware, reset the boards, diassembled the board top make sure the wires were firmly placed. Now I get intermittant function - it will get half way through a build, then get a temp drop to zero, (probably thermister because it will reshoot up), the motor will stop extruding. All the LEDs indicate proper control/functioning, everything checks out separately, but intermittant extruder failure. Anybody have any suggestions?

Bit of a shot in the dark here but have you tried disabling temperature monitoring while you're building?

I've been having the same problem here.

intermittent everything. a couple of prints will go by, and everything will seem fine, then - in the middle of the build SOMETHING electronic goes haywire.

I was getting intermittent 0.0° spikes until I pulled the Cat5 cable away from the stepper motor cable, and that appeard to fix EVERYTHING for about 5 prints. then - all the sudden about 5 minutes ago - the Temp reading went straight to ZERO and stays there….

No I disconnected the thermistor and it read 6k ohm, right after shutting down from this. I have no idea if that's super low for it being around something like 180° C. will re-measure when it's cooled.

THIS IS MADDENING!!! this is my spare controller card too. I thought everything was going on great, but now - who knows.

So - I don't know how to fix it either - but I had SOME luck with separating the Cat5 from the stepper cables. I also put a big ferrite bead on the cable - but I don't really know if that had any effect. cables have noise? put a ferrite bead on them. hah - whatever.

I'm dead in the water now - so - hope someone can help us.

Since you replaced the extruder board and it does the exact same thing, maybe the problem is something on the motherboard. Since the whole circuit is affected in seemingly random ways, I'm guessing it might be a problem with the 12v power.

Have you checked the solder joints on the motherboard? Maybe your cat5 connector doesn't have a good 12v connection. I noticed on my optical end stops that the cat5 plug also had a bit of wiggle room. If I bump it, it doesn't make good contact even though the little clip snaps firmly into place. Maybe try pushing the plug in a bit and see if that helps? It couldn't hurt to check the solder joints on the new extruder board either, but I suspect you probably already did that. People have said the capacitors are prone to bad connections - you might look there too since these are supposed to help stabilize the voltage.

If you still can't resolve the issue, maybe the guys over here can be of more help. Its a reprap forum, but the electronics are very similar - if not the same. Just make it clear what set of electronics you have and maybe you'll find someone more knowledgeable over there that can help.

Andres suggested that I try reverting to older firmware to see if the problem goes away.

Well - I've gone back to 1.6 on mobo and 1.8 on the extruder controller.

so far - the extruder controller seems to be working better… (it's working, you heard me)

both DC Motor (1 and 2) STOPPED leds come on by default. on the 2.3 firmware they didn't show stopped unless they had been sent a command of some sort. - don't know if htat matters.

Unless you are running a different version of hardware, I can't picture the firmware versions changing anything. It isn't like the code for my v2.1 (downloaded) firmware is different from your v2.1 (unless you have changed it and recompiled of course), so that shouldn't explain any difference if your hardware is the same.

I'm running motherboard v1.2 with v2.1 firmware and an extruder v2.2 with either v2.3 or 2.2 firmware. I forget which and I can't check because I'm in the middle of a build right now. My setup is pretty rock solid at the moment though. The only reason I have had to abort any of my last dozen or so builds is that I was either experimenting with skeinforge settings or the first few threads of my raft didn't stay put.

I've got the 2.2 extruder controllers and the 1.2 mobo.

As much as it might be wierd - it's just true - at this point several builds now - and no strange behaviour since reverting back to 1.6 on mobo, and 1.8 on extruder.

If I go a day with printing fine and no problems on 1.6 and 1.8, then I'll step back up, first to mobo 2.1, then extruder to 2.3 IF there are no problems after mobo update.

All in all, this seems like a com problem - sometimes, and a cleanliness of power rails thing at other times.

The best thing, in my mind right now is… at least it's not a fried board (knocking on wood that it's not something that's being abused by continuing)

So while I understand it MAY not be the firmware. It's the first time I've been able to print for a decent length of time since this started happening… and I've fiddled with cable placement and everything. So - we'll see.

If it's a com issue, is it possible there's more chatter with the new firmware? like - is there a greater opportunity to crash the transceiver on either end?

Thanks cakeller98, I'll try reverting to older versions. I've suspected a noise or power issue. I did notice that things were significantly flakier in general when I tried to print under fluorescents. I've swapped out my cat5 cable, checked the solder joints, tried about everything else but downgrading my firmware versions. I'll let you know…

Good luck, and definitely let us know if that solves it.

In my mind this is more of a diagnostic of the hardware issue that appears to be somewhat commonplace? - if several people do this and it stabilizes their builds - then something new in the firmward is exceding some limitation on their (OUR) hardware.

I am totally hopeful that it was not just coincidence that it fixed mine - I'd like to find the root of the problem, and for me - electronics debugging IS VOODOO. mechanicals are cake - the unseen electron - fughetaboudit.

after a day and a couple builds of success - and hoping that maybe it was my wiring and not the firmware - I flashed my firmware.

latest firmwares on mobo and extruder - and the motor stops running in the middle of the second raft layer. :(

well - I don't know what the problem is - but - it's exacerbated by the firmware.

I'll downrev to 1.6 and 1.8 again -and flash each 1 rev at a time until I find when the problem starts. I suspect it's just anything 2.0+ just not sure which board.

am very interested to know if @neurothing had success with 1.6+1.8 as I did, or if it's just coincidental.

Did you remember do walk through the calibration steps after upgrading to firmware v2.x? You must change the PID values to the new defaults or the heater temperature won't keep up: http://wiki.makerbot.com/adjusting-the-thermistor-settings

yes, and, for me at least - this isn't a matter of the heater not keeping up, one of the 3 items just stops working… motor stops responding to commands. or the heater stops responding to commands and falls to RT, or the thermistor all the sudden reads 0.0… an stays.

I did adjust the PID settings with each downgrade / upgrade. (rather annoying that these settings are manual updates :( )

anyway… I just noticed when flashing the extruder controller from 1.8 to 2.2 r1… that the USB to TTL cable is a little flakey… a slight movement at the strain relief where the cable exits the USB connector housing, and the power seemed to flash on the board… is it possible the USB 2 TTL cable is causing this problem???

OK, so everything had been GREAT up till I flashed the boards (yes I have the PID settings properly for 2.1 (mobo) and 2.3 (extruder) combo….

but I got 1/2 way through the second layer of the raft, and now no combination of firmware seems to be doing the trick.

When I had 2.1 and 2.3 on, and the motor driver "crashed/stopped working" 1) the right LED for the DC motor stopped lighting up ever but the left LED lights up correctly. 2) I was at one point getting messages on repg stating something about empty payloads and unknown return codes…. but I think that was when I had 2.3 extruder, and 1.6 mobo, or was it 1.8 extruder, and 2.1 mobo?? I don't remember.

when I downgraded the extruder to 1.8 and restarted, I got a red message in repg stating "erasing"? or "updating" EEPROM to v 1.x

—— somehow once the motor crashed it seems like the flashing of the firmware isn't completing or something.

—— but again - everything was going along fine when I had 1.6 mobo, and 1.8 extruder.

as soon as I flashed - that's when things went wonky. In fact even now back at 1.6 and 1.8 - no joy.

Long story short (or maybe abbreviated is more appropriate), I have been pondering what could be so different between our setups that mine works fine while yours does not - having already covered the standard troubleshooting points and come up empty. Then it hit me as I read your last post.

I'm not using the standard usb cable. I print over a hacked radio shack "radio programmer". The factory connector was completely wrong for the job, but I did a little research and put a custom five pin plug on the end. Note I said five and not six - I forgot to add the +5v pin. It is just an empty socket, which seems to have been a (mostly) good thing.

I noticed that I don't get power feeding back to the PC if I leave the makerbot powered, plugged in, and have my PC shut off. Before using the hacked cable, this would cause a sort of buzz on my PC almost like a fan was trying to turn over but didn't have enough voltage to get started.

I have to use the original cable (with +5v connection) to do firmware updates, but it doesn't seem to be required for printing. I felt a little safer knowing that my hacked cable didn't exhibit the feedback issue though, so I kept using it for printing.

I wonder if my non-standard cable and/or lack of +5v connection is affecting anything. I haven't printed with the original cable in quite some time. I'll try a few test prints and see if I notice any difference while running with the standard cable.

That's be GREAT! - and interesting.

BTW, it's working again - go figure. I REALLY don't get it. One minute it's unresponsive, then out of the blue the motor starts responding to command (notice I said command, not commands) and then a power off and back on, and everything appears to be up and running.

again - I'm back on 1.6 and 1.8 - and until I know why it messes up - I'll be sticking with these revs. Sad as it is - these have not crashed the motor driver - so I'll stick with them till they do.

OK it hung up again - (the motor dropped out) and then I just kept setting the temp, setting it to zero, setting the motor to stop, 255, forward, reverse, 0, forward, 140, forward, stop, reverse… temp 200, temp 220…. meanwhile I am noticing that the LED next to the FET seems to MAYBE - it's hard to tell since it's "switching" … but it seems to be affected by the commands sent to the motor. SOMETHING seems to be connected in that circuit… I wonder if the motor start + heater on is causing a brown-out condition on the atmel? or something… or maybe it's something wierder. OR maybe it's a bad packet of info because of the cable (one of the many bad ones in the system.)

oy!

i also had the same problems you are experiencing cakeller98 i ended up desolder and resoldering the motor driver chips thinking it could have failed, worked then randomly screwed up again. bought a new extruder board seemed to be working fine but again started bugging out. firmware downgrades seemed to help me too but at a point they woudnt take like you are saying and similar error codes…

i also noticed if it bugged out and I got frustrated and slept on it, powered it all down it seemed to restore itself… i'm curious about dazednc's cable now

Just completed a one hour some-odd minutes print with the standard makerbot usb cable. It is probably just in my head, but it sounded like the steppers were driving a bit harder. No noticable change in print stability though. I had 7-ish benign "packet payload: empty" messages, but these appear while using my hacked cable too.

I thought we already talked about the whole low-voltage/brown-out thing? Maybe I'm thinking of another discussion. Usually when people start talking about that, it is attributed to running the motor, extruder heater, and heated build plate. According to the wiki, the cable is supposed to be able to carry 10 amps. A 4 ohm hbp works out to 3 amps, I'm guessing the motor to be 2-3 amps, the extruder heater at 6 ohm draws 2 amps, and you need maybe .5-1amp for running the control logic. The motor, being an inductive load, will trigger an amp spike when it switches on (at least when done by relay or switch contacts. Maybe the mosfet smooths out the switching action a bit? I'm still learning when it comes to solid state stuff.)

Taking the worst case estimations, with everything running, it draws 9 amps (90% of the cable's limit). So, if you're running a heated build plate, the motor switching on and spiking up the amps is probably that final nudge that puts your load above the limit of the cat5 cable's ability. Assuming I've got my understanding of the whole voltage-resistance-current relationship right, then when the cable can't handle the amp draw, your extruder board will see a reduction in voltage. If the drop is severe enough, it will cause your brownout.

The other thing I read on the wiki that might pertain to your problem is that if you give your extruder board 18V, it will overheat the 5v regulator - which powers the control logic. If your voltage is high and that regulator is overheating, that might explain the temporary nature of your problems. Lots of voltage regulators have thermal shutoff protection. These datsheets suggest that the 7805 used in our boards does as well. Maybe the thermal shut off is intermittently cutting power to the brains of your board.

all interesting - but I don't know it correlates to my problem… because - it's only one of the three things that seems to go haywire.

here's another wierdity…

when I have the heater on and heating up.

then change the motor speed and press forward or backward:

1. the motor doesn't turn on
2. the heater turns off until I hit enter on the temp again

there's something OFF about this. I've seen brown out situations in circuits from noise. Do I get why, no, but I've seen it in products I've worked on (I wasn't the EE, and am not an EE so it's third hand)

anyway - I was taking a video of this bizarro behaviour and the thermostat went to zero - the heater stayed on and got REALLY REALLY HOT and - poof - smoke… smoked the kapton tap, and the outter layer of PTFE tape I had wrapped around the heater. and actually a little bit of the insulation on the nichrome wire hade come loose on the heater element which dropped the resistance to 4.7Ω - I don't know for how long - but —- hopefully not long enough to cook the FET. Thank goodness this is open source though - I can just replace anything I BLOW up !! HOORAY !! :S

Right, but if your logic level voltage is weak, it could be causing failures all around. Not necessarily everything at once, but each item at different times depending on which things are powered, which ones are switching on/off, and how they affect the distribution of what little power is left.

One of my first transistor based circuits had issues like that. I was trying to use a couple of binary to decimal converters to drive two of sixteen outputs as a matching pair. My logic voltage was too low so during certain cycles it would randomly skip outputs on one or the other counter and the output device pairs were never the same. That was horrible to troubleshoot because it didn't seem to have any rhyme or reason.

Fair enough - so how could one test that? (without a scope)

If the voltage regulator is the chip on the right just below the big cap - I've checked it on a few occasions - and it's never been hot. would this be a transient thing?

So am I safe to (forgive me if this is stupid - I've done LIMITED electronics stuff since highschool) measure the incoming voltage by placing one lead of my volt meter to any ground, and the other to the 12v pin on the extruder board's connector? as long as that single lead doesn't short anything out by itself, am I ok to do this?

The problem is that your volt meter will be to slow to pick up a quick power drop that could result in unrational electronic behaviour. Even with a scope, it's not that simple to have the right input sensitivity, time scale and trigger settings to actually pick up such an event…

What you could maybe try it to add some more capacitors to the 12V (maybe 5V too) power supply on the extruder board. Something like a 1000uF/16V electrolytic capacitor (the bigger,the better) could make a difference, if it's really a power related issue.

I played around a bit on my board with more capacitors and seperate power supply wiring, but i wanted to reduce the empty packet errors and not some direct misbehaviour. (Did not get rid of all the empty packet errors yet, but it's much better now, and i had my bot do a 3h print session and finished a nice piece of ABS-Artwork…)

I can't really tell you a precise source for where your problem really is, but from all the design flaws i see in the schematic, layout and wiring of the extruder controller, the supply seems to be the biggest and most probable source for strange failures. It could be some bad soldering too, but thats hard to see and check from over here.

Chiming in again. After downgrading my firmware (both mobo and extruder), recalibrating, checking solder points on all connectors, testing the hardware again to make sure my motor is not flakey, replaced my cat5 cord, swapped through all ports, I went through the same thing as above - works for a while then just see a dip in temperature and the motor stops and reports of empty packet errors. Basically randomly.

I'm really beginning to think that this printer was a lovely idea but it is just too flakey to spend more time on.

check this out -

try setting the temperature so the heater comes on.

then try setting the motor speed and select forward, or backward, or stop.

keep doing this - repeatedly when the motor is not responding.

DOES THE HEATER KICK TO OFF WHENEVER YOU CHANGE DIRECTION AND SPEED???

Mine does… it's odd.

and I TOTALLY feel your sentiment… but will likely stick it out - and am sorta glad that at least I'm not alone in this issue.

Isaac Dietz emailed me back and suggested re-flashing the bootloader. IT requires the TinyISP usb programmer, or similar, but he thinks it might help. - I'm not sure. - but it's worth a shot.

i have the exact same symptoms as you cakeller98.

I'm going to Protonite's cap mod a go and see if that fixes it.

PLEASE DOCUMENT WHAT YOU DO! :) and let us know if it fixes anything or everything :) And with pictures too (if you would be so kind)! :) thanks.

cakeller98, I checked and my heater does exactly the same thing. Let me know if reflashing the bootloader helps.

I've packed it up and I'm going to hand it over to some of my more insane engineering grad students to see if they can save it or destroy it. I'll keep checking back and if they do come up with anything I'll post immediately.

Seems like strange behavior but Isaac Dietz told me it's normal, and changing motor speed and direction at the same time is not a normal set of events. It's better to set the speed and press stop, then press forward.

Although I really don't see the difference. If setting motor speed and etc is supposed to happen as a discrete command, then the control panel should know this and send it as discrete commands. i.e. if there is a command sequence that can cause problems, then the software needs to NOT allow it.

However, I don't think that people without this seemingly hardware-like problem have the same event sequence, but who knows, maybe it really is normal for the heater to get shut off by the motor speed change command followed immediately by the forward or stop, or reverse command. I just don't know.

looking forward to v2kai's cap adventure!

i'll be grabbing my caps tomorrow morning and hopefully get time to work on it in the next couple days. I'll definitely document how it goes.

Also I might mention my makerbot was absolutely screwy, as we've all described so I disconnected the usb cable, power supply (from the wall outlet) and unplugged the extruder board from the mobo, remove SD and let it sit for 24 hours. Now upon reconnecting everything and firing it back up… seems like it's back to normal. this of course is a temporary fix as it goes wonky again usually (if i'm lucky) after a couple prints. Albeit temporary it's at least something to keep you from tearing your hair out until we get to the root of the problem.

still doing the cap mod will post up details how it goes.

i should also mention this may help us out

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

as mentioned directed airflow over the board and cooling seems to help, so makerbot willing I'm going to try and print this and add it to my setup

can a mod please delete.

"Known issues
If a build is interrupted while the nozzle is heating up, it's possible for the extruder controller to get into a bad state and require a reset. The motherboard will often indicate that it's having trouble contacting the extruder controller by blinking once or twice."

uh-what does that mean? isn't the nozzle CONSTANTLY being heated up?

What I'm getting at is - ok, say a build is going bad because the motor stopped - and you cancel out - does that mean that stopping the build will put the extruder controller into a bad state, necessitating a reset? and is it possible that this "bad state" sometimes actually means "corrupt firmware" state??

Seems to me there is something SERIOUSLY wrong - ok maybe not SERIOUSLY, but just wrong enough that with the right component, and assembly tollerance stack-up there are a bunch of people with set-ups that don't work as well (at all) as other folks do.

I'm in the process of trying to flash the bootloader and firmware from scratch, on both extruder controller and motherboard. I don't have a USB programmer, so I'm going to try and use my STK500's ISP —- we'll see, long as I can find the right HEX file I should be ok.

I'm also going to download the firmware/bootloader and eeprom from the card and see if I can find the same version of firmware, to do a byte-compare…

ok - so I EASILY flashed the firmware using my STK500 and AVR Studio. In addition, I was able to verify the firmware as well… don't know which bootloader I had on there before - so I guess I don't know.

I've reconnected the motor - and the control panel STILL can't turn on the motor.
without the motor hooked up - the LEDs come on properly. when it's hooked up - hmm… no such luck???

is it possible the motor is tweaked? it runs fine off 9v battery.

motor controller? - but everything is fine when the motor is not hooked up.

I M @ A Loss!!!

EDIT:
OK, so I reset EVERYTHING - all green. Then I bring up the control panel. Change motor speed to 255 (or anything) then I press stop. Then I press forward.

result, after pressing forward, the two LEDs come on for about 300 ms, and then the right one turns off. the left stays lit, and that's it.

The red light on the mobo keeps blinking slowly.

DUDES!!! OMG - so - every time I sent a motor command - the motor driver was crashing. lights would blink, then blink off.

This is the wierd part - I hooked up the motor to a 9v battery, and huh… it's working.

Hooked it back up to the circuit and what???? it works again.

sounds like a bad motor-vader.

frickin wierd…

and the motor just crashed again…. let's see if unhook, connect to 9v battery and then, back on the controller un-sticks it.

if so - at least it's telling… I just don't know what.

Just random - not telling.

now the board is reporting null version.

BTW I was getting a ton of unkown response codes as well.

I only flashed the bootloader, and firmware on the extruder controller - wonder if I should do both motherboard and extruder controller.

is it wierd that while I've got my amp meter hooked up in series with the motor the thing isn't crashing at all?

I just ran it through one of my test builds and it's running all the way through - with firmware 2.3 on the EC and 2.1 on the MB.

Go figure.

OK now I'm doing the same build with the volt meter hooked up across the terminals with the motor running…. motor is running - all the way through the build.

One thing I did notice is the reset sequence is tricky - to get the motor to come back online once it's gone offline.

I have to power off the motherboard, hit the reset switch (I guess to dissapate any residual power? ) then turn it back on and reset the extruder controller…

Sometimes I have to do the software reset. - I just haven't nailed the exact method yet, but it FEELS like it's possible - just a little flakey.

This is hair-brained - goofiness…

now the extruder controller is working ok. maybe, but maybe only when there's something hooked up inline with the motor - or across it - or who knows if I hold my breath and cross my fingers, eyes, toes, and T's

any ideas?! should I put a small resistor in series with the motor? should I put a cap across it (obviously not a polarized cap, just a buffer or something)

what can I do.

Also - the unknown packet errors and such are the precursors to the MB and/or EC crashing. they are a bad sign…

EDIT: OK it all works when motor is hooked up backwards - WHY? When I set it up with the amp-meter, it was definitely hooked up correctly, but when I did the volt-meter, well… I goofed and got it backwards. When I hooked it up correctly and re-ran the control panel - the motor cuts out after a few seconds.

without the motor hooked up - the LEDs come on properly. when it's hooked up - hmm… no such luck???

This seems to prove what I was trying to explain earlier about the motor being an inductive load that has a higher current draw upon start up and how the cat5 cable is probably very near the limit of how much current it can handle. Without the motor being in the circuit, there is one less thing drawing power. With less things drawing power, your control voltage is probably more stable. Hence, you don't get random failures. Check out mangel-ajo's graphs in this thread for some real world data on what is happening. I don't quite know what those graphs really mean (IE: mVpp is something I've never heard of before) but I'm guessing that one of them shows how switching on the motor while the heater is running causes a voltage drop. The others make even less sense to me, but I think they are showing how the tx/rx lines are affected by motor activity.

I still suspect that you are fighting power supply issues and that if you could beef up or stabilize the power more, then the other design flaws will cause what amounts to negligible inconveniences rather than aborted builds.

I would try the modifications Protonite suggested before mucking about with anything else. If that helped, maybe you could get even better results by replacing the voltage regulator with an actual 5V supply from the PSU.

Mangel-ajo also mentioned something about putting a EMF filter on the motor. I think this is generally done with a capacitor wired in parallel with the motor. Don't use an electrolytic cap because it could explode when the voltage reversed in order to make the motor go backwards. I couldn't say what size you should use.

so I can reliably (almost) get the motor back up and running through a really nutty sequence of resetting - everything has to align just right. But here's the thing - I can only reliably get everything to come back when I have the meter hooked up in series with the motor measuring the amps.

I'm considering putting a low-ohm resistor in there. Is it possible the DC motor is getting some kinda spike it doesn't like and kicks off and cthereby confuses the controller? I dunno…

@dazeddnc - isn't it WEIRD though that it works when hooked up in series with the amp meter, and when hooked up in parallel with the volt meter but only when reversed polarity?

It only stops responding when hooked up in forward polarity. RE TAR DOID -

So - yes, am interested in Protonite's solution - I don't have the EE background to decide WHAT to put on there Might have to pull out my Forrest Mims books :) see if there's something in there that could help? hehe…

Check this out - when the EC is reset, the debug light blinks on bright once, then off, then the B FET's LED blinks on very very faintly and then off. seems like parasitic signal going through there, not like something deliberate.

I have been looking over the board really closely - but I can't find any solder that's crossing…

so - what values of caps and where - please :D

I've put a 0.375 nF ceramic disc cap across the motor leads and a 2.2ohm resistor - in series with the motor.

So far soooo freakin' good.

I should try it with ONE or the other - but it's going along here - without hiccups so far.

I forget what I was doing at the time, but I have noticed the LED thing too. I figured it was just a freak event caused by the caps charging up or voltages bouncing around during initial power up.

I'm not sure I understand what you were saying about the polarity though.

As far as the cap size goes, you should be able to use any uF rating without causing damage. While I can't answer what uF rating is optimal or if it is really critical, getting a suitable voltage rating definitely matters. I think the rule of thumb is to look for ones marked at or above double the voltage of your circuit. IE: For a 5V circuit, use a 10V or higher cap. For a 12V circuit, use a 24V or higher cap. You'll see that the existing caps are rated at 50V even though they shouldn't see anywhere near that much voltage. It should be safe to try whatever uF caps are most available to you and see which works best. Just make sure the voltage rating fits.

As a word of caution for future reference, if this were an AC circuit, then the capacitor could be configured to drop voltage. In this case, using a cap with a different uF rating would change the voltage. Don't do that.

Edit:
I put together a picture to try and help describe the orientation/location of the caps. You can wire in parallel to C1 and C2. If it makes things easier, wire in parallel to C3 and C4. Just pay attention to polarity as noted in the pic.

Once you have found a capacitance that works best, you'll need to add 100nF to it if you intend to remove the existing metal covered caps. I wouldn't recommend removing the ceramic ones. I'm guessing there is something special about ceramic caps or otherwise they could have just used one cap with a greater capacitance to do the job of two caps.

yeah great…. although, as it is - what I've got going seems to be working. A filtering cap (right? @ 0.375 nF across the motor leads, and my 2.2ohm resistor in-line seem to have prevented the wierd spikes. and smoothed the voltage WAY out. in fact before I wasn't able to read the voltage smoothly coming off the DC motor leads, now with the CAP, the voltage looks like pretty rightly exact at any motor speed from 140 (7.5V) to 220 (~9v) to 240 (11 v) and 255 (~11.8V) and what's wierd is - it almost seems as though when the motor kicks over 12v AT ALL it goes nuts.

i'm glad youre making headway because i just finished swapping out those 100uf caps to 1000uf and no difference on my end. was protonite's suggestion to add another 1000uf cap in parallel to the existing caps, either way I've significantly boosted the capacitors in the PS circuit and my extruder motor is still hooped. you've got me all excited with the new filtering cap setup!!! need to try this asap

can you share what you did in terms of reset sequence to breath life back into your extruder motor board again?

Keep in mind there may be a bit of voodoo here - and I also burned the bootloader on my Extruder Controller - so I MAY have un-corrupted something there - but I also still got motor stoppages.

Bear in mind - I am totally psyched as well, but in a measured way. I've been equally as excited many times over the past few days.

reset sequence (without the dancing and praying and finger crossing)

When motor stops responding and/or temp hits ZERO.
Pass 1-

1. reset EC
2. reset MB
3. reset machine via ReplicatorG
4. press reset on MB again

if both power LED go green !!WITHOUT!! getting the lost packet red debug/comm light of doom - then USUALLY the motor starts back up.

if that doesn't work

Pass2

1. power off the MB by the switch
2. turn off ATX power supply
3. press reset button on mobo (as the red debug/comm whatever LED still keeps blinkin' after ATX is off… EVEN when the USB2TTL is disconnected, although right now in Pass2 - it's still connected. - this should dissapate any residual wahtever and the red light should go off and not come back on.
4. turn on ATX power
5. turn on MB the red light should blink 3 times, and then again 3 times - then go out.
6. if the red LED KEEPS blinking - it'll prolly say Unknown response code in the repg window - if it's communicating with the MB that is) sometimes it doesnt… anyway - if it's blinking red - then the reset probably didn't work - so, reset the EC first, then reset the MB.
7. hopefully both power LED have gone green!
8. good idea to either restart replicatorG OR reset machine from replicatorG or disconnect and reconnect. —- sometimes a reset machine - leaves the red debug light blinking and that's fixed by a MB reset.

STEP 2 - check using control panel in ReplicatorG - set the motor speed to 255, press forward (no plastic filament, and don't set the heat yet)

if both LED go on on the DC Gear Motor circuit and the motor starts turnin- you're back
if both LED go on for a second, and then the right LED goes off - that's the problem I have, and the EC is probably now in a "Bad State" - as stated by the Makerbot Wiki.

again if the left LED goes on ever - then subsequent commands probably won't work on the motor, and the left LED will respond properly, but the right LED will be pretty much permanently off.

Anyway - this is what my experience has been like - the fact that I can reset the circuit is a good thing
the fact that I can deliberately crash the motor circuit - at all, ever - and that I seemingly CANT when the amp meter is hooked up in series, leads me to believe that it's all in the motor circuit, and it's just something flakey in there.

hope this helps. I'll post a pic of my filter cap and resistor, however - it's brain dead simple to explain - so … from the 1A terminal - a lead goes to a 2.2 ohm resistor, the other end of the resistor is then tothe cap, and the RED lead of the motor. the black lead of the motor is connected to the other side of the cap, and then that is inserted into teminal 1B

This is what I did (there may be a better cap value, but I don't know and this is just one of those ceramic disc caps I had laying around)

[1B]--------+-----blk----/MOTOR
            |
            =  <0.375 nF>
            |
[1A]--/\/\/--+-----red----/MOTOR
          2.2ohm

well i've got mine going again configured similar to yours with motor cap and resistor. we'll see how it goes

Cakeller98, I'll give it a whirl, but to throw in my 2 bits, the 2 engineering grad students who got to dissect my unit said the first problem was the USB-TTL. Their quote "who made this piece of cr*p?" It apparently would spike every time it was wiggled even slightly, and since the makerbot vibrates pretty much constantly, it seems a likely suspect. I'm having them scavenge the serial chip from it and rebuild the cable so I'll try that as well as your fix and will post any updates.

Thanks for all your work.

Yup - I noticed that a jostle on the cable would cause errors as well.

FTDI, I think makes that cable - if you look up the cable online you can find the specs and stuff - since it's open source as well (I'm pretty sure)

FWIW - if you do make a new cable - try to see if that solves it without my mod, as well as with… I mean - I've made my modification and (knock on wood) I haven't had the motor go butunky yet… I've run several parts as well as tried hooking up the heated build plate which - FAIL! - didn't work because it's trying to draw how many? 36 WATTS through that poor little underpowered mosfet that - since they state don't make your heater barrel under 6 ohms, or you'll burn out the mosfet, I don't know why they think 4 ohms on a pcb would be ok.

I mean REALLY!!??!! - anyway :D even with that not working and shutting down the mosfet, STILL no crashing boards. So - I'm feeling pretty good about now.

Anyway - I'd be interested to know though if the USB cable fixes it as well… the motor might just be the straw - like the USB keeps it in a precarious state, and the motor-spikes or whatever, are what dumps it into a bad-state.

keep us posted!

now I go back to learning to configure setting for Skeinforge!

While trying to learn more about how to determine the correct cap for both the EMF filter and voltage stabilization, I found a thread on another forum about the subject.

Apparently the optimal cap size is related to the frequency you are trying to filter out. Low frequencies require higher farad ratings. High frequencies require smaller farad ratings. Apparently large caps are better suited for stabilizing voltage while smaller ones are better at EMF filtering.

Quote from one of the posters:

if your motor is causing interferance on a UHF TV channel then 100nf is probably too big, I recommend 1nF or 470pF, or better still use ferrite beads on the connections.

If a filtering cap makes a significant difference, the ferrite bead might be another thing worth investigating. I don't know how that compares to using a cap in terms of emf filtering characteristics.

As far as voltage stabilizing caps, I see a lot of 300-3300uf caps in my collection of retired power supplies. This is probably a good indication of what range you should be looking for there. Given that someone already tried a 1000uf cap without seeing improvement, this may not help though.

EDIT:
See this for reading the cap values.
http://www.hackcanada.com/blackcrawl/elctrnic/capinfo.txt

I just happen to have that 0.375 nF (isn't that 375 pF?) cap there - and it just seems to fix it… OR I dropped the voltage enough so the motor isn't spiking as much?? maybe??

I should try bypassing the resistor and see if it's just the cap… Although the 2.2 ohms is only dropping 0.1 or 0.2 volts there… if I measured that right… so it might just be doing nothing.

anyway - thanks for the input.

OK so the 0.375 nF cap virtually eliminates the noise….

wait for it -

only at certain speeds of the motor.

well - duhhh…

so now - what can I do here? - can I put a bunch of different sized caps? I think it doesn't work like that - parallel caps are just like added together, right? or does that change when you're talking about noise filtering etc?

http://groups.google.com/group/makerbot/msg/67bfbc6b1021bb0d

I was over at that link - looking at the write up that Cliff Biffle did on calibrating your makerbot… so I decided to do some studies to check my filament useage - anyway - long story short, I noted that those errors are back when I use particular motor speeds (230, not 235, but definitely 240, 245, and not 255 at all…

hmmmm- I did mention before that it seemed to happen in the middle of a build, randomly.

?How much you wanna bet there was a motor speed change. Not that the motor speed change caused it, but maybe the actual SPEED!

—- Another note - my successful printing of late has not included speed changes - so perhaps THAT has something to do with my successes as well.

joy!

Isaac suggested upgrading to a Cat6 cable - hmm… ok, I'll give that a go. I even have a Enet crimper - I can get a 3m cable and cut it as short as I can reliably still use it.

Long as you guys care - I'll keep posting my findings. :D

I designed a DC motor suppressor for RepRap and Zach made a PCB for it: http://hydraraptor.blogspot.com/2008/11/suppression.html

I don't know why he didn't include it in the Cupcake kit as would save a lot of random problems. DC motors generate massive amounts of RF noise and it varies from motor to motor and during its life, as the brushes first wear in and then wear out.

Although your series resistor only drops a small voltage when the motor is running, it will limit the big peak current when the motors starts, so will help if your 12V supply is not solid.

SERIOUSLY?! wow - why not indeed!…

Is there anything special about the ferite ?
I have some stock of my own - so going to give it a try.

Nopheaad -rocks.

thanks.

I don't think the ferrite is too critical. I used what I had and Zach used a different one and it seemed to work at least as well.

I was getting some VHF noise so theoretically it needs a ferrite with good high frequency attenuation.

They have a current rating, which is not about them burning out, but about them not magnetically saturating.

Okay, swapping the new improved (and much less noisy) USB-TTL cable helped but I still had a spike and stoppage after 15 minutes; however, it did kick right back in after a mobo/extruder reset, so I suspect that was a contributor. However, when I tried Cakeller98's trick (2.2 Ohm resistor and a 100 pF cap [all I had lying around even near the appropriate range]), it's been running forward and backwards reliably for 30 minutes now. Fingers crossed - will keep informed…

Hopefully final update on this. The new USB-TTL cable and Cakeller98's mod seem to have done the trick - in five days I've printed ten major complicated items and no problems (aside from the usual creaky plastruder gear, plastic bit wrapped around bearing slowing it down, cat sticking head into chamber and biting the thermistor wires). Thank you Cakeller98 and everyone else who chimed in…

slight - update - I'm looking in to the filter circuit I made having SOME potential conditions where it doesn't work - or may cause problems.

I ran in to a situation durring a test where a PWM value of 230, and also 235 still can cause the motor to stop responding, the extruder board to sometimes crash when the motor stops responding, and the DC Motor drive chip AND resistor to get -VERY HOT!-

I finally had someone mention that the motor's inductance, and the cap may be creating, essentially, a notch filter - which would have some resonant frequencies that are worse than without the circuit… so maybe that's what those frequencies are (230-235)

I run mine at 210 and it's working just fine - but in case someone has trouble… I think this issue is not solved - at least not well solved… yet :D

I am glad that the solution has helped some folks get started printing - when nothing else seemed to work - but it doesn't seem to work in every situation.

for those of us that cannot print without it - we need to keep looking for a better solution?!

Resonsance could maybe lead to some strange behaviour, but i think it's something else that causes your problems. You have to keep in mind that we are actually dealing with digital pulse with modulated signals here, so the base frequency stays the same all the time and we just modify the on/off ratio.

I would think it's more a problem of the driver circuit having problems to keep up with the signal the controller wants to have amplified. It maybe gets into some kind of "half conducting" state or even trying to short out the H-bridge at a certain PWM input and thus acts like a resistor. That would explain why it gets hot very fast. I could imagine that this bad driver state could generate some nasty "backfire" of noise into the supply too, so the entire circuit could get unstable and unpredictable…
Just a theory tho, to really get down to it, i would need to measure your circuit to see whats really going on. (my circuit seems to be rock solid after i did some tweaking)

For now, there is only one thing i can tell you to do:
To really see if its a resonance problem you can try to change the capacitors value of your filter circuit. (try something like 10x bigger or smaller to shift resonance frequency far enough) If that does not really change the PWM values that provoke the error, there is definately some other problem around.

Thanks Protonite ;)

yeah - ok I can do that test pretty easily.

What's your circuit look like?

by the way I was just reading up on a "tuned circuit" and when you hit the resonant frequency on that, if I read this right, it says the impedance can go very high or very low.

if it's tanking really low that would totally make sense with what's happening.

so - I'm thinking it's time for a different cap - or build a proper circuit.

Yea, the impedance can drop pretty low, but as we are basically still supplying a switched on/off signal to the motor, you cant compare it to a perfect sinus ac waveform you usually calculate resonance and impedance with. (at least thats the case for most examples you will find) And you have to keep in mind that you would have to really hit the "sweetspot" with quite some precision to mess up the driving circuit we use. If you are just "near" the sweetspot, you still have a large amount of ohmic resistance that would stop the current from getting to high… Thats why i dont think the resonance is the problem here.

My circuit has some small modifications on the supply side. Direct 12V input from the atx-powersupply, for that i removed the rj-45 connection to the mainboard completely and just added a small connector for the rs485 bus and a screw terminal for the power. Then, i swapped the electrolyte capacitors for some bigger sized ones with better quality (less series resistance, higher capacity) and added some tantalum and small ceramic capacitors on the neuralgic points (at ic and power terminals) to eliminate some of the noise sources. To get rid of some comm errors on the rs485 bus i tryed to swap the rs485 transceivers with a fault tolerant circuit too, but it turned out to be a firmware problem that could not get hardware fixed…

gotcha - yeah I do get that PWM is not a sinusoidal waveform - but the frequency coupled with the inherent noise of the dc motor might end up hitting something.

On the other hand your idea of hitting some (at least I think this is what you mean) some bad spot electrically on the dc motor with a particular PWM - is something I'd also considered, I just don't know how I'd fix that :D

… anyway - I'll be driving my bot at a PWM frequency of 210 until we all find a better solution. It's find with me anyway - since I've got my Skeinforge totally dialed in for this PWM and am now getting better than decent printing with it… and at a feed rate of 28mm/s so it's not like I'm limping along here.

And the resistors and chip are cool to the touch - at this PWM, so as I said - until someone gives me a "try this at home" solution - with pictures :D I'll be just happily printing knowing that I have a slightly hobbled setup.

Thanks protonite - do you have these changes documented? care to share? or was it just a bunch of experimenting that ended with a rock-solid machine?

Currently i dont have it documented for public eyes. I wanted to start a blog or something to share all my modifications with the community, but i just did not take the time to actually sit down and set a page up for everything.
I will try to free up some hours and start the documentation, but it will probably take some weeks before its all set up, especially now that we have very nice summery weather i prefer to do other stuff… :)

This has just started happening to me too! Ugh, it is so frustrating.

Interestingly enough, this only started right after I moved my Makerbot to a new room in my house. This room just so happens to be near the powerline into the house and the bot is directly over where the fuse box is in the basement. I figure that high EMF levels are the culprit here.

I've shielded all the communication cables with braided shielding, still no luck.

I will try cakeller98's RC filter today to see if that does the trick.

If that dosen't work, I'm going to go insane! Then ground, cage and shield everything!

ah!

RC filter works like a charm. Thank you cakeller98