I have experienced communciation failures with two SSC-32 boards and need help in figuring out what to do.
I have a robot consisting of 10 servos – 6 HS-475’s, 2 HS-645’s and 2 HS-1422CR (continuous motion). I have been controlling the robot from my PC (running VISTA) using the Lynxmotion Sequencer. Everything worked fine for a couple of weeks then suddenly, in the middle of a sequence, the robot stopped responding to the SEQ commands. No matter what I tried, I could not re-establish communication with the SSC-32. I purchased a second SSC-32 figuring that there was some anomaly or that I blew something on the board. Again, the same story. It worked fine for a couple of weeks and then stopped communciating with the SEQ in the middle of a sequence.
I have checked all cables, tried different PC’s, checked power, tried different batteries, etc. and the problem is not there. I am running the logic from a 9V battery and the servos from a Lynxmotion 6 volt Ni-Mh pack.
Interestingly enough, when I load a sequence into the Basic Atom Pro and connect it to the SSC-32, it runs fine. It just won’t communicate with the PC. I have tried the “ver” test in LynxTerm and get no response. When I power up the SSC-32, the green indicator LED lights up. When I type “ver” or any other comand from LynxTerm, it turns off. For each command send, the LED blinks, but I get no response on the screen.
Since this is the second board that this has happened to, there must be something systematically wrong – but I can’t see it. Are there any diagnostics that I can run? Please let me know if anyone has suggestions.
I have serious doubts that the SSC-32’s at fault. Are you using a usb to serial cable? If so you will want to read some of the sticky posts pertaining to them. Short story a setting called latency can be the culprit. Also the read and write buffers must be equal. There are also the usual make sure no other program is trying to use the serial port… The SEQ also has a feature that allows you to adjust the timeouts for the program. Another way to test the SSC-32 is to used the free LynxTerm program. If it routinely responds to the VER command but the SEQ will not, it’s a sure sign timeouts are needing to be adjusted.
I have tried to connect with Lynxterm but was unsuccessful. There was no response to the “ver” command. I don’t think the problem is with the timeouts because it has worked fine for several weeks before failing. Is there anything else that I can try?
The baud rates could be mismatched. You can also remove the two tx/rx jumpers on the board, then replace one of the jumpers across the outboard tx/rx pins so what ever is sent from your computer usng lynxterm will be sent back to your computer. If you get the echoing back of what is sent, then you know that part of the communication link is working.
I have tried several computers using LynxTerm, including one with a true RS232 serial port. Still no go. I also tried linking the tx/rx pins as suggested. I do get echoing, but I get the same echoing if I power down the SSC-32.
I have tried all the different baud rates but the result is the same.
So, I’m not sure what to try next.
The weird thing is that I have no problem controlling with the SSC-32 from the basic atom board through the tx/rx pins. Do these pins use different circuitry or are they in some way merged with RS232?
Since I can’t communicate through the PC, is there a way to check out what is going on in the SSC-32 through the basic atom.
Did you set the baud rate in lynxterm to the same baud rate set on the ssc-32? I think the default setting in lynxterm is 9600 and the factory jumper setting on the ssc-32 is 115200. I’m supprised you get the echoing with the ssc-32 powered down, but at least you know you are sending something from the computer.
There is a setting in LynxTerm in the Setup section called Echo typed characters locally. It is enabled by default. This lets you see in the window what you are typing. That’s why you see characters typed even with the power off. For a useful test remove the two (vertical) jumpers from the db9 enable and place just one (horizontal) to connect TX to RX. This is closest to the bottom of the board if you can read SSC-32. Now with the power on you should see two characters for every keypress. One if the Echo typed characters locally is disabled. If this doesn’t work, then there may be trouble with the RS232 driver.
We may be getting a little off track here. The PC you are using is the most likely culprit. You suspect the SSC-32, get a new one and same trouble. This points to the PC not the SSC-32. Have you installed any other programs, especially suspect if it uses the serial port? I have also read of a logitec driver that prevented the Atom IDE from working.
I have tried using LynxTerm with 3 different PC’s with the same result. In fact one of the PC’s has an RS232 serial port. I also changed all the slider and latency settings as recommeded on the forum posts. Still nothing.
I happen to have a serial cable from another project with one of the DB-9 connectors cut off. I identified the tx, rx and ground pins and hooked them to the appropriate pins on the SSC-32 (tx to rx, etc.). I used an oscilliscope to try and figure out what whether signals were being passed back and forth. In LynxTerm, I used the ver test and “all 1500” to send a signal. The oscilliscope showed that the signals were transmitted from the PC but nothing was sent back to the PC.
Just wanted to wrap this one up. We received the two boards and found the DB9 connectors were bent up and some of the pins were broken. We replaced the DB9 connectors and viola they worked again. Turns out the boards were being used on a bot capable of climbing stairs, and they took a few tumbles in the process. Hope to see images of the bot.
If this doesn’t work, then there may be trouble with the RS232 driver.