So it occasionally takes 500 ms instead of 200 ms for the Q command?
Maybe your RS-232 receive function is getting blocked by something else in the PC?
Just a thought.
Alan KM6VV
- Yes, from time to time, the servo get stuck and the difference factor may be higher than the
mentioned one, apparently as much as 200ms and 1 sec - Effectively, as mentioned, the RS232 send/receive methods we wrote may be the cause of the
unexpected behavior nevertheless these same methods perform without trouble when we shunt
the Query cycle. This is not a full proof because there is much more communications when the
Query cycle is present. - If someone may use its on RS232 library to communicate with the SSC-32 with one servo connected
on port 0; we could confirm (or not) these results.
I went back and re-read the thread. You never mentioned what sort of hardware you are using. Is it RS232, or USB to serial? If it’s USB to serial what adapter are you using? If it’s FTDI based, change the latency to the minimum. This will help. The SSC-32 as stated before can have delays (50uS to 5mS), but nothing like 500mS or more. The most likely culprit is the serial system on the PC / embedded PC…
Also as stated before. You can achieve great results by defining the time, send the commands, then waiting precisely for that time to elapse, then issue the next command. You can even subtract the time required to send the command from the equation. This will be more precise than relying on the PC’s serial system to pass data, although RIOS uses it quite effectively. 
Good luck…
Hi Mike,
the previous posted CCP code should answer most of your questions; I have not monitored the stream.
Thanks.
- You are right, I use USB to serial; tomorrow I will repeat the test with another converter and/or on a PC with a RS232 output… (my converter label is unreadable)
- “send the commands, then waiting precisely for that time to elapse, then issue the next command” is what I am doing in the test code; I also agree that I could avoid the query command and programmed my own to bypass RS232 but… anyway I’d like to understand…
Below is the code I used with my foot contact test. It worked with out issues using a noname USB to serial adapter.
'ssc-32 (SSC32-V2.01XE) servo control using Just Basic.
'6 second timed move, stopped when "VC" analog input is
'grounded and reads less than "228" (foot switch, etc.).
'22k resistor connected between +5v and "C" input
'to keep "C" high at +5v (~"255" value) until grounded.
oncomerror [handleIt]
'set comport value to the one you use
open "Com8:9600,n,8,1,ds0,cs0,rs" for random as #comm
Print #comm, "#0P2200T1000" 'put servo to initial position
y=1 'outside loop counter set to 0
[loop]
print "step ";y
print "starting 2 second start delay"
timer 2000, [delay2] 'iniial delay before timed move
wait
[delay2]
timer 0
x=0 'inside loop counter set to 0
Print #comm, "#0P700T6000" 'start timed servo 0 move to 700
[loop1] 'inside loop
x=x+1
y$ = "VC" 'used for analog input
Print #comm, y$ 'request digital input value from ssc-32
timer 20, [delay] 'read return delay
wait
[delay]
timer 0
dataRead$ = input$(#comm, lof(#comm))
num = ASC(dataRead$)'used for analog data
if num < 228 then Print #comm, "STOP 0"
if num < 228 then [jump]
if x < 160 then [loop1] 'set for number of samples during move
[jump]
Print #comm, "QP0" 'get last position sent to servo
timer 50, [delay3] 'delay to allow data to be returned
wait
[delay3]
timer 0
dataRead$ = input$(#comm, lof(#comm)) 'get returned data
print "voltage byte is "; num 'print out raw servo position
print "position byte is "; dataRead$ 'print out raw servo position
print "servo position is "; ASC(dataRead$)*10 'convert position into ms
timer 500, [delay4] 'delay to allow data to be returned
wait
[delay4]
timer 0
Print #comm, "#0 P2200T1000" 'send servo to start position
print ""
y=y+1
if y < 11 then [loop] 'set for number of loops
print "done"
Close #comm
end
[handleIt]
print "Comport error! Check settings and status."As I mentioned the Query instruction works globally fine but do not allow real time…
A recent test on a PC with a RS232 port (thus without USB-serial adaptator) shows
a different behavior, the servo do not stuck but sometimes do not respect timing
between steps and similarly to previous tests using Query make the process very slow.
So the best solution is definitively to compute the required delays inside the controler
and do not use the Query instruction.
maybe you can help me with this:
