Questions on mutilple query

[collapsar]

I’m wondering wether I can query SSC-32 for mutiple information (movement status, digital inputs and so on) at a time? just like a group move?
Or I can only query one and wait until the response? and what if no response received within a certain period(longer than 15ms)?

[collapsar]

And one more question, can I query when the previous command is still on going?

[nickreiser]

::scratches head::

A guess:
I believe that you can go right ahead and asynchronously request multiple responses from the SSC-32.
Since moving the servos is the #1 goal of the SSC-32, it queries such requests until it’s free to respond.
As long as you don’t overfill this querry space, it should work.

Just keep in mind that what comes out is going to look very similar, so it might get a bit hairy…

[robotdude]

@collapsar

I’m wondering wether I can query SSC-32 for mutiple information (movement status, digital inputs and so on) at a time? just like a group move?
Or I can only query one and wait until the response? and what if no response received within a certain period(longer than 15ms)?

@collapsar

And one more question, can I query when the previous command is still on going?

I was going to try and answer this, but I found an email from Mike that should help you.

@mike

I am going from memory here, aided by knowledge of how I usually do things. In other words, I don’t have the code in front of me but I am fairly confident of how it works.

If you want the position of servo 2, use “QP2”. This will result in 1 byte returned, either immediately or with a delay, depending on the firmware version.

If you want the positions of servos 1, 2, and 3, use “QP1QP2QP3”. Spaces optional. This will return 3 bytes, either as fast as possible or with delay/pacing, depending on the firmware version. You can do (I think) up to 16 servos this way.

Of course, you could send three separate commands: “QP1”, read result, “QP2”, read result, “QP3”, read result. But this will be much slower than all at once.

In general, I allow any query commands to be grouped like this, even different types of query. So you can do “QP1AL VA QP2” and it will return 4 bytes. The spaces in this command are required due to the use of commands that do not take numeric arguments. The SSC-32 buffers the bytes for transmit, in a buffer that is (I think) 16 bytes long. So don’t request more than 16 bytes at a time.

Of course, there is the general caveat with the QP command that the SSC-32 does not know the actual position of the servo, only the position being command through the pulse output.

I look at the forum every once and a while and am overwhelmed with the amount of information there. I appreciate that you send me pointers to things that I should be aware of or reply to. Otherwise I would probably miss a lot, or at least have long latencies in my response time.

Mike

Hope this helps, Jim

[miked-6]

I’m glad Jim was able to find that email, because I appear to have lost it.

Most versions of the SSC-32 firmware will blast the response bytes out as fast as possible, which we discovered is too fast for some Basic microcontrollers to keep up with. The latest version, 1-06XE, inserts short delays before starting to transmit and between bytes.

As a previous poster mentioned, response to queries is lower priority than moving servos, but still the response should start within a millisecond. The servo pulses are interrupt-driven, so the SSC-32 is not very busy most of the time. What would really slow it down is sending a long group move command immediately followed by a query. Then the query response would be delayed while the SSC-32 crunches on the move.

I guess one thing the email didn’t address was the question about sending a query while the previous command is still going. From the SSC-32 perspective that will work fine, but it might make the response harder to interpret.

[collapsar]

Thanks for all your reply! They do help a lot.

And I’m wondering if there’s a buffer length limit fortransmit which might be 16, then is there a limit for the receiving buffer and how long is it?

I guess one thing the email didn’t address was the question about sending a query while the previous command is still going. From the SSC-32 perspective that will work fine, but it might make the response harder to interpret.

Well, what do you mean by “harder to interpret?” Thanks!

[miked-6]

The receive buffer is 128 bytes, but it is being continuously emptied so it unlikely to fill up even with very long commands. For example, a group move using all 32 servos with speed and position can take over 400 bytes to transmit, and the SSC-32 can process it at full speed (115.2k). But as I mentioned before, if you follow this long group move with an immediate query command, you will probably end up waiting about 10ms for a response to the query while the SSC-32 chews on the group move.

As far as the “harder to interpret” comment, I was refering to the specific case where the previous command was a query command. i.e. you send a query command and, before getting the response to that command, send another query. There are a few potential problems with this:

1. It will be more difficult to associate queries and responses. A received byte won’t necessarily be in response to the query you just sent, but might apply to a previous query.
2. If a query or response is dropped for some reason, it will be more difficult to detect.
3. Some microcontrollers cannot transmit and receive at the same time.

Maybe I misunderstood the original question. A query is acceptable at any time, regardless of what the SSC-32 is doing. If it has just received one or more group move commands, it will reply to a Q command with the status of the last group move command received, and will reply to a QP command with the position of the servo requested. All queries will return the appropriate value even if a move is in progress.