A 1 AMP power source is NOT going to be enough to run an arm - any arm. Get this Regulated Wall Pack - 6.0vdc 3.0amp and you should have the power you need. It sounds like your SSC-32 is resetting due to not enough power from the wall wart.
8-Dale
Your issue is probably due to the fact that for 13+ years you have been working with equipment using stepper motors and now you are dealing with servos. If you want to work with servo based equipment, then you will need to get up to speed on servos and how they work.
Nope. Not a stepper in the machines. All Servos. Some with DC servos others with AC servos.
Then if you are going to use “hobby” servos, then you need to get up to speed on “hobby” servos and how they work. You may also need to read up on the capabilitys of the ssc-32. Some people make the mistake of thinking a $500 hobby/educational robotic arm has the same capabilitys as a $500k industrial robotic arm. The common arm position solution is to park the arm in a resting position when shutdown, then start the arm at the same position before making any moves from the rest position. You might try the ssc-32 servo “speed” function to see if it does not require a known previous position. You can always look for solutions in the software that is controlling the ssc-32, or possibly read the voltage from the servo pot wiper to determine the approximate current position of the arm.
Yup. The ‘servo’ in hobby servo is a misnomer. It has no feedback, so its not a servo by definition. Its open loop just like a stepper. (without a tacho, encoder, resolver)
wow! 
Nope!
The typical R/C servo has an integral pot for position feedback.
Alan KM6VV
Well the truth is a hobby servo does indeed have feedback, or it wouldn’t be very useful. We call it local feedback, meaning the servo has feedback so it can move to a commanded position, but the device telling it where to go does not have any feedback. You can call it unacceptable, but we do have a lot of fun making cool robot arms and legs using them.
i say… dont let the limitations stop you.
Just cross-posted over to the BM forum.
Older post, but I think I may have a solution to the fast-startup problem for R/C servos. (Isn’t there a current thread on this, I couldn’t find it).
I’ve mentioned and I’m sure others know about running servos from a desk power supply at lower voltage for initial tests in order to “weaken” or slow down servos so they don’t destroy themselves.
In talking with a UK robotics friend, he says he varies the frame or refresh rate of his servos in order to control the stiffness of the “electronic spring” effect of R/C servos. 20 mS is normal frame time, if the frame time is lengthened to 25 mS, there is a noticeable “softening” of the servo. Up to 100 mS is often useful. He varies all of his servos times, not fixed by interrupt code in the uP.
My question,
Can we add variable frame time to the SSC-32 (or BB-II for that matter) to allow a choice of frame time? That shouldn’t be too hard, assuming adequate memory time, and perhaps a handle for the parameter. Ideally it would modify groups of servos, on the fly, at a minimum even just an initial, one-time setting of the frame time would be useful.
Actually, the benefits go further then just start-up. Making a servo “softer” makes for much more complaint walking, moving arms, etc. as well.
Alan KM6VV
You may want to look into the ssc-32 servo speed function. The timed servo function requires a known previous position, but the speed function should not. My ssc-32 is not available for testing.
I knew about that, it helps. This would would actually make the servo “soft”.
Alan KM6VV
Um, what? 
No it’s still required to know where the servo is before either speed or timed moves can be achieved.
I am highly suspicious of the frame rate and power supply solutions. Sounds like smoke and mirrors to me. All I ever experienced when slowing the frame rate was ugly…
That is a bummer for a speed function. Current position should not be a requirement. Maybe something to modify if the firmware is ever updated.
Hi Zoomkat,
I personally don’t think there is much the servo controller can do, as it has no feedback from the servo to say where it is. All it can do is send the servo a the initial pulse of some specific width and the servo will jump to that location as fast as the servo wants to. What the Speed or Time functions do, is knowing where the servo is and where it wants to be, it can choose how much of a delta in pulse width to send to the servo for each servo pulse cycle.
That is why for example with my Rover with Arm, I would try to have the arm go back to some known rest location before it is turned off and the first command to the Arm is to move to that rest location… That way hopefully the servos don’t move very far.
Kurt
Ah yes, that’s true that if the servo is not in an assumed inital physical location, the first incremental move will be a wild card. Probably some involved possible solutions, but starting the arm from a known relaxed servo “parking place” is the practical solution.
Could be, I have not personally tried it yet. I have some C code driving servos directly, might be able to test it there. This guy should know…
Might be just a quick patch to put into the SSC32 code to change the frame rate for a test, if Mike (?) is interested. Could be very useful if it works!
I often back off on the power supply voltage for new servo implementations, it does reduce the torque; less chance for damage if a servo is driving into the stops.
BEST BET, have a “Kill” switch handy…
Alan KM6VV
Or Keep some spare servos handy 
Kurt
Mike’s into the new SSC-32 design up to his elbows. We’re simply not making any new firmware for the old version.