So the servo would not answer to that query, can you narrow it down do one specific query ?
There is a chance that you are getting a value back before it actually finish the movement.
Query is done right after the movement and even if it take (too long) to answer it could be a earlier position.
NB: I know it will sound obvious, but if queries are not throttled there are chances that multiple servos answer at the same time on the same bus.
It is called from the CycleStance command code, which is called with the ‘i’ command
Note: I am thinking of hacking this command a little to check Serial for extra letter where
it - would try to move by time (MoveT)
is - Would try to move by servo speed - No member function to do this in library.
im - Just does the Move command
i - would do the default… which would be set by previous use. and default to it…
Again you can always sink up to my test project, and maybe make your servos/default setup match our current version. If your servo numbers are different, the test program does have quick and dirty command to renumber a servo… OR we can write another quick and dirty sketch to renumber from X to Y commands…
Again the method call that tries to do the move of all 18 servos is cycleStances.
The call that does the cycling of calls to query, where these failures happended was: checkStatus2
I thought about that so in the second run I added a query to test the servo to see if reached the hold position and then did the getPostion. In all cases the servo returned “HOLD” then getPosition returned incorrect results:
i: 1, move: 357
Status Loop CNT: 1: 6
Returned Postition: 438
i: 2, move: 268
Status Loop CNT: 1: 6
Returned Postition: 408
i: 3, move: 179
In partial dump you see I commanded the servo to go to 357, did the query 25ms later for status and it returned ‘6’. Then when I did the getPosition after the status it returned 438? Pretty sure the servo moved to the correct position because it winds up where its suppose to be.
You got to be kidding. Would have thought that regardless of the EM the servo would still give you back status. So how the heck do you know that you ever when you reach position without putting in an crazy long delay per move.
Ok how about this for a recommended improvement going forward. When the servo reaches its target position regardless of mode it automatically returns something move complete ack message.
You guys have some work to do between getting status working for EM0 and moveT working for EM1. But have to admit comm is much much improved - I am running at 921K with 3 servos.
The intermediate position motion system is controlled by the IPE set of commands:
IPE0 is the default state; IPE1 will get enable the motion system to generate intermediate positions between where the servo is internally and your target positions: it will get there while applying the filter for smoothing motions (starts & ends).
Of course, FPC & IPE are only applicable in EM0 and only with D command at this time (AFAIK).
*:I don’t think CIPE is implemented, so only session value at this moment (i.e.: IPE would need to be set manually every power cycle).