PDA

View Full Version : Need a miracle to make it now (long rant)



jwatte
04-13-2013, 03:01 AM
I made new leg brackets to narrow the footprint of the bot. I also attached cooling fans to the knee servos (which seemed to work alright.) I turned it on, on battery, and 7 of my 14 servos stopped communicating, and will now not answer to firmware recovery. The other 7 are fine (-ish.)

It'll take a miracle for me to be at Mech Warfare at robogames. Or at least a very, very, fast Robotis turn-around. (They've been out of the office last week, I hear.) Also, I'm out of testable ideas for what could potentially be the problem. Inductive kick ("L-C spikes") in the wiring? Regenerative voltage from turning the servos manually? 16.8V of a fully charged LiPo is actually too much? (Note that the servos will report overvoltage, but Robotis support forums say 4S LiPo is fine.)

I'm at the point where I'm no longer willing to concede that it's all user error. My first catastrophic failure was probably my fault, but after fixing that, it hasn't really gotten better. These parts are not behaving to spec. I'm treating them as gently as I can -- if these were eggs, they'd all be in fine shape! Yet, they keep failing.

Others are getting these servos to work, and stay working, I think? There must be something different in the way I develop. There are two main problems I keep running into.

For the torque/heat problem: I idle the bot a lot with power on. The reason is that I develop the controlling code on the computer that also runs the bot -- the bot is the computer!
If you see the temperature-over-time charts I posted in the other thread, after 25 minutes of uptime, some of the servos are getting quite toasty. This may have led to some servos becoming "sticky" and very hard to move by hand. If I just run the bot for a few minutes, and then turn it off, the initial design of my bot wouldn't have been a problem, because not enough heat would have built up.
I have never let the servos actually overheat -- I put the shut-off temperature at 75 degrees, down from the default of 80 -- but it may be that prolonged "warm" also is a problem.
Now that the problem is isolated, I actually think the active cooling will do just fine for this. It's just a shame that some of the servos suffered from my blind spot until now.

For the servos-stop-communicating problem: It seems pretty much like an input driver problem in the servos themselves. For example, if a pin on a 3.3V microcontroller was tied directly to the bus, without buffering and without stand-off and ESD protection, I'd expect it to be very fragile, and that might be an explanation for these problem. This second time, I'm not aware of anything I could have done wrong myself; the most likely culprit would be an inductive kick when turning the system on. The servos closer to the distribution were the ones that failed, whereas all of the furthest-out servos seem fine.


So, some combination of documentation problems (holding vs stall torque vs heat buildup) plus usage pattern (very long on-times) plus who-knows-what for the electrical failure means I'm unlikely to have a working mech by Robo Games. I'm also out about $5,000 in parts. This, frankly, has me very disappointed!

tician
04-13-2013, 04:16 AM
(They've been out of the office last week, I hear.)
All their sites were down a couple days ago and their Q&A is getting spammed again this weekend (not nearly as bad as a couple weekends ago where they got several hundred spam posts).


Also, I'm out of testable ideas for what could potentially be the problem. Inductive kick ("L-C spikes") in the wiring? Regenerative voltage from turning the servos manually? 16.8V of a fully charged LiPo is actually too much? (Note that the servos will report overvoltage, but Robotis support forums say 4S LiPo is fine.)
How long does it report mild over-voltage? If it is really short term, it probably won't cause any problems. Long term, not so sure. Short-term, really high spikes definitely can cause problems. Time will tell if 4S LiFePO4 is as safe as I hope for the MX-28 (14.8V fully charged would appear to be almost perfect for the MX-series).


I'm at the point where I'm no longer willing to concede that it's all user error. My first catastrophic failure was probably my fault, but after fixing that, it hasn't really gotten better. These parts are not behaving to spec. I'm treating them as gently as I can -- if these were eggs, they'd all be in fine shape! Yet, they keep failing.

Others are getting these servos to work, and stay working, I think? There must be something different in the way I develop. There are two main problems I keep running into.
What sort of filtering (http://forums.trossenrobotics.com/showthread.php?5371-A-Multi-Purpose-Hexapod&p=54826#post54826) do you have on the power supply to the servos?


For the torque/heat problem: I idle the bot a lot with power on. The reason is that I develop the controlling code on the computer that also runs the bot -- the bot is the computer!
Maybe try powering the servos independently of the PC. The CM-730 in the DARwIn-OP and NimbRo-OP can completely cut power to the dynamixel bus when not needed (or falling down or pressed the CM-730 reset button). Just leaving them idle (torque disabled but still powered) after an overheat error can lead to failure, so maybe just sitting idle without a previous overheat can cause problems as well.


If you see the temperature-over-time charts I posted in the other thread, after 25 minutes of uptime, some of the servos are getting quite toasty. This may have led to some servos becoming "sticky" and very hard to move by hand. If I just run the bot for a few minutes, and then turn it off, the initial design of my bot wouldn't have been a problem, because not enough heat would have built up.
I have never let the servos actually overheat -- I put the shut-off temperature at 75 degrees, down from the default of 80 -- but it may be that prolonged "warm" also is a problem.
Now that the problem is isolated, I actually think the active cooling will do just fine for this. It's just a shame that some of the servos suffered from my blind spot until now.
You are not alone. The shoulder servo that was making an unusual noise (may have overheated or over-torqued, but no damage to geartrain) is now getting a bit stickier with every use. The spare with the really sticky motor is probably not too far ahead in failure, but we have not been using it recently.


For the servos-stop-communicating problem: It seems pretty much like an input driver problem in the servos themselves. For example, if a pin on a 3.3V microcontroller was tied directly to the bus, without buffering and without stand-off and ESD protection, I'd expect it to be very fragile, and that might be an explanation for these problem. This second time, I'm not aware of anything I could have done wrong myself; the most likely culprit would be an inductive kick when turning the system on. The servos closer to the distribution were the ones that failed, whereas all of the furthest-out servos seem fine.
The STM32 in the MX-series servos is 3.3V, but it should have a buffer IC protecting it and performing the full-duplex to half-duplex conversion. Do the servo LED's light up and not respond, or do they not show any signs of life? I get the feeling that buffer IC is not surviving as well as it should, because we had the same problem with a couple MX-28 that went to Taiwan (they would flash their LEDs at start up, but refuse to respond).


So, some combination of documentation problems (holding vs stall torque vs heat buildup) plus usage pattern (very long on-times) plus who-knows-what for the electrical failure means I'm unlikely to have a working mech by Robo Games. I'm also out about $5,000 in parts. This, frankly, has me very disappointed!
ouch.

Xevel
04-13-2013, 07:30 AM
Sorry for what's happening to you :/

I've had in my hands a "sticky" MX-28 that somewhat worked (LED OK, communication OK, moved when asked even if the noise what a little bit off): it had an idle current of ~300mA compared to the measured ~60mA of a brand new one. It heated up even when idle (heat coming from the side with the horn, not from the side with the motor), while the new one stayed around room temperature.
Same deal with an AX-18F.

I have no idea what exactly is wrong or how to fic it but you could test power consumption on the ones which are "fine" to see if they really are. :/

jwatte
04-13-2013, 11:32 AM
14.8V fully charged would appear to be almost perfect for the MX-series

Fully charged, that's at 16.8V. The hard-coded maximum voltage sensor level is 16.0V. The 16.8V fairly quickly bleeds down to 16.0V (after a few minutes.)
Andrew/Tyberius, and Robotis support forums, claim 4S should be good, though.


What sort of filtering do you have on the power supply to the servos?

I have a 1000 uF electrolytic capacitor, and a 22 uF ceramic capacitor, and a 16V stand-off TVS diode, at the hed end, before the 2 connectors that split out to the 6-way hub. After that, there's just the narrow-gauge Trossen and Robotis wiring, adding some resistance. Note the graph I posted a while back showing about 4V spikes on the battery power when the servo is moving -- hence the TVS! Also, a LiPo battery is very low impedance, much lower than almost all AC power supplies, but it still can't eat all that (the wiring probably doesn't help.)

I've been thinking about soft power-off, but board space is an issue, and turn-around time with OSH Park or iteadstudio is slow enough that I haven't been iterating past the original design for now. Another option is to build some little dongle to use on each connection with additional filtering and some TVS and perhaps a little power regulator for plugging in a fan so I don't have to run a second strand of cable...

I'm not quite ready to call bullshit on these servos just yet, but they certainly are the finickiest part I've had to work with in all of my life, and I've worked with some very finicky alpha hardware of various kinds before! (I've done electronics since I was 10, software since I was 12, and have worked on embedded/hardware teams before, although I'm a software guy professionally.)

Anyway -- if Robotis can turn around an RMA in a day, I could overnight the servos from Monday 'til Tuesday, they re-mail on Wednesday, and I have the servos back on Thursday, and I have the evning to assemble a working bot. The danger is that I honestly don't know what killed them this time, and will it come again? What can I possibly do to protect against it?


It heated up even when idle

Probably a good idea to check. Although in the temp diagram I posted the other day, really only the knee servos were problematic, and the fans seemed to get good airflow in that way. All those servos are part of the dead now, though.

tician
04-13-2013, 02:03 PM
I was talking 4S LiFePO4, not 4S LiPo. A pair of 1.45Ah 2S LiFePO4 receiver packs modified into a single 4S DARwIn-OP pack. It really will look quite a bit like a stick of butter when finished.

The CM-730 has ~1300uF of 35V electrolytic caps directly next to the input power connector for a bot with a 10A fuse and 20 MX-28.

The controlled, slower, lower current dynamixel bus power-on transition might be worth the bit of ugly that a through-hole P-MOSFET, or two, on a piece of proto-board might add. Also, digikey sells some really simple DPak and D2Pack breakout boards if you want SMD instead. Then again, there is nothing quite like overkill (http://www.digikey.com/product-detail/en/IXTN170P10P/IXTN170P10P-ND/1995386).

jwatte
04-13-2013, 02:37 PM
The controlled, slower, lower current dynamixel bus power-on transition

Are you suggesting the TTL serial bus here?

I'm actually thinking MCP1407 drivers on the way out from the microcontroller. But the problem is that my microcontroller is still healthy -- it's the boards in the servos that are nonresponsive. Thus, driving that bus stronger isn't going to help me much. If the problem is spikes on the TTL bus, then I need something to eat those spikes, without affecting the signal.

I previously tried a 5000 W 5.1V TVS diode. Unfortunately, it has a capacitance of 2 nF, which at a 70 Ohm drive impedance puts the filter corner frequency at 700 kHz, so the signal didn't make it through. I'm going to have to look for lower-capacitance devices (by a lot!)
The problem is that, even if *I* can drive the bus just fine, the servos sending responses might not be able to, so I might not be able to read data back.

If you mean the actual power wires, then my capacitance is within spitting distance of the CM-730. Also, the combination of ceramic (very low ESR) and electrolytic (very high capacitance) should be decent. Plus I already have a 16V TVS, so at most 19V or so spikes should make it through the head end. The problem is, the wires have inductance, and thus protection is needed at the tail end, which the Dynamixels themselves may not have a lot of.

Btw: Nice MOSFET selection :-)

AVRnj
04-13-2013, 06:50 PM
Sorry to hear about the trouble.

Not sure if it would help, but I have two mx106s that I'm not doing anything with right now that you can borrow.

jwatte
04-13-2013, 06:55 PM
Oooh! 106! :-) I just might take you up on that... if I do, check your PMs in the next few days. Thank you so much for the offer!

AVRnj
04-13-2013, 07:14 PM
Oooh! 106! :-) I just might take you up on that... if I do, check your PMs in the next few days. Thank you so much for the offer!

Seriously, don't hesitate.

I have two that are sitting on my desk and I won't do anything with them for at least a month, probably longer.

These bad boys are nice! Very powerful, very quiet!

I will check my PMs.

tician
04-13-2013, 08:35 PM
Yeah, the power line of the dynamixel bus. Slowly turning on the mosfet (~1 second or so) during servo bus power-up would help keep the initial surge of current in check, would it not?

Also, an "OH, SHIT!!" (E-stop) button is always nice to have when things go wrong, and now that my brain is finally on a bit of a roll I'm adding one of those P-MOSFETs onto the power line connecting the battery to Darsha's motor drivers (the existing button is only rated 10A, and I'm a bit paranoid) and a second to control the DARwIn-OP's tether.

CogswellCogs
04-13-2013, 08:48 PM
Very sorry to hear this. I hope you get your miracle.

Was everything working fine up until you changed leg brackets and added cooling fans ?

ArduTank
04-13-2013, 09:55 PM
that's why I like my HS-311s. They shut off if the power has too high of a voltage, then turn on again when the voltage drops.

KevinO
04-13-2013, 10:44 PM
Dynamixel will shutoff if they receive to high or to low voltage as well.

ArduTank
04-14-2013, 07:32 AM
Yeah, I know, but how fast is the shutoff?? Mine don't even turn on in the first place if you try to start them at too high of a voltage.

Jwatte: How many good servos do you have total? I might be able to suggest a design to use for mechwarfare.

jwatte
04-14-2013, 02:22 PM
Thanks for the encouragement!

I have seventeen servos. Eight are bad, nine are working, although two or three of those nine are what I'd call "sticky." I need fourteen for the actual mech.
I could perhaps build something with 2 DOF legs and elevation for the gun/camera, but that would be sad :-( Or maybe a biped with 4DOF legs and some aiming -- except I need to work this week, and all evening slots for the mill are already taken by others, so that'd be more of a stretch than I'd be likely to pull off.

I'm already planning ahead to do a biped next year or two, so I could buy spares instead of relying on Robotis turn-around time, except Trossen is all out of MX-64T.

ArduTank
04-14-2013, 06:17 PM
so, six good servos total. You could try a 3 servo biped, or with 2 more servos, make something like this: http://www.lynxmotion.com/driver.aspx?Topic=video01 Your six good ones in the legs, and 2 new or 2 of the sticky ones on top.

jwatte
04-14-2013, 07:41 PM
Or I could clone TwitchMX :-)

Meanwhile, I still don't know what kind of electrical problem took out these servos. The microcontroller I use (on a carrier board I designed) is fine, and the PC I used (drawing power from a power converter I designed, and that's on the same power bus as the servos) is fine, so whatever it was, it can't have been that powerful, given that my hobby electronics survived...

ArduTank
04-15-2013, 03:50 PM
What other wires ran near the cables for those servos, and what did they connect to. EMI on the serial line can possibly screw up the micro in the servo or if it's on the power line, it could have made the regulator in the servo start fluctuating just right for it to fail.

jwatte
04-16-2013, 10:53 AM
The lines are ground, power, and TTL in parallel -- all the way to the microcontroller, with the power board in the middle.

The power board has a 16V 5000W TVS between power and ground. I also had a 5.1V 1500W TVS between signal and ground, but it added too much capacitance so I had to cut it. I plan on replacing this with a Zener for at least some protection without too much signal degradation.

The way it works in detail is:

4 leg strands, each of which as three servos in serial. These come in to a 6-way Robotis power/TTL hub.
2 parallel connections from parallel hub to power board. Yes, this creates ground/power loops, but the amperage means both are needed.
Also, one strand of 2 servos (the turret) goes to the power board -- it has 3 total molex sockets.
The power board draws on a 4S LiPo, and contains a 1000 uF 35V electrolytic capacitor, a 22 uF 50V ceramic capacitor, and a 16V TVS between power and ground.
From the power board, that connection then goes on to a piece of protoboard, where the power is hooked to a 5V switching regulator that powers the cooling fans. The signal is just bridged from in to out on that board. Finally, the signal/power goes to the microcontroller carrier board, where the TTL is tied in with a 70 Ohm resistor to TXD and RXD, and the power is tied with a 10 kOhm resistor ladder to an analog in for voltage detection.

The servos that failed were in the leg, closest to the body and the Robotis break-out hub. Each of the "tip" servos survived; the two "closer" servos died. The turret survived. The microcontroller survived.
The power board also contains a 19V boost regulator to power the PC; the PC survived.

Given all this, especially the turret and microcontroller surviving, my guess is that the problem this time must have centered either on the Robotis hub, or one of the "hip" servos. The Robotis hub is fully passive, so the only thing that could have happened there would be some kind of short between power and TTL. Assuming all the connectors are okay, I think this is unlikely, because it's mounted in an enclosure that's fully powder coated (black plastic) and non-conductive, but to be safe, I will conformal coat the back of this hub for the next go-around.

If it's something with the actual servos, I don't know how to defend against that.

ArduTank
04-16-2013, 05:10 PM
So, the servo signals are linked to the proto board? If so, remove them from it. Actually, remove the protoboard from that area entirely. Take one of the extra ports on the hub to power the fans' regulator. If you have the servo serial cables near a regulator with both on a protoboard, chances are something on the protoboard shorted, and the nature of how the servos are linked saved the outer ones.

jwatte
04-17-2013, 01:02 PM
Note that the microcontroller is a lot closer to the proto board than the servos that failed. Also, the turret servos are closer to the proto board than the servos that failed. Neither of those failed. The proto board already has a coated back, too, so thus is unlikely to short out.

ArduTank
04-17-2013, 06:06 PM
Yeah, the micro has port protection built in, and the turret servos could have not taken any of the current. But I see what you mean. Your best bet right now is to emulate Twitch, or build a biped of some sort, unless you make something similar to CrabFu's turtle bot in leg design.

Slugman
04-17-2013, 07:24 PM
Only six working servos...... Can still make a 2 DoF legged biped with pan & tilt, but I'd hate to be looking through the camera while it's walking. >:P

jwatte
04-17-2013, 07:59 PM
Some good news: Kyle at Trossen and a service tech at Robotis have busted their butts to turn around my RMA in record time. FedEx says it'll be here tomorrow before lunch. Well worth the cost at this point!

Also, the tech turns out to also enter a Robomagellan bot in the same competition as my Money Pit, so that'll be fun to see :-) (And, in some ways, this hiatus means the Money Pit gets some work it needs to actually be able to navigate by Saturday... It hasn't actually locomoted with the new motors/steering/suspension/controller boards yet...)

I also just got some 5.1V Zeners from Digi-Key. They're kind-of high-capacitance (130 nF or so); I'm lowering the bit rate to 1 Mbit and will only use one at the split hub, and hopefully this will help. A uni-directional 16V TVS is also going onto the split hub power bus for good measure.

ArduTank
04-18-2013, 06:14 PM
lol. Fun

jwatte
04-18-2013, 08:44 PM
Arg! I'm having problems AGAIN!

I put a 5.1V Zener between TTL and GND, and a 16V unidirectional TVS between power and GND. (There was already a bi-directional 16V TVS)

I ID/d and configured the servos I had gotten back, and they all worked fine.

Then I got to the servos that I had previously declared "survived." And the USB2Dynamixel couldn't see them anymore. And neither could my microcontroller.
Measuring a bit showed that the Zener had failed, shorting TTL to GND.
No matter, I've got plenty of those. Quick replacement later, and I could start talking to the servos using my microcontroller.
But the USB2Dynamixel is still not seeing them. Did I kill it? It's possible.
Then, after trying a little bit more, the second Zener dies again.

Meanwhile, the first 8 servos that had gotten fixed all worked fine. So, at least one of the "survived" servos isn't actually healthy, and is killing my Zener. That, or the microcontroller board has some problem that slowly eats up the Zener. (Less likely, as the first Zener failed while I was still using only the USB2Dynamixel.)

So, again, I don't have enough servos :-( I'm going to send the ones that I didn't send previously back for service, and then try some other way to get this guy up and walking again. Perhaps for Kansas City? Any other events coming up this year?


The good news is that I will at least have some time to finish my Magellan entry now...

Gertlex
04-18-2013, 09:43 PM
Firstly, a gif is useful here (http://i.imgur.com/qI3YBpp.gif).

Secondly, I'm sure I'm not the only one of this opinion... My sincere thanks for being so persistent in figuring these issues out!

Finally, it sounds like there will be a Chicago event at some point. I'm not sure if anything actually occurred at the most recent KC Makerfaire.

jwatte
04-18-2013, 10:24 PM
Well, if anyone puts on an event, I will try to be there :-)

I think I have some vampire servo, which makes all the other servos dead. Just gotta rub them all in garlic and see which one withers...

ArduTank
04-19-2013, 03:03 PM
I'm trying to be at the Chicago one in 2014.

Vampire servo, lol.

Wouldn't it be possible to leave out the zener diode, and if not, why??

tician
04-20-2013, 08:54 AM
Just to make sure, the LED does blink once when powered, correct?

I somehow managed to kill the RXD (and only the RXD) of the dynamixel bus of a second CM-900 v1.01 last night and this time there was no chance that it was a short from touching an uncoated aluminium frame. The only thing I did over the course of an hour or two of attempted debugging was unplug and replug the two AX-12 and a HaViMo2 from an SMPS2Dynamixel a few times (CM-900 was always powered by SMPS and connected to USB).

I have the sneaking suspicion that it is the tri-state buffer not living up to its datasheet and getting one of its channels zapped. If the MX-series moved to the same tri-state buffer as the CM-900 (NC7WZ241 for space and cost savings), it might be the common cause of our problems. Digikey will be getting a bit more of my money monday, and I will know more once the buffer has been replaced. If not that, then the AND gate. If neither of those, then the STM32.

Also planning an N-MOSFET bidirectional level shifter (ala I2C app note) with dedicated 5V and 3.3V logic supplies with 5.1V and 3.4V zener diodes.

jwatte
04-20-2013, 07:50 PM
Just to make sure, the LED does blink once when powered, correct?

Yup.

I do not want to leave out the Zener. The whole point is that it protects the bus against spikes! The fact that the Zener blows means that the servo is putting spikes onto the bus that are bigger than the Zener can absorb (it's a 500 mW one, but it has a higher transient capacity.)

I previously tried with a 1500 W TVS, but the capacitance (2 nF) was too high, so it ruined the serial signal. I could run it at perhaps 250 kHz. The Zener has a capacitance of 130 pF, which is less than 1/10th that of the TVS.
Unfortunately, the super-high-performance parts (5W, 30 pF, and similar) are only available as surface mount. I think it may be time for me to learn how to do toaster oven reflow soldering...

tician
04-20-2013, 08:01 PM
I just place boards on a kapton-coated piece of 1/8" aluminium plate and stick it on the stove (electric), then watch and wait. Covering the workpiece would probably would make it faster, but it works well enough for small builds if you do not linger too long or try to do rework. I'm temped to get a sparkfun hot-air station, but I don't think I would use it enough to justify the expenditure (yet).

ArduTank
04-21-2013, 08:49 AM
You can hand solder SMT components, you know. You just have to be careful.

Th232
04-21-2013, 09:07 AM
What size are those SMDs and how's your eyesight/coordination? If it's SOT23 or 0805 sized then hand soldering should be fine, but things like 0201s are best stayed away from if you can. And then there're no-lead ICs and BGAs...

ArduTank
04-21-2013, 07:09 PM
I can solder any of them as long as it's not a BGA with a good tip on the soldering iron.

jwatte
04-22-2013, 02:18 PM
I've tried soldering QFP Atmegas before, and while the soldering worked well (no shorts,) the chip didn't work, so I probably overheated it through the pins. My approach was to first do a "tinning" step for the pads, and then put the chip down, and hold the iron across the pads, one side at a time, to melt the solder and let it stick to the pins.

The have a toaster oven with thermostat and timer at the workshop, so I can probably do it there; I just need to get an entirely new component bin...

escott76
04-22-2013, 04:40 PM
Doing QFP's isn't too hard if you use the right technique. As always a clean iron is essential. I use a liquid flux pen designed for this type of work, available at the usual suspects. No pre tinning of anything. I use what's called a "drag solder" or "hoof" tip, which has a tiny hollow to hold a bit of a ball of solder. You tin the tip, and then like the name says you "drag" it down the row of pins. Don't panic if you have a few shorts, after doing a few you get the timing and amount of solder to use and we will get rid of them in the next step. Then use some solder wick. A light tin of the iron is required to make this stuff work well, but not heavy enough to saturate the whole part. Lay some down over the pins in question, heat from the other side briefly and pull off before it has time to cool.
Reflow is a good technique, but evenly applying paste without a stencil can be "a challenge".

ArduTank
04-22-2013, 06:22 PM
If you go and set the part on the solder pad, then QUICKLY run the solder over it to get just enough for the pad, you're good. Try to use thin solder, it'll work better

Th232
04-22-2013, 07:31 PM
Well, while we're on the subject I'm genuinely curious:


I can solder any of them as long as it's not a BGA with a good tip on the soldering iron.

How would you go about soldering an IC with a heat spreader pad underneath? E.g. this part (http://cds.linear.com/docs/en/datasheet/3593f.pdf), the TSOT-23 version is easy, but with higher power levels the DFN package is required and turns into a problem for me with pad 7.

tician
04-22-2013, 09:00 PM
If you put vias through/underneath the heat/ground pad, it is possible to melt a small pre-applied dab of solder paste by applying heat to the vias from below. It might even be possible to use only a tinned footprint instead of solder paste (have not tested that to confirm, but experience says solder paste works fine). That said, if you have solder paste and lots of SMD components, why not just get a cheap laser cut mylar stencil from someplace like pololu and do hot-plate reflow? It's easier, faster, and safer to do (can re-arrange components easily and start over without damaging anything). Best of all, it requires less manual dexterity (I have very little of that and several scars to prove it).

Th232
04-22-2013, 09:09 PM
Yeah, I use a reflow oven for that kind of stuff but ArduTank's comment that I quoted made me curious to see if there was something I missed. There was an occasion where I had to reflow that exact IC but there weren't any vias underneath the pad, so I'm wondering how he would have gone about doing it. If there are vias then I do like that suggestion though.

jwatte
04-23-2013, 12:12 PM
why not just get a cheap laser cut mylar stencil from someplace like pololu and do hot-plate reflow

Even better: cut the stencil myself on the workshop lasers :-)

The reason I'm dubious about hot plates is that I've seen decidedly mixed comments about that when researching this on the interwebs. Meanwhile, the toaster oven option seems to work for everyone.

But, yeah. This is what I should be trying out. The main two things keeping me from doing it are inertia, and this large box of through-hole parts...

Th232
04-23-2013, 07:37 PM
If you want to try a hotplate, my suggestion is to have an easy way of removing the PCB from the plate immediately after the solder melts. I've seen some tutorials where they just let everything cool down before removing it, but with the thermal mass of some hotplates it makes me wonder.

Oh, and an aluminium plate to act as a heat spreader. Even some of our lab hotplates have only a circular element, definitely not good for reflow work.

tician
04-23-2013, 08:21 PM
Aluminium plate preferably covered in a non-conductive, non-metallic, heat-resistant material. Tried once on the stove without the kapton and some of the solder paste seeped through the many vias of the thermal pad and briefly soldered the board to the aluminium plate.

As soon as everything self-centers/settles into place on the molten solder, just lift the plate off the heating element with a pair of pliers. I place the ~3" square plate and boards on the grate of the built-in fan to quicken cooling since it is already on to help with fumes (~40 year old Jenn-Air electric cooktop).