RPM control system

[Bruno#1382]

hello guys we are having some troubles with a RPM control system
we are using a inductive sensor to get pulses and convert to RPM anyone knows a another way to do this? it can be simple or not
thanks

[BitTwiddler]

The WPI Library in the Functions Palette contains some vi(s) specific to the Counter functions built-in to the Crio's FPGA. One of the outputs of the Get Counter VI is the period between input pulses. Use that output to calculate the RPM value. See some of the example code for how to use the counter.

The Crio's FPGA takes a lot of the processing load off of the on-board computer so you don't have to try to do it all in software.

[propionate]

If you have trouble with the solution above, there is a way to tweak the example code for an encoder to do what you are looking for as well.

[Bruno#1382]

ok,but the encoder don't work well because when he works in high rotation he skip a lot os pulses

[propionate]

You don't have to use the encoder - just wire up the inductive sensor to a DIO input, and have LabVIEW pretend it is an encoder. The encoder VI will generate a speed for you (degrees/second), but you will likely have to scale it to get the correct RPM. Once again, this is just an alternative to using the Counter method.

[Ether]

Originally Posted by propionate

You don't have to use the encoder - just wire up the inductive sensor to a DIO input, and have LabVIEW pretend it is an encoder.

LabVIEW must be different from Java:

http://www.chiefdelphi.com/forums/sh...26&postcount=2

[propionate]

Originally Posted by Ether

LabVIEW must be different from Java:

http://www.chiefdelphi.com/forums/sh...26&postcount=2

You do need to provide a DIO number for both Channel A and Channel B, but I just entered in the same channel for both. It worked out fine.

[Joe Ross]

Originally Posted by Bruno#1382

ok,but the encoder don't work well because when he works in high rotation he skip a lot os pulses

Are you saying that the sensor doesn't react fast enough and misses pulses, or that the cRIO misses pulses?

I'd expect that the counter works at a higher rate then an encoder.

[Ken Streeter]

Originally Posted by Bruno#1382

ok,but the encoder don't work well because when he works in high rotation he skip a lot os pulses

I keep hearing reports like this and always wonder whether or not I should try to stop the misinformation. Usually Ether jumps in to do so, but this time I figured I'd have a go...

The USDigital Sensors that have come in the Kit of Parts in recent years and the FPGA in the cRIO are fully capable of keeping up with very high rate encoders or counters.

The limiting factor for the maximum rate will be the lesser of the limits for the encoder and the cRIO.

First, the USDigital encoder:

There are two separate constraints for the USDigital encoder: (1) The mechanical limit for the USDigital E4P encoder is 60,000RPM. (2) The maximum count frequency is 60kHz. Accordingly, the maximum RPM due to the maximum 60kHz count frequency is 3,600,000/CPR. For the 250 count disks that were provided in the kit in recent years, this means the maximum RPM is 14,400 RPM. Even a 360 count disk will allow 10,000 RPM.

Next, the cRIO:

The cRIO is fully able to measure such high rate encoders with the use of the FPGA counter. The input sample period is 6.5usec, which is 153 kHz, giving a permissible encoder rate of up to 38.4k counts per second. For a 250-count disk, this is about 9200rpm.

OK, so rates of up to 9200rpm should be possible. But, what about practical experience?

For 1519's shooter wheels last year (Rebound Rumble 2012), we used a 250-count optical disk in the USDigital E7P encoder and had no problems with this setup being driven at over 4000rpm and measured by the cRIO using an encoder object with 1x sampling in Java.

One caveat that may lead to misinformation that teams were having problems with encoders at high RPMs is that the getRate() function will have excessive jitter at high RPMs, but this isn't due to missing counts. Instead, this jitter is due to the way the getRate() function works in WPILib. getRate() determines the rate by measuring the period of a single pulse (with 6.5usec resolution) and then taking the reciprocal to determine a rate. This isn't accurate at very high pulse frequencies, due to the discretization of the measurement of the period of a pulse. Instead, what can be done is to periodically sample the number of counts, determine how many counts have occurred since the prior sample, and then divide by the time since the prior sample, to determine a rate in counts per second.

Converting counts per second to RPM is achieved by multiplying by 60 seconds / 1 minute and dividing by 250 counts per 1 rotation (for a 250 CPR disk). We did this last year and received very stable RPM information for controlling our shooter wheel speeds via a PID control loop.

[Bruno#1382]

our encoder don't detect the pulses in high rotation ,but we solve the problem today's morning thanks for all replys guys we use a control wired direct on the motor so we can control the motor direct from the labview