How many characters can the SSC-32 buffer before sending a to it to execute a command?
I could not find this info in the manual.
8-Dale
Taking a quick look at some older version of the code, I think it has a 128 byte input buffer. However this may not necessarily imply the answer. I don’t remember if the code starts parsing the data before the CR or not…
Kurt
I’m not sure it’s really important to know the buffer size, but I would like to know in case I run into weird behaviors, and/or so I can properly limit the lengths of commands I send to the SSC-32.
If it starts parsing right away, then knowing the size of the buffer may not be relevant.
8-Dale
Has there been update on this question.
I plan to send about 20 servo commands in a group and want to be sure that the system wil either hold them in it’s buffer, of dprocesses immediately until it gets a
A 3DOF hexapod routinely gets 18 or more servo commands. 20+ if there’s a tilt/pan on it.
Alan KM6VV
Hi Alan
Many thanks for such a prompt reponse.
So I am correct in that I can send about 20 grouped servo commands and then set them in motion.
Take Care
Dave
Yes, we do this all the time with the phoenix code as well as code that is generated by powerpod…
Kurt
Many many thanks for you help.
Definately looking forward to when my SCC-32 board arrives (currently in transit)
I’ll be using it with a FEZ Mini so it will be a very powerful syste,
Take Care
Dave
To get back to the original question. I know the SSC-32 can update all 32 channels in one command. Not saying it’s a limit, but I know it can handle taking care of all 32 channels at once.
The SSC-32 processes incoming characters as they arrive. The 128-byte input buffer is only used to hold a few milliseconds of characters that might arrive while a lengthy command is being processed. For example, if you send a 32-servo group move command, after you send the , the SSC-32 needs several milliseconds to do all of the calculations to start the servos moving at the correct speeds. During this time, it is not pulling characters from the input buffer, so any newly arrived characters will be saved in the buffer. The SSC-32 will start removing them from the buffer as soon as it finishes processing the last command.
The SSC-32 command processing was designed to be able to handle a 32-servo group move (almost 400 bytes if speed is specified for every servo) at 115200 Baud. In fact, it should be able to handle a continuous stream of such commands without a pause, although this would push it to its limits. I tested this worst-case scenario early in the software development, but have not tried it lately.
Mike
Hi Mike
Thans for the valuable information
A quick question - you mentioned the that SSC-32 need a few milliseconds to process the commands, how does that affext servo movements during that time.
For example if a servo was connected to a pendulum to simulate a clock - would you see the servo pause or stutter with a long command comes in.
What I will be doing is to draw a timeline graph of the servo positions and read the timeline into 500ms slices. I will be feeding the servo position of each slice to the SSC-32 every 500ms so the a servo would be almost at the end of its movement when it recieves the information for its next position.
Many thanks for any advice.
Take care
Dave
Dave,
Servo pulses are interrupt-driven, so they continue during the command processing. The 20ms loop provides plenty of time to process incoming commands and update servo positions for the next loop, so there should be no pause or stutter in servo movement. In my testing I have simulated processing long commands while servos are moving, and I believe there is adequate margin in the timing.
Mike