I will try to be clear and concise as that seems to be an issue here when people ask for help.
I am connecting an ssc32 to an FPGA via direct serial.
I have connected the grounds between the two boards and have also connected the RX and TX pins(viewtopic.php?f=2&t=5440)
The board is being powered by a 9v battery and is isolated from the servo power.
The packs are supplying 6-7v across the first rail(when i multimeter the pinouts for servos, they read at apx the pack voltage. This seems correct.)
I have servos connected to ports 0 and 1.
The baud rate for the fpga has been set to 115200.
Now that the setup is out of the way, I will talk about the problem.
When i initially turn on the ssc-32, the green LED illuminates.
It remains on untill i give it a command. At this point it goes out(i assume it flickers to fast for me to see it) or flickers slightly.
After this occurs, none of the servos move.
As a test, i looped the serial output of the fpga. When i constantly send strings, the LED on the ssc-32 flickers.
This is the string i am sending:
I do not have a usc-serial connector so I am unable to connect the system to the computer directly to test it. I was just curious if anyone here had any ideas before i spend the next couple days waiting for the cable to i can trouble shoot. I am on a relatively tight schedule.
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.
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.
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.
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?
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.