Setting up CTRIO to calculate RPM with the edge timer.

[trevorstripling]

I just ordered the CTRIO for my DL06 to use to calculate driveshaft RPM.  I have a pulse input that is 4 pulses per revolution.  The pulses are equal time on and off.  It is important to read low RPMs accurately.  I think my best option is the edge timer instead of the rate option.  I need help with the scaling wizard and setting it up to calcuate the correct RPM.  What should I use for the Counts/unit and Unit Time Base.

Any other tips will be appreciated.

Trevor

[Greg]

It is a bit confusing at first, but once you understand some basics, I think you can see how it works. An "Interval Scaling Calculator" is provided in the Scaling Wizard inside CTRIO Workbench to check your settings.

First, I would advise that after selecting Edge Timer that you configure it for "Free Run". In this mode you do not have to reset the Edge Timer to get the next value, it automatically resets. Next, select "Interval" as the Scaling type. Since you want an accurate representation of slow RPMs I would recommend using Integer x100 (2 implied decimal places). This will give you hundredths of RPM accuracy in your reading if you need it.

Next, if you have an encoder that only gives you 4 ppr (pulses per revolution) and you are measuring RPM, this is not much resolution to work with. But taking that as the given; then consider RPM simply means "revolutions per minute". Thus running a 1 RPM with your encoder:

1 RPM = 4 pulses in 1 minute

Thus if you selected "minutes" as the Unit Time Base, then the Counts/unit would need to be 4 because at 1 RPM you will get 4 counts / minute.

We can check this using the Interval Scaling Calculator provided in the Scaling Wizard. Notice you can only enter pulse times in µs (microseconds). So, again, running at 1 RPM, I am getting 4 pulses per minute or:

60 seconds / 4 pulses = 1 pulse per 15 seconds

and...

15 seconds = 15,000,000 µs

Thus, if you enter 15000000 into the Pulse Time of the calculator you will see that you get 1 RPM. Of course, if you picked the Integer x100 (2 implied decimal places) as I recommended, the calculator will show 100 RPM which really means 1.00 RPM.

Does this help?

[trevorstripling]

Yes, that is very helpful.

Here is the big picture of what I am trying to accomplish. 

The process that I am monitoring is the RPM of the driveshaft in a race car.  The driveshaft accelerates from 0 to 2000 rpm in the first second, then from 2000 to 3000 in the second second.  These are the time frames that are most important (but I like to see and log the whole cycle 0-6000 rpm in 5.5 seconds).  What I am looking for is tire spin and the quicker I can see (sense) it the better.  My first attempt was with a proximity sensor and a wheel with 4 teeth (4 ppr) and using the high speed inputs on a DL06.  This worked but did not yield very good resolution in the low rpm range.  I counted the pulses in a 50 ms window and this only yielded 300 rpm increments.  I then changed the wheel to 20 teeth (20 ppr and 60 rpm increments) which now works up to 3000-4000 rpm and then goes hay wire.  Looks to be exceeding the proximity sensor's 3 khz limitation.  My next attempt is to use the CTRIO with the 4 tooth wheel and use the time interval versus the pulse count (I could probably make a new wheel with 10 teeth that would work within the sensors limit).  In the plc I would like to see the RPM more often than 50 ms (20 times per second) maybe 10 or 20 ms and compare the increase in RPMs per time window to a constant setpoint an if the increase is greater than the setpoint (indicating tire spin) turn on an output that is wired to the ignition system that reduces the engines power output (and hopefully reduce or eliminate the tire spin).

Maybe you can let me know if I am going in the right direction?


Trevor

feel free to call me 832.922.7925

[Greg]

Interesting app!

The limiting factor of your application will certainly not be the CTRIO. But depending on how you are "reading" or "logging" the readings, or depending on your requirements for the readings, the PLC scantime may come into play. The CTRIO can count very fast pulses, and the pulses it is receiving at 6000 RPM even with a 10 ppr encoder would only give you:

6000 rpm / 60 spm = 100 rps
100 rps x 10 ppr = 1000 pps (Hz)

However, the communication of the scaled reading to the PLC across the backplane of the DL06 is limited by the scantime of the PLC.

But otherwise, I think you are "headed in the right direction", yes.   

[BobO]

Interesting bit of trivia...

I created the free-run edge timer and interval scaling function after attempting to instrument a race car!! Engine RPM off of the crank shaft and speed in MPH off of a spindle sensor were not giving good results when counting pulses and scaling. So I switched to edge timing, added the free-run option, and then created the interval scale....which produced a far better solution for the highly dynamic speeds of a SCCA Trans-Am car. It works very well for that!!

[milldrone]

trevorstripling,

This looks right up your alley!
http://groups.google.com/group/comp.dsp/browse_frm/thread/b3e2d7a50b301eed/cdb7b4d1156d827e#cdb7b4d1156d827e