Female Professional Golfers Association 
An FPGA is a Field Programmable Gate Array.
It allows parallel processing in real time.
For the purposes of the question, just think of it as a microcontroller.
Without a computer with a serial port, not much else available to do some testing.
I’m curious why you have the DB9 cable plugged in and why you have one of the DB9 enable jumpers installed. Because the data normally goes through a level shifter (max 232) I believe you need to invert the data send from the FPGA. We invert the data when talking to the SSC-32 from an Atom.
Because the LED is blinking this means the SSC-32 is receiving data. Baud rate is not the issue. So it’s got to be the data format.
I assumed that the ssc23 was still handshaking with the other board when receiving data. Do i only need to use the RX pin then? I was also under the impression that since I am not sending any data i can simply bridge the TX pins. It was so i wouldn’t loose the bridge component because it is tiny.
I am also curious if you know what the maximum application frequency of commands is for the ssc32.
for example: could i send it 10ms commands every 10ms?
Whooooosh! That’s the sound of that entire paragraph going right over my head… In other words. What? 
What other board?
The SSC-32 generates the servo pulses every 20mS. Because of the advanced method of setting up the servo commands using either Speed or Timed options. There’s really no advantage to sending pulses more than, say 30mS. I mean why send commands faster than the SSC-32 can respond to them. 
I believe RIOS sends commands to the SSC-32 every 33mS.
Sorry. By other board, I meant the FPGA. I am not pulling any data from the ssc-32 so I assumed that the TX pin on it could just be bridged.
For the second part, you answered my question perfectly. Thank you.
Ok I think I got it now. So the FPGA is sending TTL data to the SSC-32 via ground and RX. No need for anything to be connected to the DB9. Normally when TTL data is selected (non DB9 mode) both jumpers are removed. So yes the SSC-32 does not need to talk to the host unless the host asks for data.
The exception is when you want to read the version number from the SSC-32, or wait for a move completed response. Some of the code around here waits for this response.
Alan KM6VV
Same thing. 
Alright. I bought a serial-usb adapter and am able to control the servos using lynxterminal so the ssc-32 is working properly. Any ideas with why the FPGA is not correcty communicating?
Hook it up to a terminal, and see what it’s sending!
Got a CR/LF on the end of the lines?
Alan KM6VV
You never really acknowledged my comments on data inversion… “We invert the data when talking to the SSC-32 from an Atom.”
I am unsure what you mean by “inverting data”.
I attached the serial out on the FPGA and took at the data in lynxterm. Here is an image of 3 consecutive commands which were output by the FPGA and read by the computer.
The spacing of the commands received on the lynxterm screen indicates that there are a lot of bytes possibly being sent that aren’t ascii viewable characters (assuming you didn’t type spaces and enters on your keyboard). You might download the free PortMon program to run on the computer along with lynxterm to see what is being sent. Set portmon to show the sent bytes as hex instead of ascii so you can see all the bytes.
It looks to me like you probably are not outputting any CR characters to the SSC-32, but instead out outputting several LF characters.
I am not sure what types of commands you use on the FPGA to output lines. If you are using some form of command like in VB of WriteLine, you may need to configure what the New line character is. Alternatively you may try to do the simple equivalent of a Write statement where you pass it a buffer and length and manually make sure you output the CR character. I sometimes do this in VB for example.
Kurt
Nah, he’s just getting a couple of LF (line feed) characters out, and none of the CR (carriage return) characters.
Data is OK, no “inversion” problem.
Put in some CR characters!
Alan KM6VV
You are right, looks like ~4 line feeds on the end of the command.
Thanks a lot you guys! Its working like a charm. Ill post movies/images of the project once its underway. Its a 3-4-foot diagonal hexapod
Glad to hear it! Looking forward to seeing the videos!
Alan KM6VV