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.