@jlp Mike designed the SSC-32 and wrote the firmware. If there’s anything wrong he will be able to help you figure it out. 
That is probably the best thing to do. Querrying the movement command status is just adding useless churn to your setup. You already know the value you are going to use for the servo position. Remember that the ssc-32 knows nothing about the actual position of a connected servo.
Isnt it just to measure the the Voltage on the middle soilderpoint in the potentiometer on the servo in question ?
No, the “Q” command only checks to see if the ssc-32 has finished sending its commands to the servo.
I thing you misunderstood … or i didnt explain enough
If you carefully take the servo apart, solder a wire to the middle of the three solderpoints , i think its called “the brush”, and then put the servo together again. Now you have a absolute feedback exactly where the servoposition is, if you can decode it, and its quite simple: You just move the servo to one end, for example 500us, save the voltage, then move it to 1500us and save the voltage. Now if you have a reading of for example 3,26V you can easely calculatre the exact position where (in us) the servo is
hrmmm… was this explanation understandebal ?
Please observe, i have NOT done this IRL, but if you have spare analoge inputports it souldnt be a problem … i think …
Not the same.
Yes you can read the wiper of the pot, and calculate its position, but that has nothing to do with the Q command. The Q command will respond with + when the command has executed.
To use the voltage read from the R/C servo pot in a positioning system, you are essentially creating a ‘P’ (proportional) controller (simple closed loop).
Alan KM6VV
you are right
I just thoght it was an easy answer to jlp initial question, whithout solving the initial cause of the problem… because it was certanly way over my head…
@zoomkat
it was a very nice “Proof Of Concept”, did you use it for anything after that ?
No, I just did it to see how it could be done. It is more practical to query the last position sent to the servo when some event happens. Below is a test of that idea.
The C++ code in attachment shows the trouble with the Query Movement Status :
If you compile the code as given (adding main and rs232 subroutines) you should find
the servo from time to time freezes for half a second. Now, if you comment the query
cycle, the servo performs at a higher rate and never freezes.
I am still not sure where the problem came from; eventually a cause may be our own
RS232 send/receive methods…
checkServo.cpp (2.25 KB)
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:
