Using PIC18 MCU..SSC receives data..on 1.5ms pulse on line

greetings experts…i warrant your great knowledge…

I using a PIC18 MCU to send out serial commands to the Pololu 8 servo controller, thats working fine the SSC receives the data cause the GRN LED flashes when I send them, however the only output I’m getting on the signal pins of the SSC is the 50Hz signal with 1.5ms pulse width 7.5% duty cycle that the manual says is the neutral position command. No matter what I send tot he SSC it won’t generate a different pulse.

I read about the servo numbers configuration, tried changing that so its in 0-7 range still no luck. any advise would be greatly appreciated.

What communication protocol (Pololu or Mini-SSCII) are you trying to use, and do you have the mode jumper set properly (jumper off for Pololu mode, on for Mini-SSCII mode)?

Also, could you post your PIC code here?

The green LED flashing indicates that the servo controller is receiving bytes that it can properly interpret (i.e. it auto-detected the baud rate properly, and isn’t seeing any frame errors) but that doesn’t necessarily mean that it’s receiving bytes that it knows what to do with

-Adam

i9m usign the Mini-SSCII mode…9600baud rate here is my code…very simply just want basic movement to start

void main(void)
{
TRISDbits.TRISD4 = 0; //output

//baud rate of 9600
OpenUSART(USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE  
    & USART_EIGHT_BIT & USART_BRGH_LOW, 15);

while(1)
{
	PORTDbits.RD4 = 0;	//reset controller
	PORTDbits.RD4 = 1;
	
	putcUSART(0x80);
	putcUSART(0x02);
	putcUSART(0x00);	//set controller range 0-7

	Delay10KTCYx(250);
	Delay10KTCYx(250);
	Delay10KTCYx(250);
	Delay10KTCYx(250);
	Delay10KTCYx(250);	//wait a while (5sec)

	putcUSART(0xff);
	putcUSART(0x07);
	putcUSART(0x80);	//move a servo

	Delay10KTCYx(250);
	Delay10KTCYx(250);
	Delay10KTCYx(250);
	Delay10KTCYx(250);
	Delay10KTCYx(250);	//wait a while(5sec)
	
	putcUSART(0xff);
	putcUSART(0x07);
	putcUSART(0x64);	//move the servo again
	
}

}

nothing complicated just move to start

The command to set the servo mode will only work in Pololu mode (with the mode jumper removed), and the servo controller has to be reset after this to be used again. I would just take this part completely out of your code, you don’t need to mess with the servo numbers.

It looks like you’re sending correct commands for MiniSSC-II mode, but you should try adding another delay to your code after you send the second command. With no delay, your main loop is resetting the servo controller immediately after commanding the non-neutral position. You then immediately send another serial bite, which in MiniSSC-II mode sets all of the servo positions back to their neutral positions by default.

Did that take care of it? Can you see the signal changing (or your servo moving) now?

-Adam

Adam

I moved the reset to outside the loop, Ive tried setting it to different positions however all i get it still the 1.5ms pulse…its won’t change, nothing changes

I tried all servo signal output pins they are all giving me the same signal

Hello, did you actually try adding another delay at the very bottom of the loop after the final servo command as Adam suggested? What happens if you make your program be simply:

putcUSART(0xff);
putcUSART(0x07);
putcUSART(0x64);

while (1);

- Ben

hey Ben I jus tried that…i just don’t know…its wont move from the signal position. could it been an issue with that servo number, I am addressing them incorrectly. I am sending the correct sequence. At this point I just don’t know.

Hello,

I think you should verify that the servo numbers are set correctly on the servo controller. To set them back to the default of controlling servos 0-7, put the controller in Pololu mode (jumper off) and send the sequence: 0x80, 0x02, 0x00. You should see the green LED flash approximately once per second. (You can see more details on page 8 of the user’s guide.)

Don’t forget to put the jumper back on (and reset) before sending Mini SSC II commands!

- Jan

Jan

I tried that, I get a solid YLW and slow blinking RED

The red LED flashing indicates a fatal serial error, usually caused by something lik extra junk on the serial line or the serial line staying low. You can try pinpointing the problem by sending one byte at a time and finding out when the LED begins flashing.

- Jan

I am trying to use the pololu now seeing I was unfruitful in getting the MiniSCC Mode to work at all.

I tried sending a few bytes in Pololu mode but still not movement, this time Im not even getting an pulse anymore.

Can someone please provide an exmaple of a byte sequence to be send in Pololu mode. I just cant figure this out.

Pololu mode is a little more involved than Mini-SSCII mode, but is also a lot more capable. It sounds more like you’re having a serial communicatoin problem than a command string problem, but it’s worth a try.

The standard Pololu mode command is a start byte (always 0x80), the device type byte (always 0x01), the command type byte (my favorite is command 0x04, absolute position with two-byte accuracy), the servo number to apply the command to (lets try 0x00 for servo 0), and one or two data bytes specific to the command.

Here are a couple of Pololu mode test strings:

{0x80, 0x01, 0x04, 0x00, 0x17, 0x38}
This command string should produce a 1.5ms pulse on channel 0

{0x80, 0x01, 0x04, 0x00, 0x1F, 0x20}
This command string should produce a 2.0ms pulse on channel 0

There’s a little more discussion about how to pick the data bytes for the mode 4 absolute position command here.

Do you see the right pulses?

-Adam

I tried your command suggest Adam and got no pulses at all no movement at all.

Since you have an oscilloscope to look at these pulses, you might also take a look at the serial signal out of your PIC, and see what the bytes look like and what the actual baud-rate is.

I would suggest you keep trying in Mini-SSCII mode until you get things working (its just a lot simpelr). What happens if you put the mode select jumper back and load this as your program:

void main(void)
{
TRISDbits.TRISD4 = 0; //output

//baud rate of 9600
OpenUSART(USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE
& USART_EIGHT_BIT & USART_BRGH_LOW, 15);

PORTDbits.RD4 = 0; //reset controller
Delay10KTCYx(250);
PORTDbits.RD4 = 1;

putcUSART(0xff);
putcUSART(0x00);
putcUSART(0x00); //move a servo

while(1);

}

You should 1.5ms pulses on most of the servo lines, but a much shorter pulse on the signal line of servo 0. If not you might try other servo numbers, or a loop that cycles through the range of servo numbers, but I doubt your servo number range has been changed if you had the mode select jumper on when you were first testing.

-Adam

I’m back again, still cant get this thing to work with my PIC18.

I have used the Pololu COM1 communicator program to verify that the servos work, and they work fine, I have verified that the SSC works.

My final conclusion is that there is an issue communicating between the PIC18F452 and the Pololu SSC board.

Is anyone aware of what the sink/source current requirement is for the Pololu SSC board is? I have been informed that this might be the issue, of why the SCC unit is receiving but not responding to commands.

Once again help, greatly appreciated.

Sorry about the delayed response; I’ve been out of the office since the 18th. The pull-up resistor on the servo controller serial input is 10k (the “pull-up” is actually just in line with the RS-232 level shifter output, but that goes high when you’re not using the DB9 connector), so it should not be an input current issue at all. The setup with that pull-up means that the RS-232 signals will show up as TTL signals on logic-level pin if nothing else is connected, so you can look at that on an oscilloscope and compare the working signals to the ones coming out of your PIC.

- Jan