encoder values fluctuating considerably

[grosh]

As an offseason project we are trying to read the encoder rate from a vexpro ballshifter and use it to automatically shift when a desired rate is reached.

To test the rate we are using the LV sample program "encoder and motor". All values, but the encoder rate, show up consistantly. The encoder rate (deg/sec) values fluctuate between 50-1000+ when at full speed. How do I make the range of encoder rates more useful? The encoder is a Usdigital e4p 250-250-0-0-0-0.

-Thanks in advance

[Ether]

Originally Posted by grosh

How do I make the range of encoder rates more useful? The encoder is a Usdigital e4p 250-250-0-0-0-0.

How fast are you spinning the encoder (RPM)?

Post a PNG of the code you are using to initiate and to read the encoder.

[grosh]

We estimated the encoder will spin about 1400rpm at top speed.

[Ether]

Originally Posted by grosh

encoder settings.PNG

That's the user interface display.

Please post a PNG of the code.

[grosh]

Roger...the LV "motor & encoder" sample code is attached.

[Mark McLeod]

At what rpm (or deg/sec) do the encoder values begin to go bad?
Have you calculated the maximum theoretical rpm that the encoder will support?
Have you compared the number of ticks per second that the encoder will produce at max rpm to the maximum ticks that the cRIO will support (~39,000/sec)?

A simple experimental test is to try running the encoder at 1x or 2x to demonstrate if 4x is attempting to sample too much , too quickly.

[grosh]

It does work better at 1X sampling but the values still fluctuate greatly.

I don't know how to calculate the max theoretical value the encoder will support. I am using a UsDigital 250-250-0-0-0-0 that came with our VexPro ballshifter.

[Joe Ross]

Originally Posted by grosh

I am using a UsDigital 250-250-0-0-0-0 that came with our VexPro ballshifter.

Just as an FYI, the VexPro Ballshifter does not come with an encoder. Additionally, US Digital PN 250-250-0-0-0-0 is not valid. 250-250 is a good start, but there should be letters where you have 0s.

[Mark McLeod]

A rate of 50 to 1000 Hz is not very much.
The rate is not really degrees per second unless a 360 encoder is being used at 1x sampling.
Does the rate fluxuate much at low speed too?

You may simply have a poor electrical connection on the encoder lines.

[grosh]

Joe- The encoder came as an option when purchasing the ballshifters. I was wrong on the encoder number it is a E4P-360-250-d-h-d-b.

I am going to replace the wire and report soon. Thanks all for your help so far.

[Mark McLeod]

After verifying the wiring, another issue with that model encoder is the proper installation and spacing of the encoder disk.
If it isn't spaced properly, using the spacer aid that should have come in the kit, then the rate will be random at all speeds.
The encoder disk also needs to be tight on the shaft rotating it, and the shaft itself cannot have very much play which would change the spacing as well.
"Accepts +/-.020" Axial shaft play"

Finally, if you have other EP4's be careful not to mix the encoder disks. The disks and encoder package are paired specifically to match up cycles per rev. Your model number specifies it is 360 cycles per rev., but if you happened to also own a 250 or 100, then they would not work with the 360 model and they are hard to distinguish between.

[Joe Ross]

Originally Posted by grosh

We estimated the encoder will spin about 1400rpm at top speed.

Is this including the 3x encoder gear ratio on the ball shifter?

[Ether]

Originally Posted by Mark McLeod

...proper installation and spacing of the encoder disk...

...If it isn't spaced properly...

...The encoder disk also needs to be tight on the shaft rotating it...

... be careful not to mix the encoder disks...

What Mark said. Plus:

... damage to the disk (e.g. scratches) from improper handling

[grosh]

Joe- the max RPM did include the 3x encoder gear

Mark- I think it is the encoder assembly. I swapped the encoder wire to the gearbox on the opposite side and it solved the problem.

Now can someone help me determine the correct value to use for DistancePerCount in the Encoder Open VI?

[Mark McLeod]

Originally Posted by grosh

Now can someone help me determine the correct value to use for DistancePerCount in the Encoder Open VI?

It depends on what you want Get Distance to return.
In the example code you are using it isn't actually setup to return distance. It is setup to return an angle of rotation. In normal usage I'd prefer the Get Distance to return actual inches travelled.

If you want to use the example code as is and keep Distance as a rotation angle, then you can determine the value experimentally by setting DistancePerCount to 1, rotating the wheel 360 degrees (or some multiple to help reduce error), finally dividing 360 by the "Distance" to get DistancePerCount in degrees/count. You'll need to add a display of the raw Distance value, so you can use it. The value can also be calculated analytically as long as you take into account any reduction, so you know what a full rotation is.

If instead you want to have the Get return actual distance travelled, then follow the (paraphrased) example given by the LV Help detail for Encoder Open:
"For example, if the wheel diameter is six inches and the encoder pulses 360 times per rotation of the wheel (at 1x), then a scaling factor of 6*pi / 360= .0524 returns the number of inches the wheel has turned. In this case, you input .0524 ."

I also recommend experimentally verifying the distance value by setting DistancePerCount=1 (that'll output the number of ticks as the "Distance"), adding a display of the raw Distance value, then slowly push your robot a pre-measured distance using a tape measure. That'll give you the proper value to use by dividing the measured distance by the Get Distance.