So, between these two descriptions there is a conflict. Either the nMotorEncoder value is actually an int. Or there is something wrong in the way the encoder value is being returned and the long is being truncated to an int someplace.

This came up because we have an arm that travels vertically, by chain. If arm begins at the bottom and we zero the encoder value; A full travel from bottom to top and back to bottom again results in not returning back to '0' but instead the value is approximately 5000 above that. A second travel up and down again results in being about +5000 off.

So I got the idea from the nMotorEncoder description that the motor might be advancing past the 90 rotations and causing the value to wrap. Then it occurred to me that a long should be able to accommodate this and not wrap so quickly. Thus I discovered the inconsistency.

Any input into any of these issues?Thanks!

Sun Jan 20, 2013 5:42 pm

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1512

Re: API documentation errors with nMotorEncoder, what is rig

I think the API guide is wrong. A "long" is a 32-bit signed number. It can hold approx. +/- 2G. Having said that, even if the nMotorEncoder is a 16-bit signed value which holds +/- 32K, it will take over 90 revolutions to overflow it. Did your arm motor really travel more than 90 revolutions one way? Assuming the travel range of the arm is about 180 degrees and the encoder is mounted on the motor shaft. For the encoder to overflow, you must have a gear ratio of greater than 180 to 1 (i.e. 90 revolutions on the motor resulting in 180 degrees displacement of the arm). It would be quite difficult to achieve that kind of gear ratio with the textrix sprockets. I have a feeling that 32-bit versus 16-bit is not the problem.

EDIT: Actually, if you have a US digital quadrature encoder with 360-line optical disc, it will generate 1440 counts per revolution (4 times of 360). Even with that, your gear ratio would have been 180/4 = 45 to 1. Still too high in reality, so still unlikely in my opinion.

Last edited by MHTS on Mon Jan 21, 2013 4:56 am, edited 1 time in total.

I have just confirmed that the API is incorrect and the revolution count range for a Mindstorms encoder is -2,147,483,648 to 2,147,483,647. I apologize for the confusion on this and thank you for bringing it to our attention, I will make sure this gets updated properly.

I believe that the chain travel is about 4 feet. And it is geared at 2:1. Could it be making 90 revolutions? Yes, I actually believe so. But we have to focus a bit more on that.Could there be a truncation issue from casting the long to an int all over the place? more likely.

Someone else pointed out to me that the Tetrix encoders are 32bit. And the NXT motor encoders are 16bit. So, this can easily lead to confusion taking examples intended for one and applying them to the other.

Hmm, that's an interesting thought. Do you know how the NXT reads the NXT motor encoder? I would imagine on Textrix, the counting is done in the Textrix motor controller and reported to the NXT via I2C messages. But the NXT motors are dumb devices, so I would expect two of the motor port pins must be channel A and B of the encoder and the counting is done by the NXT. Furthermore, I assume nMotorEncoder[] is an array of LONGs and the NXT firmware periodically updates this array by reading all the NXT and Textrix encoders. So it all boils down to what is NXT encoder's "counter width"? This is probably a question for the RobotC folks.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum