Velocity readings cFP-QUAD-510, explain limitations

[RVallieu]

I am trying to understand the limitations of the Velocity measurements capability of the [c]FP-QUAD-510.

Looking at the operations manual I see the maximum velocities that can be measured in counts/us.

If I have a quadrature encoder tracking a shaft running at 1750 rpm, and the encoder is 60 PPR - this yields 1750 counts/second or 0.00175 counts/us.

Would I thus have to use the longest timebase to obtain RPM +/- 38 counts/sec which with the 60 PPR yeilds +/- 38 rpm ? 

Thus I would need to increase my PPR to get me a better Velocity Resolution.**

**Is my understanding of the velocity Ranges correct?

Message Edited by RVallieu on 07-01-2008 04:30 PM

[Karunya_R]

Hi Ryan,

This is what I have:

60 Pulses /revolution * 1750 revolutions/minute * 1minute/60 seconds = 1750 revolutions/second = 1750 counts/sec (1 revolution = 1 count)

1750 counts/sec *1sec/ 10^6 microsecs = 0.00175 counts/microsecond

Comparing this value to Page 11 of the operating instruction, the best time base for this would be 26214.14 microsecs.

Velocity range means the highest velocity value that can be measured within that rage. So for your value of 0.00175 counts/microsecong, the range of +/- 1.25 counts/microsecond would be the most appropriate since you would get the best resolution. You can, of course measure values upto +/- 1.25 counts/microsecond within the range.

I hope this helps!

[RVallieu]

Thanks for the double-check, this is what I concluded.  At the RPM ranges in the system I will be monitoring, it would be better to use a higher PPR encoder to get better resolution on the velocity.  Even the longest timebase at these RPMs would be able to handle up to ~26000 PPR to approach the 1.25 counts/us.

[RVallieu]

Testing one of the QUAD-510 untis showed me that it is not appropriate for this application.  At anything below 38.15 resolution with this 60 ppr encoder, the velocity output oscillates between 0 and 38.15.

[Karunya_R]

Hi Ryan,

As you probably know, what you are seeing is expected behavior. You needed a module with a higher accuracy count. If you signals are in AI signals, then I can recommend some other modules for you.

[RVallieu]

These are Line Driver outputs - digital signals.

[Karunya_R]

One of the DO modules maybe?

Have you tried looking at those?

[RVallieu]

cRIO will handle this for me at this point.  Thank you for your help.