Folks…
For the last 18 hours I’ve been trying to get my new SSC-32 to communicate with my old BS2e board to control my newly rebulit hexapod 2. I can drive the SSC=32 fine from lynxterm… but when I try to drive it from the BS2E I have problems. I can’ t get them to communicate reliably, i.e. I can’t seem to send simple servo positioning commands or anything else predictably. I have the BS2e attempting to read and write through the TTL-level serial port of the SSC-32. Occaisionally the SSC-32 will cause one of the servos to react… but only once in a while. I’ve tried all sorts of different board settings. I’ve use the following code snippet to try and send/receive a simple response to the ‘VER’ command…
serStr VAR Byte(20)
baudr VAR Word
baudr = 79 ’ I’ve tried 84,16468 , etc. the board is configured for 9600 b
Doit:
SEROUT 8,baudr,“VER”,CR]
SERIN 10, baudr, Bad_Data, 10, No_Data, [WAIT(“SSC”), STR serStr\8]
GOTO done
No_Data:
DEBUG CLS, “Timed out”,CR
GOTO doit
Bad_Data:
DEBUG CLS, “Parity error”,CR
GOTO doit
done:
DEBUG “test=SSC”,STR serStr,CR
Output is a sporadic… ‘test=SSC32 1.03x’ more often a time out. I’ve found the baud setting of ‘79’ by wrrting a simple ‘trial and error program’ to find a baud rate that works. At this rate the SSC-32 will respond correctly with the firmware version (SSC32-1.03x) some of the time… but I still can’t get the SSC-32 loaded with a gait to drive my hexapod 2. The predicted ‘84’ that should correspond to 9600,N,8,1 doesn’t work.
I’m beginning to think this is voltage related because the communication is so unreliable. I’m running the logic from both boards of a common 9V battery… the grounds are common. I have the SSC-32 jumpered for VS1=VS2, 9600 Baud and TTL level Serial communications. The SSC-32’s VS1 and Vs2 are strapped and tied to a seperate 7.2V NiMH battery… All battery’s are fresh. All waveforms look good on a scope…Any idea? I’m going nuts !
Since no one with any SSC32 experience piped up, I’ll toss out a few ideas I’d use to try to debug it.
Since you’ve got a scope, simplify things: Eliminate the 7.2 supply and disconnect the servos. You can still scope for the pulses but it’s not necessary until you get your version header responses.
If you have a TTL to RS232 level converter, attach it between the BS2e board and the PC. Run a term program and ensure that the data makes it to the PC at the expected baud rate. If that checks out, also connect it between the PC and the TTL level ports on the SSC32 and ensure that’s working as expected too.
You’ve said the boards share a ground. There is a GND pin right at the TTL serial pins on the SSC32. If you aren’t already, use this instead of just sharing the common ground on the supplies.
The wires you’re using for a connection between boards shouldn’t be unreasonably long. If you’ve got something over say 2 feet, try something shorter.
When scoping the serial data, ground the scope to the GND pin on the SSC32 and watch the TX on the BS2e. Check voltages.
The baud mode for the SSC-32 is inverted. So it’s 84 for 9600 baud, I just tested it with that, and with 6 which is 38.4k baud. I know the stamps are a bit slow, and I haven’t personally tested the bidirectional comms with a BS2, but simple servo positioning is perfect.
SEROUT 15, 6, "#0 P1600", 13]
PAUSE 1000
Hope this helps! Jim
I’ve run into the same problem except I have a basic atom pro28 with the botboard that I am using with the SSC32, I can send commands all day long and they work just fine, however I cannot see a responce back from the SSC32, even when I send a command to move a servo (#0 P2250 T10000) while the servo is moving, I send out the Q command, followed by 13(cr).
Right after I do a serin command and I get nothing but timeouts. I have tried different wires, separate power supplys for the SSC, just about everything.
Software version on the SSC32 is 1.06XE
Serial comms is set to 2400 on the SSC and the AtomPro.
Here is part of the code that I am using:(trying to get a responce to VER)
I will ask the obvious. Do you have both serial input and output setup between the SSC and Bot Board? On my Hex, for example, the instructions for the complete H3-R Hex only has us set up one jumper with two wires between the two. So the Mini AAB can output to the SSC, but not get any inputs back.
I just found something odd, my settings were for the correct baud rate was wrong, which I have corrected, HOWEVER I find that I can only get this to work at 2400 baud. I tried all the way up from 38,400 baud and worked my way down to 2400, funny thing is that commands sent from the botboard work at every setting, but to receive I need to be set at 2400 baud, confusing, however I think that 2400 baud will work out okay.
Here’s the updated code snippet which will show 1.06XE everytime
Another thing you might want to try is the hardware serial port. I believe on the PRO28 P14=RXC and P15=TXD
You can then use the HSERIN and HSEROUT commands. You will need to enable them first (ENABLEHSERIAL) and SETHSERIAL.
I was about to try these on when I was trying to get a serial LCD to work on the PRO, but I was able to get it to work at 2400 baud reliably especially when I disabled certain interrupts while outputing to the LCD.
Actually I have been working on this all night, what I found is this:
I have to be at 2400 baud
I can send the VER command, the first few characters are garbage, the rest I can use.
IF I send just the Q command I never get anything back, HOWEVER if I send VER Q, then I get back garbage, then the version and then the status (Q gives me the status of the current operation).
I am going to try the hardware way you mentioned now and see where I get. I am also thinking about making a DB9 connector and hooking it to the SSC DB9 with the wires then going to the Botboard and using it that way.
I think this is a AtomPro issue, I even tried the setbaud command for the atom pro, and the funny thing is that the first time I send out a VER command at i2400, then I can receive at the setbaud rate “SSC-1.06XE” perfectly the first time.
It works! All the way up to 38,400 baud with the hserin and hserout commands. Do not get back any garbled data either, just had to have a short delay (10ms) added in when the program starts.
So maybe I am right and it’s a bug with the atomPro?
I know when we were testing the firmware for reliable queries we had to add a delay before sending the response, and a pacing delay in order for it to work with a BS2. We were capable of doing bidirectional comms at 38.4k baud with the BS2 and Atom 28. We didn’t test the Atom Pro at the time. We added a 600uS transmit delay and a 70uS pacing for the query commands.
My guess is that the serin and serout commands are software loops and these loops may not take interrupt overhead into account. For example I believe I heard that enabling HSERVO commands puts a 3% overhead on the PRO. So if the delays or loops within ther serin/serout commands do not take this into account, the timings for the different baud rates may be out of spec. Likewise if you enable any other interrups, such as timers or external inputs. But again I am guessing!
I think that the serout command on the Atom Pro works fine.
The Serin command however needs to “settle” by receiving more than one character in this case from the SSC32. I was able to get partial information when doing a VER command from the AtomPro.
The information before the actual version number is always garbage using serin, however using hserin, everything comes out, even at 38,400 baud.
