Kit opto encoder resolution?

[flameout]

What is the resolution (in pulses per turn) of the KOP's optical encoders? I need to find out the scaling value to plug into the open VI for the encoders in LabView.

The datasheet says "400-1440" ticks per rotation. This is obviously not helpful. Also, I assume you don't have to specify the quadrature decoding type, right (1x, 2x, or 4x?) I would assume it gets that right without modification.

Thank you for any help.

[apalrd]

Last year they were 250, 1x. this year they are either 350 or 360, I can't remember which. I would set it to 350 1x. We honestly don't need more than around 12 counts in 4x decoding, or more for 2x or 1x decoding, since the mechanical error is great enough (especially with a little chain slack) that we could be off by as many as 100 counts using the KOP encoder, depending on gearing.

[Vikesrock]

Originally Posted by apalrd

Last year they were 250, 1x. this year they are either 350 or 360

360 counts per revolution for this year's KOP E4P-360-250-D-D-D-B encoders

[Joe Ross]

Originally Posted by flameout

Also, I assume you don't have to specify the quadrature decoding type, right (1x, 2x, or 4x?) I would assume it gets that right without modification.

The decoding type can be used on any quadrature encoder. If you want to count the rising and falling edges on both the A and B channel, choose 4x. 2x does rising and falling edges on only one channel, while 1x only counts 1 edge on one channel. If you are using the encoder for position only, using 4x gets you extra resolution. If you are trying to use the rate function, you'll probably have better results with 1x. Choose whatever makes sense for your application.

One cool thing you can do with the scaling is get the encoder value in a measurement you want to use. For example, if you want to measure angle in degrees, put in a 1 for the scaling. Each tick will then be 1 degree (since the encoder has 360 ticks per revolution). Alternately, you could calcuate using your gear ratios and wheel size that each tick makes the robot move 1/10 of an inch. Put in 1/10 and then you will get the distance the robot traveled in inches.

[ericand]

Originally Posted by Joe Ross

The decoding type can be used on any quadrature encoder. If you want to count the rising and falling edges on both the A and B channel, choose 4x. 2x does rising and falling edges on only one channel, while 1x only counts 1 edge on one channel. If you are using the encoder for position only, using 4x gets you extra resolution. If you are trying to use the rate function, you'll probably have better results with 1x. Choose whatever makes sense for your application.

One cool thing you can do with the scaling is get the encoder value in a measurement you want to use. For example, if you want to measure angle in degrees, put in a 1 for the scaling. Each tick will then be 1 degree (since the encoder has 360 ticks per revolution). Alternately, you could calcuate using your gear ratios and wheel size that each tick makes the robot move 1/10 of an inch. Put in 1/10 and then you will get the distance the robot traveled in inches.

Using the 2x and 1x, raises the question of which edge does it detect? I'm running into problems getting a good count of the encoders and I'm thinking the problem is that we have been using an old IFI robot controller theory of operation.

Our setup on our test setup has the encoder output going to a BaneBot encoder divider. This was done previously to allow us to use hardware to divide the counts of the A channel and latch the direction (B Channel) to preclude any latency issues when reading it on the old controller.

Our final robot will not have the dividers, but to save time, they were left on the practice chasis and the A and B signals were taken from the divider to digital I/O on the cRIO.

In this configuration, we are not getting any counts (getraw() returns 0, 1 -1) regardless of how much we move the robot. However, scoping the outputs of the encoders and the dividers shows that the signals are being generated as expected.

I suspect that the cRIO is getting confused since the B channel is not pulsing, but remains constant while the robot keeps moving. I'll be able to run more experiments on Thursday, with the encoder divider out of the picture to see if things work better.

I suspect it would be good to have the cRIO have a library call that would allow it to take advantage of hardware like the BaneBot divider, but given the current set of interfaces, I do not see how it can be done. I could set up a counter on the A channel, but I don't see how I can get an interrupt when the B channel changes so I can properly apply the direction to the A channel count.

[Joe Ross]

Originally Posted by ericand

I suspect it would be good to have the cRIO have a library call that would allow it to take advantage of hardware like the BaneBot divider, but given the current set of interfaces, I do not see how it can be done. I could set up a counter on the A channel, but I don't see how I can get an interrupt when the B channel changes so I can properly apply the direction to the A channel count.

I believe you can set an external direction input for a counter, which should do what you need.

[Ether]

Originally Posted by Joe Ross

The decoding type can be used on any quadrature encoder. If you want to count the rising and falling edges on both the A and B channel, choose 4x. 2x does rising and falling edges on only one channel, while 1x only counts 1 edge on one channel. If you are using the encoder for position only, using 4x gets you extra resolution. If you are trying to use the rate function, you'll probably have better results with 1x. Choose whatever makes sense for your application.

Forgive me if this has been asked and answered elsewhere; if so I haven't found it yet:

Per the above explanation, if 1x is reading only one channel, it wouldn't know which way the encoder is spinning, right? So the rate information with 1x wouldn't tell you whether the rate is positive or negative, right?

So if you wanted a rate that contained direction information, would you have to use the 4x?

[Joe Ross]

Originally Posted by Ether

Forgive me if this has been asked and answered elsewhere; if so I haven't found it yet:

Per the above explanation, if 1x is reading only one channel, it wouldn't know which way the encoder is spinning, right? So the rate information with 1x wouldn't tell you whether the rate is positive or negative, right?

So if you wanted a rate that contained direction information, would you have to use the 4x?

There was a long thread (maybe last off-season) that went into a lot of detail about the encoder algorithm.

The 1x, 2x, and 4x only denotes how often measurements are made, the method of measurement is the same. In 1x, 2x, and 4x, the state of the opposite channel is used to determine direction.

[Ether]

Originally Posted by Joe Ross

There was a long thread (maybe last off-season) that went into a lot of detail about the encoder algorithm.

The 1x, 2x, and 4x only denotes how often measurements are made, the method of measurement is the same. In 1x, 2x, and 4x, the state of the opposite channel is used to determine direction.

Thank you. I was slogging my way through that long thread but not finding the answer I was seeking.

[buildmaster5000]

Originally Posted by Vikesrock

360 counts per revolution for this year's KOP E4P-360-250-D-D-D-B encoders

The number of "ticks" per revolution is found in the part number. The one referenced above has 360 ticks, while the E4P-250-250-D-D-D-B has 250.

Hope that helps

[Ether]

Thank you. I was slogging my way through that long thread but not finding the answer I was seeking.

I forgot to ask: is the above (bolded) documented somewhere? Before posting here I pulled up the on-line LabVIEW help for the encoder vi but all it said was:

Decoding Type specifies the type of decoding used to decode the quadrature signal. Decoding Type supports three types of decoding for quadrature encoders: 1x, 2x, and 4x.

... which wasn't very informative.

Is there somewhere else that a LabVIEW beginner should be looking for this kind of information?

[buildmaster5000]

My team tried to use similar encoders to those in the KOP to read the angle of a swerve module, but we had trouble getting quality readings. If you are trying to do this, my advice is to find another sensor that is designed for this purpose. The KOP encoders to designed to read rotary changes (such as RPM on a gearbox) so that the program can respond accordingly.

Good Luck