You previously posted “Tried it on a “old” Dell with serial port and it worked fine!” so it probably isn’t the ssc-32 unless it has been damaged since you did that test. Now noting that it will not also work on “the” dell laptop (assuming “the” dell has the factory windows install) is another data point. Do you have basic basic electronic test equipment such as a multimeter and jumpers?
Note that the jumpers need to be oriented correctly across the tx/rx pins. If they have been removed and replaced 90 deg out across the pins, then the connection with the board is lost.
Bought it all direct from yourselves and shipped UPS.
As per diagram running vertically, North to South!
I’m still going to contact Active Robots to see if they can test the board for you. Like I said before I don’t mind replacing it if it’s defective. I’m not wanting to replace it on a whim.
I suggest that the ssc-32 be retested on the “old” dell to verify it hasn’t been damaged since the time the board origionally tested good on the “old” dell.
It will no longer run on the Windows XP Pro SP2 Dell.
Device Manager says USB-Serial running fine. Brand new Duracell Plus 9v battery.
Same scenario as on the MacBook Pro running Windows XP Pro SP2.
Green light stays on and no version returned when “ver” typed.
The machines are adjacent to each other and just take the USB cable out of one and plug in other.
No hardware changes have been made at all, no jumpers changed etc. Built as exactly as in the Assembly Guide.
I’ve got an email in to Active Robots. Waiting to hear back from them. Will have an answer next Monday. Your board will be replaced if necessary. They will be shipping the replacement if needed. I know you have been working on this for too long, but it’s Apples fault they can’t properly design motherboard USB ports. 
Hang in there.
Great. Thanks for everybodies help.
Just to sum up what seem to be the facts so far:
-
ssc-32 oriionally worked great on an “old” dell with a “real” serial port.
-
USB adapter appears to work on a mac running windows, but the ssc-32 does not respond.
-
“It will no longer run on the Windows XP Pro SP2 Dell”. Is this the “It will not work on the Dell Laptop.” mentioned in a previous post?
So, the ssc-32 origionally worked on an “old” dell when you got it (aka, ssc-32 wasn’t broken when delivered to you). Your statements seem to indicate that the ssc-32 origionally worked on a “Windows XP Pro SP2 Dell” but now it does not. Is the “old” dell with a “real” serial port the same computer as the “dell laptop”? Just trying to sort out what you have actually tried and the associated equipment.
Yes. Direct Serial Port & the USB-Serial
.
Yes
No longer works on my “old” Dell Laptop. Green light doesn’t go off.
Yes
“Old” Dell = Dell Laptop
Yes. After trying on my Intel MacBook Pro booted into Windows XP sp2 I tried it on my “old” Dell (Laptop) and it worked for three or so days.
Today when I tried it got the response posted above.
Also mention previously the 9v battery is draining power. A new battery I used yesterday was down to 5-6 V today. Could something be shorting on the SSC-32 board and using power when it’s switched off?
My ssc-32 does not have a power “switch”. How are you switching yours off? If the green LED is lit it will eventually run the battery down.
an interesting contradiction is that while the loop back test worked you report the green light on the ssc-32 never goes off. what is so unusual about this is the green light goes off if any sort of communications activity makes it to the microcontroller, even if it’s bogus commands or the wrong baud rate. so what this suggests is somewhere between the db-9 connector and the micro controller there is a break.
I’ve got another type of loop back test to suggest if you are willing to try it. The two jumpers labeled 14 in the user’s guide are on the TTL side of the RS-232 converter. there are two parts to that jumper block, a 3-pin portion and a 2-pin portion. If you were to remove the jumpers and use one of them to short across the 2-pin portion you would be looping the TTL level TXD to RXD and forming a loop-back connection. Using the lynxterm program, based upon your earlier results, you should see the double repetition of characters typed if the loopback is intact.
What this specifically allows you to determine is whether the fault is before or after the jumper block 14. If the loop back works then I would look for a bent pin on the Atmel microcontroller… it might look like it’s in the socket but could be bent under the device. If the loopback doesn’t work then off hand I would look more closely at the db-9 on the board and see if it has been damaged, or if any of the parts around U2 such as the caps C3 through C7 have been damaged. I recall a troubleshoot problem some months ago where we went round and round with some guys who it turns out had rolled their rover down a flight of stairs a number of times (or something like that which they never mentioned) and they had bent the DB-9 back and forth enough to make a connection fail. my point being that the fact your ssc-32 worked on the dell for a bit and now doesn’t is making me wonder if you don’t have some sort of mechanical intermittent going on. If the controller chip on your ssc-32 has been upgraded then it is possible a lead bent under rather then went into the socket when the new chip was installed. If the db-9 got flexed or even had a cold solder joint on a pin it could result in intermittent operation. Lastly it’s possible an ESD handling event could have damaged either U2 or the micro. I’m not saying any of this happened of course but just throwing out some ideas to explore in trying to figure the thing out. The jumper block 14 loop back test may help resolve to more detail exactly where the failure is occuring.
The AL5D Robotic Arm has two power switches, one for 9v battery and other for Servos.
Get double characters. Type ‘ver’ get ‘vveerr’.
AL5D Arm. It’s not going anywhere!
It sounds very much like the connection between the pin of the Atmel chip and the jumper block 14 header is not made… or the Atmel chip itself is hosed in some way.
Got a digital multi-meter handy at all? Going to ask you to measure a couple voltages and check for continuity (ohms) at a couple spots…
lol, ya I realize that but I was just using an example of where something not readily obvious and very mechanical was the culprit and the board had to go all the way back to RobotDude to actually figure out they had broken it themselves. it was mostly an attempt to get folks thinking outside the box is all. 
Ready and waiting …
Did you try the loopback test at #14 on the board?
Yes. Read posts above.
Removing the jumpers at #14 and using the multimeter, on the 3-pin section you should find a connection between the left tx pin at #14 and chip pin #3 on the below diagram, and a connection between the center rx pin at #14 and pin #2 on the below diagram.
edit: another quick test would be to very carefully connect pins #2 and #3 on the atmel chip (use the tip of an allagator clip or similar to jumper across the two) and do the letter echo test. If you don’t get the vveerr, then there is a bad connection somewhere between the chip and the board tx/rx pins. If you do get the vveerr, then check between pin #7 and pin #8 on the chip to see if +5v is present.
second edit: I tried jumpering across pins 2 and 3 on the chip on my board and do not get the echoed letters or a response from the chip. As such this test probably won’t be useful.
Went to my Dad’s yesterday and connected the AL5 D Arm via the USB-Serial adaptor to his Dell Desktop with Windows Vista with latest SP etc.
Let Windows install the appropriate drivers. Worked first time, could get the version number and move the arm through LynxTerm.
Came home. “Cleaned-up” Dell Laptop ("Old Dell) running Windows XP SP3 and attached the USB-Serial adaptor, let Windows install the drivers. NOTHING.
Rebooted and used the serial cable (supplied by LynxMotion) from the serial port on the Dell Laptop to the AL5D arm. Light continuously on. Shows COM1 connection in device manager and all working well! (sic). From LynxTerm CANNOT get version number or move the arm. Light stays on.
Uninstalled the drivers for the Serial-USB adaptor, cleaned registry. Rebooted. LynxTerm is still showing COM3 in the drop-down list. Though the device Manager only shows COM1 and LPT1 available.
The Mac is off to Apple for some warrenty work tomorrow whilst I’m on holiday for a week.
It is now getting crucial/critical I have committed to providing a working demo of my application using a Robotic Arm to a major worldwide toy manufacturer. I have a lot riding on it.
I have written Active Robots and they have agreed to test your SSC-32, and replace it if necessary. All you need to dois make contact with them to get their address. You have just reported the SSC-32 is working fine on the desktop machine. If time is so critical then why don’t you just purchase another SSC-32 from Active and see if it helps. If it does you can return the first one to them for credit and we will replace their controller.