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.
No worries @kurte Thanks anyways for replyingâŠ
@cyberpalin Actually the reference examples is what helped me ! I had a nose around in the examples section. Thanks anywaysâŠ
In this case it is just the Querycommand âQâ
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: 179In 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.
@cyberpalin - You will get mad at us, but the servo is not leaving the âHoldingâ status in EM0. Itâs in âHoldingâ mode all the time since there are not motion controller active.
If you are in EM0, what are your settings for the motion engine (i.e.: buffer depth and rate)? With default settings your values would be average (IIRC) over a 5 position input in a WEMA filter.
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.
QDT vs QD would make sense.
Not workable since the servos cannot read the TX line at this time (physically/electrically) and therefore youâd get collisions (with 2 or more servos).
To be fair here, EM0 modeâs motion engine can also be set to auto-repeat your last input (and thus saturating the buffer).
Therefore, that would lead you to your desired position with smoothing.
You should probably turn that on if that is what you want to have it do.
Was playing with a variety of settings but for the last test was AngularStiffness = -4, holding stiffness = 4 and fpc was not set but did try changing it to 2. Canât remember if it got better.
What settings would you recommend.
FPC should be an odd value for best results. Values of 3 or 5 seem to produce good results for others before. @dialfonzo ideas here?
ok understood - was just a thought. Thanks for explaining.
Ok how do you do that? Will give it a try - as I said let me know what you are recommending.
As a just a thought maybe some of this stuff needs to get added to a knowledge base for the servos somewhere. Lots of good info going back and forth here.
The Wiki would be the natural place for this kind of stuff, I think.
Did try fpc=5 but still had the same issue. But will try again with anything that might help. As I said I am pretty sure the servo is going where its suppose to but no way to confirm.
EDIT: think we are cross posting now 
The intermediate position motion system is controlled by the IPE set of commands:
IPE/QIPE/CIPE*;
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).
Wondering now if some of @kurteâs problems are related?
@dialfonzo - know this is going to sound nick picky but are there any other gotchas we should be aware of when in the different modes (guess EM0). Doesnât have to answered right this minute.
As long as you donât also do IPE1 in EM0, youâll never get to your final position without sending the same value multiple times; therefore saturating the WEMA filter.
With IPE1, the server will internally, every 20 ms (4x 5 ms control loops) reproduce a âvirtual commandâ to the last position requested until it reaches it physically.
Therefore, this just saves you the trouble of sending a bunch of commands every 20 ms like you would do in previous setups (with RC servos, for example).
I guess no one read my previous posts on EM=0 then? 
There are a few on the forum⊠and Iâm pretty sure we discussed it in this topic a while back, too⊠
Ok thanks - have some more reading to do. Donât mind setting up for session only or on power recycle.