sanyc Posted July 30, 2020 Report Share Posted July 30, 2020 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? Quote Link to comment Share on other sites More sharing options...
MVP 2022 Flex727 Posted July 30, 2020 MVP 2022 Report Share Posted July 30, 2020 What PLC and I/O are you using? High Speed inputs will calculate frequency for you. Quote Link to comment Share on other sites More sharing options...
MVP 2022 Ausman Posted July 30, 2020 MVP 2022 Report Share Posted July 30, 2020 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 Quote Link to comment Share on other sites More sharing options...
sanyc Posted July 31, 2020 Author Report Share Posted July 31, 2020 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. Quote Link to comment Share on other sites More sharing options...
AlexUT Posted August 2, 2020 Report Share Posted August 2, 2020 Hisanyc, Review Unitronics Helpdesk Articke: Calculate Total - Totalizing Hope this is what you need. B.R. Quote Link to comment Share on other sites More sharing options...
sanyc Posted August 6, 2020 Author Report Share Posted August 6, 2020 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? Quote Link to comment Share on other sites More sharing options...
MVP 2022 Ausman Posted August 6, 2020 MVP 2022 Report Share Posted August 6, 2020 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 Quote Link to comment Share on other sites More sharing options...
sanyc Posted August 7, 2020 Author Report Share Posted August 7, 2020 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. Quote Link to comment Share on other sites More sharing options...
MVP 2022 Ausman Posted August 7, 2020 MVP 2022 Report Share Posted August 7, 2020 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 Quote Link to comment Share on other sites More sharing options...
sanyc Posted August 7, 2020 Author Report Share Posted August 7, 2020 I see what you mean. The thing is my current model Unistream doesn't support interrupts. Please someone enlighten me if I am wrong Quote Link to comment Share on other sites More sharing options...
MVP 2022 Flex727 Posted August 7, 2020 MVP 2022 Report Share Posted August 7, 2020 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. Quote Link to comment Share on other sites More sharing options...
MVP 2022 Ausman Posted August 7, 2020 MVP 2022 Report Share Posted August 7, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
sanyc Posted August 11, 2020 Author Report Share Posted August 11, 2020 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. Quote Link to comment Share on other sites More sharing options...
Rivka Posted October 18, 2020 Report Share Posted October 18, 2020 Please note that T42 UniStream models now support 1ms interrupts Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.