This year our team used encoders for the first time on our robot and seemed to have some problems. They would work for a while but then randomly would stop working. We then changed ports on the side car and it worked again. Are the encoders frying our sidecar ports? If so do you know why they are?
What encoders were you using and where on the robot were you using them?
They were the US Digital ones that are sold on Andymark and the one that kept stopping was mounted on our shooter wheel.
I’m assuming your shooter wheel was spinning at several thousand RPM? If so, you might simply have been spinning the encoder too fast and it couldn’t generate clean pulses quickly enough. Since it’s relatively unlikely that you’d damage a digital input with the encoder, it’s more likely that changing it from one input wasn’t actually changing much. Something else changed to get the wheel back into a measurable range.
(Elaborating further on what Kevin said in his previous post)
If you provide the following information, I will show you how to do some quick calculations
-
what encoder part number are you using
-
what RPM are you spinning the encoder at
-
how are you decoding the encoder signal? e.g.:
– are you using both channels or only one channel?
– are you using the encoder or counter class?
– 1x 2x 4x up/down geartooth?
– are you reading counts, rate, or period?
– did you set the FPGA averaging sample ring buffer size or leave it at the default value of 1?
While you are gathering the info Ether requested, let me give you some of the common problems we have experienced with these encoders. BTW, these encoders work well if you know when and how to use them. That information should be borne out when Ether shows you how to do the calculations.
Some common problems:
- The encoding disk may not be spaced correctly from the optical sensors. Use the alignment tool provided with the encoders to space them properly.
- There may be smudges (finger prints) on the disk. Clean it VERY CAREFULLY and re-install.
- The disk may be loose on the shaft. This is VERY common. Gently tighten the fingers with a pair of pliers on one side of the disk ONLY! Re-install the disk.
- The pins on the wires may not be crimped properly on the conductor/wire. There may be insulation inside the crimp. Inspect the pins with a magnifying glass and correct if necessary.
- Run-out on the shaft may exceed the operational tolerances. Locate and correct the cause of the run-out.
#3 is the most common issue we have seen when the encoders are intermittent.
Make sure these items are correct and you should be in good shape.
If you provide the following information, I will show you how to do some quick calculations
- what encoder part number are you using
- what RPM are you spinning the encoder at
- how are you decoding the encoder signal? e.g.:
– are you using both channels or only one channel?
– are you using the encoder or counter class?
– 1x 2x 4x up/down geartooth?
– are you reading counts, rate, or period?
– did you set the FPGA averaging sample ring buffer size or leave it at the default value of 1?
Has someone created/can someone point to an application note that provides a few examples and configuration setups for Labview for 1) drive wheel application (low speed) and 2) high speed target (4000 rpm) with configuration comments ?
Here is the encoder we used on the wheel.
We now know that this is not the encoder we should have been using, because they get destroyed so easily at this high of RPM, which was direct driven on the Mini-CIM (6500 RPM I believe)
Ben and I are not programmers, so we will have to get back to you on how they coded the encoder.
The problems were in the Side Car I believe though. We could use the exact same encoder, with out modifying anything else, and change the ports it was plugged into and it would work.
I installed all of our encoders my self, and made sure the disks were clean, they were spaced properly (which for some reason wasn’t properly spaced using the spacing tool, because the encoder wouldn’t read the disk when we used it), the disk was properly on the shaft (100% sure about that) and the wires were properly plugged in. There was one time which we destroyed the surface of the disk, replaced it and worked again.
By the way, 772 won’t be using these encoders again by choice. They are unreliable and too sensitive for our applications in FRC. I would recommend using more durable encoders for the FRC.
Interesting as I used the same encoders(excepting for 360 instead of 250 counts) with another team. One was running at 6200RPM and the other at 7800RPM and didn’t have any problems at all. Of course we use them at that speed directly attached to a Jaguar running in closed loop speed mode.
They do have tight mounting tolerances, and not a lot of axial play is tolerated, so the damage to the disks might be attributable to their mounting and axial play. How much axial play is there? How much vertical play is in the shaft? It could be too much vertical play that causes the disk to come down and scrape on the electronics board in the encoder.
The questions have been asked if you are decoding in 1X, 2X, 4X mode using the CRIO. It maybe that if you are doing 4X mode and using more than 1 of them you might be overrunning the counting ability of the FPGA CRIO. JHersh from NI on here is the expert on the FPGA rates of encoder counts. In fact there have been a couple of discussions on just how many and how fast the FPGA can handle.