Command to read both encoders at once?
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Command to read both encoders at once?
The manual has not been updated yet. It usually takes longer to get that updated than the sample code and libraries.
Re: Command to read both encoders at once?
I think latest is 4.1.16. It works with command 78 for me.4.1.6
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Command to read both encoders at once?
Yes, the current firmware(release version) is 4.1.16. The QA version is 4.1.17 but may have bugs(hence the QA). We encourage people to use the QA release and report any problems they may find.
At this point we are nearly ready to make the release version 4.1.17 but we are going to hold off a little longer since this version had a fairly major change in the IonMotion software and we want more feedback.
At this point we are nearly ready to make the release version 4.1.17 but we are going to hold off a little longer since this version had a fairly major change in the IonMotion software and we want more feedback.
Re: Command to read both encoders at once?
Robogames are in ten days. I'm not changing anything right now
Re: Command to read both encoders at once?
If command 79 is like a combination of commands 30 & 31, would it be possible to add a command that is like a combination of commands 18 & 19 ?
Thanks a lot,
Colin
Thanks a lot,
Colin
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Command to read both encoders at once?
We could but we felt there was no value to it. The Speed values are running averages(1 second average) so are already significantly delayed. The added milliseconds to exectuing a second GetSpeedMx command didnt add signficiant value. The GetISpeeds command(79) was more appropriate since if time was a factor you would probably want to work with the instantaneous speed and do you own filtering.
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Command to read both encoders at once?
In general we dont see those bits being used often. The GetEncoders command was setup to be as fast as possible for reading the current encoder positions. For the extended information you will need to use the individual commands.
P.S. Based on your description Im not sure your calculation is correct. The direction bit indicats the direction the count moved since the last read(eg up or down). However the encoder value is still the aboslute count since the encoder was zero'd(except after an underflow or overflow). I recommend you send a code snippet so I can confirm what you are doing works correctly. Just multuplying the value by -1 when the direction bit changes doesnt sound right.
In most cases it is best to use the encoder value as a signed long(Int32_t for example). Unless you will be overflowing/underflowing the count(+-2billion) this elliminates the need to look at the status bits.
P.S. Based on your description Im not sure your calculation is correct. The direction bit indicats the direction the count moved since the last read(eg up or down). However the encoder value is still the aboslute count since the encoder was zero'd(except after an underflow or overflow). I recommend you send a code snippet so I can confirm what you are doing works correctly. Just multuplying the value by -1 when the direction bit changes doesnt sound right.
In most cases it is best to use the encoder value as a signed long(Int32_t for example). Unless you will be overflowing/underflowing the count(+-2billion) this elliminates the need to look at the status bits.