Re: Magnetic encoders? Anybody else having trouble?
 

We noticed the readout value jumps all over when using the encoders' analog output. This seems to be caused by the slow PWM it uses. Aliasing issues occur when the cRIO samples its analog inputs. I added a simple RC filter and that seems to have sorted it out. I just used a 4.7k in series and a 1uF after that. That seems to have smoothed it out, but as always some tweaking might be necessary depending on your application.

EDIT - For more info, just found the datasheet actually mentions this on page 18...

I believe it defaults to 4096 bit but can be changed through the digital interface.

We have tried this encoder on a shooter wheel and it can swamp the cRio pretty quickly. IMHO this encoder would probably best shine in a lower speed continuously rotating system or as a positional sensor.

- Bryce

Re: Magnetic encoders? Anybody else having trouble?
 

The datasheet is a bit unclear to me. Can pins 3 & 4 be configured to output a square wave quadrature signal or can they not?

Has anyone successfully done this with this sensor?


I'm guessing your comment above is based on not using the A & B quadrature output?

The datasheet is unclear regarding the max rpm the sensor electronics can support in incremental quadrature mode and still produce a usable output.

Sorry to be unclear in my last post. Yes, we were using the magnetic sensor in encoder mode. Were did seem to be getting good feedback. I didn't scope it, but we were getting count rates that seemed consistent and direction was also detectable.

All this was possible only at slow speed though. We could hit the Nyquist frequency for the cRIO input at very low speeds - maybe 15% or less of a CIM motor output, I can't remember the exact figure. At around this speed the encoder rate sign would change. We also would get very quantized numbers for speed (e.g., always something like dancing between 20142.464 and 21439.264 that were repeated exactly).

Just a thought, is it possible that having 4096 bit resolution that could correspond to 4096 ticks on an optical encoder and that the transitions actually happen 4x that speed? That would make matters even worse for sure.

So we gave up pretty quickly using the magnetic sensor and went to US Digitals instead. In hind sight I probably should have just rotated the shooter wheel one revolution and checked how many clicks it produced...

Re: Magnetic encoders? Anybody else having trouble?
 

Pretty sure it's 1024 cpr equivalent. 4096 transitions per rev.

Re: Magnetic encoders? Anybody else having trouble?
 

quote from screenstepslive:

Re: Magnetic encoders? Anybody else having trouble?
 

I'm guessing you were using the Encoder class and instantiating 4X decoding?

That's your problem. That's overkill for a shooter wheel speed sensor.

If instead you connected only one channel of the sensor, and made a Counter object that counts only the rising edge of that channel (with no direction control), the FPGA is capable of keeping up with 1024 rising edges per rev at well over 5,000 RPM (perhaps as high as 8,000 RPM).

Please note though: for high-CPR counters at high RPM, if you use the getPeriod() method, you must set FPGA samples much higher than the default 1. For your app, I'd use 127 (the maximum), which is about 1/8 of a revolution. Setting the size of the FPGA sample buffer is easy in LabVIEW. In C++ or Java, it requires a small edit to the WPILib code.

Or, at those high speeds with a high CPR (like 1024), you could get the counts (instead of the period), and divide by elapsed time. To get good results with this method, you need a good value of elapsed time. In C++ you can use the PPCtimer (low overhead and microsecond resolution). In LabVIEW you can use a Timed Structure and just divide by the period.

Re: Magnetic encoders? Anybody else having trouble?
 

We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train. We've got a lag of about 5 seconds (when reading the values from teleop.vi). Does anyone know how to fix this?

Re: Magnetic encoders? Anybody else having trouble?
 

How are you measuring this lag?

Re: Magnetic encoders? Anybody else having trouble?
 

We have found that moving all but your driving code out of teleop in into periodic tasks seems to improve the lag issue considerably. Additionally, try making sure that your video coming from the camera is running at the minimum required frame rate and resolution with maximum acceptable compression.

Re: Magnetic encoders? Anybody else having trouble?
 

I'll hit the joystick to move the drive motor and a stop watch at the same time. Once the value on the front panel of the encoder changes, I hit the stop watch again, to stop it.

Billbo911: We don't have a camera hooked up, and just about all of our code is in periodic tasks. Even when we moved the code to read the encoders to periodic tasks (10 ms delay), we still get the same lag. The potentiometers that we're also reading are updating rapidly. The code to read those were always in the same spot as the code to read the encoders.

Re: Magnetic encoders? Anybody else having trouble?
 

Are you decoding at 4X, 2X, or 1X? The FPGA cannot read a 1024 CPR encoder at 4X at full CIM speeds.

Re: Magnetic encoders? Anybody else having trouble?
 

We tried both 1x and 4x, with no difference in lag.

I'm aware of the 1X / 4X setting and we tried both. At full speed our wheel spins at around 6000RPMs. We were using 1X almost exclusively.

As for changing to a counter class, that might work much better.

What are the changes between 1X and 4X under the hood between the cRIO and FPGA?

- Bryce