Page 1 of 1

Encoder value limits?

Posted: Sat Apr 07, 2012 9:59 am
by lbarry
I am starting to use the rotary encoder board and the VB.NET software to talk to it. The API Reference says the events InputChange and PositionChange will "provide data about how many ticks have occured" but they do not specify the numerical limits of this data. What if the encoder gets a really high number of counts between events? Is the number of counts on the board or in the event API code stored as a byte? An integer? a Long? A single? I am using an encoder with 2500 pulses/rev so I will probably make the number wrap around, but I can't tell from this description if I need to worry about that or not.

Also, the API reference for both of the above events say that they do "not contain an absolute position. This can be obtained from getEncoderPosition". I can't find getEncoderPosition anywhere - even with a search of the API. Is there such a call? Am I missing something?

Thanks in advance to anyone with helpful information.

Re: Encoder value limits?

Posted: Tue Apr 10, 2012 8:35 am
by fraser
which encoder board are you using? (ie. the 1047 or the 1057?). Because each one has a different limitation to the maximum reportable number of pulses in an event. The 1047 has a maximum speed of 250000 counts per second. The 1057 has a maximum of 500000 counts per second.

So with the 1047 - your looking at 100 revolutions per sec maximum.
With the 1057 - 200 rev/sec maximum.

The encoder position is maintained for each indexed encoder, you can access it in position change events like this, assuming you have an encoder board named "phidgetEncoder" like in our example program

Code: Select all


Re: Encoder value limits?

Posted: Wed Apr 11, 2012 2:49 pm
by fraser
Forgive me, I made a mistake in my previous post. The definition on encoder pulses/counts is a obscure and often non-concrete one. We rate the 1047 at 250,000 counts per second, and there are 4 "pulses" per count. Thus a limit of 1,000,000 pulses per second. Assuming that your encoder defines a pulse in the same sense that we do, then you could see four times the maximum speed I specified in my previous post.

This of course does not apply if your encoder does not have the same convention as us.

Sorry for the confusion.