Hello, I’ve assembled and have been testing with your serial 16 controller for about 3 months. It worked fine until a couple of weeks ago in pololu mode.
Now, when I power up the controller, the yellow light comes on (as normal), but when I send it a command (any command) the red light comes on and the yellow light flashes.
I went back and ran your initial test by shorting the S input with one of the servo grounds, and all 4 light came on as they should. I also check to see if anything was shorting out the connections on the board, and they all looked ok.
I’m using a simple basica program to run the commands to the controller at 19200 baud.
Ever seen this before?? Is there someway to “RESET” the controller if it has a bad value in it??
The 16-servo controller has no configurable parameters so there is nothing to reset. Does it work in Mini SSC II mode? The error LEDs you are describing indicate that the controller thinks the baud rate is too slow; are you sure you’re using 19200? Have you tried different speeds?
I’ve tried testing with speeds ranging from 300 to 38400 baud in Pololu Mode, and get the same steady red, flashing yellow leds each time. I used the jumper and tried both 2400 and 9600 baud to test with sscII mode, and still get the same steady red, flashing yellow, making me think the sscII mode isn’t working?? I did power off the controller before each test, and tried it with and without servos connected.
Also, I tested the port of my computer with an old sscII 8 port controller and it worked fine. I did modify my code to 9600 baud first.
My computer port is set to 108000 baud, so any value less than that should work ok.
I’m suprised as the controller did work fine for a couple of months. It is securred by the screw holes to a solid box and is pretty well shielded from dirt etc… Can you suggest any other tests or tips?? Thanks…
Well, there isn’t much between the DB9 connector and the PIC microcontroller that is the heart of the servo controller. If you have access to an oscilloscope, you could look at the logic-level serial input pin and see if the serial data is coming in well. Alternatively, you could use a microcontroller to generate a logic-level serial output and try to connect through that logic-level input pin (don’t connect to the DB9 connector at the same time). If you don’t see good data on the serial input or if the microcontroller method works, you could check your solder connections on the two resistors and transistor that make up the RS-232 level conversion circuit.
If you can’t do the tests or cannot get it working otherwise, you can send it back for us to take a look at it.
Jan, thanks for the tips. On further testing, I’ve found that it works better if I power on the controller after I issue the “open” command in my program. It’s hard to trace the serial port without an osciliscope as you’ve suggested, but maybe the open command is putting garbage in the com buffer that’s screwing up the controllers ability to determine the baud rate. I’m guessing your controller doesn’t care about the open command, and just reads data from the port expecting a certain sequence of characters over a specific period of time.
I downloaded cgywin and your test application, which seems to work pretty well. I love the idea of having linux run in a window instead of having to boot another os! I wanted to use basica instead of C because its easier to convert to pic basic if I want to create self contained programs to run without the need of a computer.
I’m glad ther doesn’t seem to be any mechanical problems with my soldering or the hardware of the controller. Thank you for your help!