Thanks @dialfonzo (and @cbenson ) for trying it out. Will try your change at some point, right now working on other projects, like working extending the File System support on Teensy (FS/File classes) to support Dates and Times…
In cases like this, I keep asking myself what is the proper goal when you find what appears to be a repeatable issue. Often times my answer will be different depending on things like. Is my goal to get the get the project done, or is it to try to solve the problem. Often times it is somewhere in between.
For me, as I have nothing pressing for me to release something, my instinct is to leave the example in a state that the firmware developer can hopefully identify the issue and hopefully find a proper fix. Yes maybe you can add additional stuff to the query and maybe mask the issue, maybe happen with 4 items queried, by may with 5 or … But gut tells me, it may depend on what other things are going on within the Servo firmware at the same time.
And maybe there should be several more examples like this, to test, like convert this slot type requests into a long query string and see if that makes a difference…
But the real question I have to ask myself, how much does the changes in this firmware release apply to what I was trying to do, and as such how much time to spend on it.
That is the main parts of the Hexapod code dealing with servos, is probably 90+% writes and a few percentages doing query.
The one part that I set that applies is that the Servo position (degree) command we should be able to start all of the servos at the same time… I have not verified this yet.
For me, I still have two fundamental issues, which this release does not appear to address at all:
a) Reliable communications: The test sketch is sending out move commands twice per second and it usually does not take more than a few iterations before one or more servos obviously moves wrong. Note this is repeatable without the query involved as well.
This is saying either:
- The data is being corrupted, probably due to longer distances, voltage changes, EMI, …
- The servo just screws up and maybe forgets something like Gyre or offset or …
I am guessing 1)
b) EM=1 is not usable for most programs that do any multiple step moves… i.e. the start, coast, stop behavior of each command, there was some interesting posts on this thread about it, but so far it sounds like no changes to address this have been made.
So that leaves us still needing to use EM=0 mode. Which I find frustrating that in this mode if I tell a servo to some position, it may or may not. You may have to tell it something like 3-4 times to actually go there before it believes you…Personally I don’t understand the reason for this, unless it has to do with a workaround for unreliable communications?
So then if your code needs to output 50+ moves per second, which implies a 20ms cycle, how much data can you query during each cycle, or does it make sense to allow the query to span multiple servo cycles…
Kurt
)
