Calculating RPM from pulses

[sanyc]

Hi,

I am reading pulses from a proximity inductive sensor and I want to convert it to rpms. The rpms are being read from a wind turbine shaft and I am getting one pulse per turn of the shaft. I will have max around 120 rpms. 

The sensor is omron PNP, NO, 3 wire 24V dc.

I am trying to measure the time between the rising edge of each pulse (thus each turn) of the proximity sensor but I am not sure how to do this with the timers. Anyone can help?

[Flex727]

What PLC and I/O are you using? High Speed inputs will calculate frequency for you.

[Ausman]

If you don't want to do it Flex's way (which will still involve some maths), although it is in Visilogic this example shows the principle of how to do it very easily.  At 120rpm max you don't need anything fancy like high speed inputs or timers. 

I'm not a Unistream user but feel sure that setting up your own 1.25ms "interrupt count" should be very easy.  You may be able to go even smaller for greater accuracy...I don't know.

cheers, Aus

http://forum.unitronics.com/topic/4599-totalizer-to-gpm/?do=findComment&comment=17077

 

[sanyc]

I am using the 5'' TA30 unistream. 

What I did so far was used a normal digital input and calculating how many pulses from the sensor I get for every 2 seconds. Then I am multiplying this value by 30 to get it for every 60 seconds (which is like an instantaneous) reading of the rpms. 

Will try various methods to see which one best works.

 

 

[AlexUT]

Hisanyc,

Review Unitronics Helpdesk Articke:

Calculate Total - Totalizing

Hope this is what you need.

B.R.

 

[sanyc]

On 7/30/2020 at 4:40 PM, Ausman said:

If you don't want to do it Flex's way (which will still involve some maths), although it is in Visilogic this example shows the principle of how to do it very easily.  At 120rpm max you don't need anything fancy like high speed inputs or timers. 

I'm not a Unistream user but feel sure that setting up your own 1.25ms "interrupt count" should be very easy.  You may be able to go even smaller for greater accuracy...I don't know.

cheers, Aus

http://forum.unitronics.com/topic/4599-totalizer-to-gpm/?do=findComment&comment=17077

 

I have looked into the example. Are you based to the fact that the scanning time is 2.5ms for the increment in the subroutine?

[Ausman]

16 hours ago, sanyc said:

Are you based to the fact that the scanning time is 2.5ms for the increment in the subroutine?

Not necessarily.  That was just to cater for the slower interrupt on older Visions.  Enhanced ones can also do 1.25ms.  The principle is what I was showing you.  The smaller the time the better, you just tailor your maths to suit.  But at something doing a maximum of only 120rpm you don't need to be going overboard.

cheers, Aus

[sanyc]

I did something similar in Unilogic but I am not getting accurate results.  Attached is the program itself.

On the first rung I am stacking up an MI that I am assuming   its increasing at a rate of 1ms based on the scanning time.

On the second rung my proximity pulse clrears the first MI and stores its value to a second MI.

Then I am converting my stacked up MI into milliseconds to get the period and converting them to seconds for the final RPM calculation. (RPM = 60/T)

My test rig is a motor at steady speed rotating a shaft that I get proximity pulses from. Testing with various instruments I know I have 31 rpms but my program outputs 40 rpm. And I also noticed that at higher speeds the deviation is larger whereas at lower speeds the deviation is smaller.

 

[Ausman]

4 hours ago, sanyc said:

I am assuming   its increasing at a rate of 1ms based on the scanning time.

The timing period has to be exact, whatever you decide on.  That is the entire basis of the concept.  Basing it on scan time is not sufficient.

This is why it uses the interrupt in Vision, as it is exact and interrupts the scan, if necessary, at the exact time interval.

Someone else can perhaps comment on your logic, as I don't use Unistream.  But your deviation observations match what will happen with the basic timing error, as it will increase proportionally the quicker the shaft spins.

cheers, Aus

[sanyc]

I see what you mean. The thing is my current model Unistream doesn't support interrupts.

Please someone enlighten me if I am wrong

[Flex727]

You can NOT depend on scan time to be consistent enough for this purpose. It varies a lot depending on what the PLC is doing at the moment.

The UniStream has a milliseconds counter built in, located at 'General.Milliseconds Counter'. Just use that in your logic above.

However, it would be simpler - if you can get by with it (due to your slow 120 RPM rate) - to use the 100ms system bit which exists in both Vision and UniStream.

[Ausman]

9 hours ago, Flex727 said:

to use the 100ms system bit

but if you do this, understand that at quicker rpms your readings are going to be all over the place.  At lower ones it would be reasonably ok.  

Sanyc, do you understand the logic behind this statement?  As it's an inverse type thing, it can be hard to get your head around.   Think about it...

1 RPM = 600 counts to be converted by maths.

2 RPM  = 300;      5 RPM = 120;      10 RPM = 60;        20 RPM  = 30;      30 RPM = 20;    60 RPM = 10  and notice now how the rpm numbers are starting to get all over the place, as you are extrapolating numbers that will by their very nature jump in large amounts due to the maths.  At any time, but more so at higher rpm, you'll also run into issues with over-lapping of input reads that might just miss the 100ms count time, but be added sort of  erroneously into the next one.  Think of the inverse relationship they same way a linearisation will work if you only have the input from 0-10 and the output 100.....you're only going to get an output of 0, 10, 20, 30 etc.    Not any of the numbers in between.

Thus the smaller the primary count, the better.

cheers, Aus

[sanyc]

I see what you mean Ausman. The resolution is not high enough.

The following is what I did and works pretty well. Its drwaback is  that at low rpms the pulse width becomes an issue and at very high rpms it will be limited by the increamental step of the timer.

 

 

[Rivka]

Please note that T42 UniStream models now support 1ms interrupts