Encoder problems
 

During the preperations for our off season competition I encounterd a problem with our shooter encoder.
At the competition we worked with the E4P optic encoder but when I checked the data after the competition I discoverd it isn't right, the encoder was mounted directly on the miniCIM's shaft that was connected directly to the wheel that spins the shooting belt, at low RPM (to measure RPM I enterd at the BEGIN.vi 1/6 to the distance) the data was good but as we got into bigger range (3000+) the input from the encoder went crazy, sometimes there was a 1000+ differnce between two continous readings.
I decided to change the encoder because I was sure that the problem is hardware, we changed it into a AS5145B Magnetic Encoder, we connected the encoder just like the manual and WPI (http://wpilib.screenstepslive.com/s/...control-system) said. I changed the BEGIN again to match it to the example (encoding with 4X mode) but the same problem reacured.
I placed the reading from the encoder in the Timedtasks.vi at a different loop with a 100ms delay.
Added here is the graph of the rate that I got from the encoder when I gave the motor full power.

Re: Encoder problems
 

There are two calculations you should be making when matching an encoder to a task:

1) Calculate the maximum samples per second that an encoder will support. e.g.,

• Encoders have a maximum rpm that they will support, differing on the model.
• For example, if an encoder supports 10,000 samples per second.
• and the encoder produces 256 samples per revolution
• 10,000/256=39 revs per second maximum

2) Calculate the revolutions per second that the cRIO will support for that model encoder. e.g.,

• The cRIO input has a limit of ~39,000 pulses per second
• So, if an encoder produces 256 samples per revolution
• And you use 4x sampling = 256*4=1024
• 39,000/1024=38 revs per second maximum

When you exceed either of these you will see odd results like the ones you are getting.
3000rpm/60 = 50 revs per second

Re: Encoder problems
 

Thank you for the explanation and information, but, is there a way to read RPM around the range of 4000-6000?

Re: Encoder problems
 

There are a few simple ways to extend the rpm range of your encoder.

1. Use an encoder that produces fewer counts per revolution, e.g., pick a 64 count encoder rather than a 256 count encoder.
2. Use 1x sampling in your code rather than 2x or 4x sampling.
3. For measuring a shooter wheel that only goes in one direction, you can also leave disconnected the encoder B channel. Since you won't care about determining direction the A channel is all you really need.
4. Gear down the encoder shaft so it revolves more slowly than the shaft you are measuring.

So do the math:

1) Calculate the maximum samples per second that the encoders must support.

• For example, an encoder that supports 10,000 samples per second
• 6000rpm/60 = 100 revs per second
• 10,000/100=100 counts per revolution maximum (so an encoder that produces 64 counts per revolution (cpr) would work at that speed, but a 128 cpr would not)
• It's also worth noting that the encoder must be mechanically rated for the 6000 rpm you are proposing, too.

2) Calculate the number of pulses per second that the cRIO will support.

• The cRIO input limit of ~39,000 pulses per second
• 39,000/100 revs per second at 6000rpm =390 samples per rev maximum
• So a 256 encoder at 1x sampling would work (< 390 samples per rev)
• A 64cpr encoder would work at 4x sampling (64*4=256 < 390 samples per rev)

Re: Encoder problems
 

For (3), if you disconnect the encoder B channel, you will also need to change the LabVIEW code from the encoder library to the counter library.

Re: Encoder problems
 

Thank you both very much.
I'll try to change it to a counter and let you know if it worked as soon as i can :)

Re: Encoder problems
 

The FPGA has a 40 MHz clock.

The digital inputs are sampled every 261 cycles of the 40 MHz clock:

40MHz/261 = 153,256.705 samples per second per digital input.

If edge transitions (rising and falling) occur faster than this on any given input channel, the FPGA sampling will not be able to detect and count them properly.

Furthermore, for quadrature decoding, cross-channel edge transitions must be greater than 1/153,256.705 = 6.525 microseconds apart or the FPGA will not be able to determine which edge came first.


Example:

A US Digital 360 CPR E4P encoder outputs 2*360 = 720 total edges (360 rising + 360 falling) per rotation on each channel. So for each channel, an edge transition occurs every 1/720 of a rotation, if the symmetry is perfect (see attached excerpt from datasheet).

When using just a single channel of this encoder as a counter, and assuming perfect phase symmetry, speeds greater than (1/720)/(6.525e-6) = 212.9 rotations/sec = 12,771 RPM would cause a problem for the FPGA¹.

But the symmetry is not perfect. According to the datasheet, the symmetry across the range of recommended mounting tolerance can be off by as much as 75 electrical degrees. So instead of being (1/720) of a rotation apart, some of the edges in a channel could be as close as (1/720)*((180-75)/180) of a rotation apart. So speeds greater than (1/720)*((180-75)/180)/(6.525e-6) = 124.2 rotations/sec = 7,450 RPM would cause a problem for the FPGA.

Assuming perfect phase alignment between channels A and B, the cross-channel edges are (1/720)/2 of a rotation apart. So for quadrature decoding, speeds greater than ((1/720)/2)/(6.525e-6) = 106.4 rotations/sec = 6,386 RPM would cause a problem.

However, for this model encoder, the phase tolerance of the the 2 channels is rather sloppy. According to the datasheet, the quadrature delay across the range of recommended mounting tolerance can be off by as much as 60 electrical degrees. So instead of being (1/720)/2 of a rotation apart, some of the edges across 2 channels could be as close as ((1/720)/2)*((90-60)/90) of a rotation apart. So speeds greater than ((1/720)/2)*((90-60)/90)/(6.525e-6) = 35.48 rotations/sec = 2,129 RPM would cause a problem for the FPGA.

So as Mark and Joe mentioned in earlier posts, for measuring shooter wheel speed it may better to use just only one channel of the encoder (depending on the encoder and its tolerances).

To reduce the signal noise, you should also consider setting the FPGA sample averaging as discussed here.


¹the electronics in the 360 CPR E4P are limited to 10,000 RPM

Re: Encoder problems
 

I Changed our counter so it will now work with a counter instead of the encoder and I'm taking 20 samples now.
Thank you all

Re: Encoder problems
 

In case you missed this (tl;dr):

Re: Encoder problems
 

I actually read it but I wasn't sure what to do with that because up until now when changing the average value to around that area helped getting more accurate readings (we compared the data to a Tachometer).

Re: Encoder problems
 

Could you please elaborate a little on what the bolded phrase means in this context?

Also, could you post a PNG screenshot of the LabVIEW code you use to set up and read the counter?

Re: Encoder problems
 

about the bolded: when we worked with the E4P encoder one of our team graduated member checked with me the parameters in the config timer, when we set the number 21 to Number of samples to average we got the best readings, so I thought it will be the same here.

Re: Encoder problems
 

There is another option you can consider. I did this with a different team than my own and it worked rather well.

We used the closed loop functions of the Jaguar via CAN. We used E4P's in 4x mode spinning at 5K & 6K RPM connected directly to the Jaguar without an issue. The Jaguar is capable of 1M pulses per second.

The hardest part was tuning the PID values for the JAG.

**They opted to do this because they had Jaguars, & extra E4P's on hand so they didn't require any additional purchases in their tiny budget for this season**

Re: Encoder problems
 

Why are you multiplying the Counter.get value by 60?

Why did you choose the semi-period mode?

Re: Encoder problems
 

I want to get the RPM, according to the help from the get it is only seconds.
I wasn't sure what to chose that was the one that seemed suited for my needs, I know that I will test it soon to see which one is the right one, but if you could help me it would be amazing

Re: Encoder problems
 

Phalanx, to do that do you need 2CAN or any other thing more than the encoder and Jaguar?

Re: Encoder problems
 

If you multiply seconds by 60 you don't get RPM. See below for proper computation.



Try this:


The LabVIEW example linked below shows how to do that, and how to convert Counter.get to RPM:

You need to know the cycles per rev per channel for your encoder. Use that value instead of "99" in the above LabVIEW example.

Use your desired FPGA sample averaging value instead of "5".

Re: Encoder problems
 

All has been changed.
Thank you very much!

Re: Encoder problems
 

Does anybody know what the default Cycles Per Rev per channel is for the AS5145B in incremental mode?

Re: Encoder problems
 

According to WPI (http://wpilib.screenstepslive.com/s/...control-system) it is 1024

Re: Encoder problems
 

"The AS5145B is the equivalent of an optical encoder with a 1024 count disc, meaning it will output 1024 pulses per channel per revolution. In 4x decoding mode, this will yield 4096 ticks per revolution."

In that context, "pulses" seems to mean "cycles" (whereas US Signal uses "pulses" to mean "edge transitions").

Assuming that is correct, there are 1024 rising and 1024 falling edges per rev on each channel.

Let's do the math. There are 2*1024 = 2048 edge transitions per rev on each channel. So the edges are 1/2048 of a rotation apart, assuming the best case of perfect symmetry. So the max speed the FPGA can handle for a single channel of that encoder before it starts to get weird is (1/2048)/6.525e-6 = 74.8 rotations per second = 4490 RPM.

So that will not work for your desired 6000 RPM. Use a different encoder with fewer cycles per rev.

Re: Encoder problems
 

So I will try again the E4P as a counter.
Thank you very much

Re: Encoder problems
 

You can use either the 2CAN or the SERIAL to CAN adapter. The instructions for making making CAN cables, terminator, and a SERIAL to CAN adapter can be found here beginning on page 23.
http://content.vexrobotics.com/docs/...e_20130215.pdf

In your case, I would use the SERIAL to CAN adapter setup for your testing, learning, developmental purposes.
There is a bit of a learning curve to get the environment setup. You'll need to load FIRMWARE and set ID's on the JAGS.
All the documentation you need can be found here: http://www.vexrobotics.com/vexpro/mo.../217-3367.html

There are also good examples in LABVIEW, for CAN Jaguar and Encoder that you can look at to get a better understanding of how to setup the environment.

Re: Encoder problems
 

If you already have the AS5145B wired up and ready to go, why not run it and see if it works as expected? Increase the RPM and let us know at what point the RPM starts to misbehave.

Re: Encoder problems
 

Ether, I will check on Sunday and post what will happen..

Re: Encoder problems
 

Phalanx, do you have any tips / important notes for working with the CAN?
I will probably test that after our offseason competition and I want to make sure I will have all the information needed.

Re: Encoder problems
 

Sure... Here are top tips....

1) Make sure you have good termination. Poor terminating has been the cause of more nightmares and headaches than anything else.

2) Don't overtax the CPU on the CRIO. When than happens the serial port bogs down, responses get slow, CAN errors tend to crop up.

3) Don't send the run at xxxx speed every loop (20ms) in teleop. I find that that adds too much traffic and floods the serial port. Just set it once, and then check it in a periodic loop (I like the 100ms loop for that). The Jaguar will do it's best to maintain that speed for you. You only need to tell it when you want to change it. It's kind of like, set it once and forget it.

Re: Encoder problems
 

I will probably ask more questions when I will work on the CAN but thank you very much!

Re: Encoder problems
 

I finally got a chance to test the encoder as a counter (you can see the images attached for the beahaviour of the counter and the begin and readings of the counter).
The math wasn't far from the truth but the tachometer reading showed that the shooter spined at 4800 - 5200 RPM which the counter couldn't read.
Should I replace back the encoder to the E4P that probably will work around those speeds?

Re: Encoder problems
 

The E4P should work, if you physically connect only one channel and set it up as a counter. For a 360 CPR E4P, I recommend you try changing the blue "5" to "126" for high speeds (like 6000 RPM) to reduce the noise.

Re: Encoder problems
 

I'll try that but aren't your calculation showed that it is over the FPGA limits?

Re: Encoder problems
 

I'm not sure where you got that from. Here is the calculation I posted (with bold added for emphasis):

A US Digital 360 CPR E4P encoder outputs 2*360 = 720 total edges (360 rising + 360 falling) per rotation on each channel. So for each channel, an edge transition occurs every 1/720 of a rotation, if the symmetry is perfect (see attached excerpt from datasheet).

When using just a single channel of this encoder as a counter, and assuming perfect phase symmetry, speeds greater than (1/720)/(6.525e-6) = 212.9 rotations/sec = 12,771 RPM would cause a problem for the FPGA1.

But the symmetry is not perfect. According to the datasheet, the symmetry across the range of recommended mounting tolerance can be off by as much as 75 electrical degrees. So instead of being (1/720) of a rotation apart, some of the edges in a channel could be as close as (1/720)*((180-75)/180) of a rotation apart. So speeds greater than (1/720)*((180-75)/180)/(6.525e-6) = 124.2 rotations/sec = 7,450 RPM would cause a problem for the FPGA.

Re: Encoder problems
 

I'm still using the AS5145B and as you can see in the graph we reached the limit, When I will change it back to the E4P there won't be any problem.
Thank you very much for all the help and knowledge!