measuring RPM - Siemens S7200

mjamil

Member
Join Date
Apr 2002
Location
PK
Posts
162
In the above mentioned PLC, is there a INTERUPT / SPECIAL BIT, etc to measure the RPM, instead of counting the Pulses for a period, doing a multiplication, and posting the result in the HMI.

The problem gets worse, in a slow process, for instance a CARTON packer, with a maximum RPM of say 20. for this I have to wait atleast 1 minute, before posting info.

coz if I count pulses for 15 seconds, and get 4.xx (actually 4.3) pulses, multiply it by "4", I get 16RPM, whereas it is 17.2RPM (for a 1 minute calculation, and for a 10minute calculation the reading would be 172, and ACTUAL 1hour production would be 1032 (based on 4.3 pulses per 15 seconds)

Now if I were to count only the "4" pulses, disregarding the remaining "0.3" pulses, (due to short measurement period), the production for one hour, as per the HMI would come to 960.

and thats a difference of 72. and I dont want the production team running behind me, for such errors.

any help would be appreicated, and no I do not want to use the typical type of RPM meters available.
 
I think what it boils down to is that, to accurately measure a slow speed, you want more (many more?) pulses per revolution... :nodi:

Another thought... Instead of waiting for multiple pulses, you may want to try the method I shared in THIS post... :confused:

🍻

-Eric
 
I'm no PLC whiz like some of the guys here, but I can tell you how to get a better result. Instead of counting the RPM pulses, count the time between two pulses. In your case this is 1000 milliseconds (1 second) divided by 17.2 RPM = 58.139.... ms. To get this back to RPM for your display, divide 1000 by your result (58) which gives 17.241.... RPM. In all cases you can discard the decimal points and still get acceptable accuracy.

How you do this in a PLC I would have to think about. Maybe feed 1ms pulses (which your PLC should give you) into a counter which is started and stopped by the RPM pulses, then read, do the maths and display the result, reset the counter and start again. You'd get acceptable accuracy and display refresh rate. Anyone got more idea on how to do this in MJamil's Siemens 7200 PLC??
 
Thanks Eric, I will try (to understand) the method in your link, except that for most functions its difficult for me to translate most terms, I have very little experience on Siemens only.

another convenient option I was considering was, to pick up more pulses, (as suggested), but I'll have to put up a separate sensor (and another PLC input), coz. currently I was using the same sensor (and input) which had been there for trigering the SHIFT REGISTER.

by having more pulses, I could get more accurate results, and I was thinking of showing the speed not in whole numbers, but in decimals as well, like "Current speed 24.70 cartons / minute"

comments?
 
please, confirm the pulses you counted for 15 seconds. i thik that if motor speed is 20 rpm then u will get 5 pulses in 15 seconds.

r u using proxi or encoder.
if encoder then how much max pulses of it.

so, first clear your question.

i m confused about 4.3 pulses u counted.

give me clarification of it.

hoping for reply.
 
jayesh.monpara said:
so, first clear your question.

i m confused about 4.3 pulses u counted.

give me clarification of it.
15 seconds = 1/4 minute
Number of pulses in 15 seconds x 4 = pulses per minute.
1 pulse per revolution, so pulses per minute = revolutions per minute AKA RPM.

Anyone care to translate my code to Siemens? I have a feeling it will work well for mjamil... :nodi:

🍻

-Eric
 
I have a new Dell laptop and do not have any of the PLC software, pictures etc loaded yet. What Eric has shown is what stn is refering too, using time between between pulses to calculate the rpm.

A simple method I have used is a spline toothed sprocket (there is another name for these but I cant think of it) with a prox or mag pickup. This is designed to give say 100 pulses (maybe more) per revolution. These can be bought or made small depending on the number of teeth/splines involved. These "sprockets" I am refering too will have "teeth" and spaces that are equal in size which can offer you double the count using on and off pulses..ie leading edge and falling edge.

If its doing say 17.2 revolutions per minute then its going to have a count of 1720 (or 3440)pulses or 430 (or 860) every 15 seconds. This offers a little more accuracy then using something like a bolt on a shaft to pickup once per revolution. In this case you can grab the count every 15 seconds then divide by 25 (or 50) and obtain the rpm. You can grab the count every 15 seconds but do an average in minutes if desired.

This is alot cheaper than an encoder and for me simplifies the math involved...we all know I like it simple.
 
Thanks all!

Eric, I understand what you are saying, but my problem are

1) The delay in updating the RPM on the HMI.

2) The Inaccuracy in the RPM and actual PRODUCTION.

lets forger the first problem, and look at the 2nd one.

say my production speed is 17 cartons per minute. So basically I produced 17 cartons!

now lets look at the RPM side, when I measure a 15second segment, I get four pulses (currently) as I get a pulse after each carton is made. so as per my RPM calculation, in 15seconds I get 4 pulses, the result would be 15 x 4 = 16 cartons.

In actual its 17. the difference occurs because in smaller time periods, the remained rotation of the shaft is not considered.

To sort this out, I was thinking to increase the pulses per carton, instead of SINGLE pulse per Carton.

regards.
 
I got confused. What are you measuring? Are you trying to obtain a speed OR a flow rate?

You are saying RPM but you are asking about products per minute, why not just count them per minute OR grab the count every 15 seconds and add together? After the first minute its a shift thing...ie 4 registers, a, b, c, d...value goes into a first, x time move to b, x time moves to c, x time moves to d. These 4 values are added to give you the rate. New values follow it so you have a 1 minute average of the production rate.

You are probably better at this then I am so I will let you think about it.
 
I don't like counting the number of pulses in x seconds and multiplying by 60/x , because you're only counting WHOLE cartons, which is sorely inaccurate, as you've discovered. You also have to wait too long to update the display... :(

Using you "17" example, and my method...

Actual machine speed = 17.0000000 cartons per minute (CPM)

Using a 1 second timer, you'll measure 3 seconds between pulses. 60 / 3 = 20.00 CPM. Way off.

Using a 0.1 second timer, you'll measure 3.5 seconds between pulses. 60 / 3.5 = 17.14 CPM. Better, but still not accurate.

Using a 0.01 second timer, you'll measure 3.52 seconds between pulses. 60 / 3.52 = 17.05 CPM. Pretty darn close.

Ideally, if you could use a 0.001 second timer, you'll measure 3.529 seconds between pulses. 60 / 3.529 = 17.00. Not EXACTLY 17 when you look past 2 decimal places, but we'll ignore that... ;)

This had its good and bad points. The good part is that the display updates EVERY CYCLE, so you know the CURRENT speed (er, the speed of the most recent cycle). The bad part is that the display updates EVERY CYCLE, so if the speed of each cycle varies, the numbers jump around. This is not good if you're trying to figure out how many cartons you'll get in an hour, day, week, etc... You may want to look at averaging the speed of each cycle over time... :confused:

I have found my method to be quite effective on slower (<100 cycles per minute) equipment. When you start going faster, the 0.01 second timer isn't good enough. Including decimal places in the display is worthless, because you will always get 'fixed' numbers.

0.60 second cycle = 100.00 CPM
0.59 second cycle = 101.69 CPM
0.58 second cycle = 103.45 CPM
0.57 second cycle = 105.26 CPM
0.56 second cycle = 107.14 CPM
0.55 second cycle = 109.09 CPM
0.54 second cycle = 111.11 CPM
0.53 second cycle = 113.21 CPM
0.52 second cycle = 115.38 CPM
0.51 second cycle = 117.65 CPM
0.50 second cycle = 120.00 CPM

But, even if you round off the decimals, you skip numbers.

0.60 second cycle = 100 CPM
You'll never see 101
0.59 second cycle = 102 CPM
0.58 second cycle = 103 CPM
You'll never see 104
0.57 second cycle = 105 CPM
You'll never see 106
0.56 second cycle = 107 CPM
You'll never see 108
0.55 second cycle = 109 CPM
You'll never see 110
0.54 second cycle = 111 CPM
You'll never see 112
0.53 second cycle = 113 CPM
You'll never see 114
0.52 second cycle = 115 CPM
You'll never see 116 or 117
0.51 second cycle = 118 CPM
You'll never see 119
0.50 second cycle = 120 CPM

With a 0.01 second timer, faster is even worse. Numbers jump by leaps and bounds. 200, 207, 214, 222, 231, 240... :eek:

Keep this in mind if you decide to go the 'sprocket' route. Don't go for the maximum number of teeth you can get. If the pulses come too often, you can't measure them accurately with a 0.01 second timer.

Again, we'll go back to that "17" number.

Let's say you choose 20 tooth sprocket (at 17 CPM), your pulses will be 0.17647 seconds apart. Since you can only measure to 2 decimal places, you will only see 0.17 seconds between pulses. Your display will show 17.65 CPM. If you speed up the machine slightly and measure 0.16 seconds between pulses, your display jumps to 18.75 CPM. You will never display a number between 17.65 and 18.75... :cry:

4 tooth sprocket at 17 CPM. Pulses are 0.88235 seconds apart. You read 0.88 seconds with your timer. Display reads 17.05 CPM. Speed up so the timer changes to 0.87 seconds. Display reads 17.24 CPM. Much better!... :cool:

Bottom line, more is not always better, unless you have the timer accuracy to match... :nodi:

OK, enough of my rambling... :rolleyes:

🍻

-Eric
 
MJ...

You are mixing apples and oranges...

"say my production speed is 17 cartons per minute. So basically I produced 17 cartons!"

This is a fallacy. Let's take an extreme example... the conveyor is up to speed but no cartons are on the line. Your line might be running at a rate of 17 Cartons per Minute, but you haven't produced a single carton!

If the line has been running at 17 Cartons per Minute for 2-hours, and then you increase the speed to 18 Cartons per Minute. Seeing 18 Cartons per Minute on the display DOES NOT mean that you have produced 18 x 60 x 2 = 2160 cartons. You have actually produced only 17 x 60 x 2 = 2040 cartons! You need to keep the Rate and Count separate!

You can easily develop two pieces of information... current-carton-rate, and actual cartons produced. Neither should be bound to the other. You need to recognize that you shouldn't use one to derive the other. Generate and maintain each number separately. Use the prox on the conveyor to determine the rate, and another prox, or photo-eye, to count actual production. Keep the two numbers separate.

Now, if indeed a single carton is produced between consecutive pulses then... using Eric's scheme, you simply need to measure the time between pulses. And of course, the finer the timer resolution the more accurate the result.

DO NOT COUNT PULSES!

Now, be aware... while the conveyor speed is changing your rate will be changing and it will NOT be accurate. If conveyor speed is increasing then your rate will be increasing. If conveyor speed is decreasing then your rate will be decreasing. In either case, your current display will be lagging behind the actual rate. As the line becomes slower and slower, the currently displayed rate will be just a bit faster than the actual rate... at least until the next pulse. As the line becomes faster and faster, the currently displayed rate will be just a bit slower than the actual rate... at least until the next pulse. This will continue to be true until the speed of the conveyor is stable.

Once your conveyor speed stabilizes your rate will be stable. Your rate-of-update will be equal to your pulse rate. That is, your rate will be updated on each pulse. Of course, this means that the slower your line is running the slower your rate is updated.

Now, you say that you get a pulse after each carton is produced. However, you also say that there is a slight lag between the production of a carton and the pulse. If you develop your scheme as described above then the timing relationship between the actual production of a carton and the pulse won't be critical.

However, it wouldn't hurt to adjust your prox, or the thing that the prox reads, so as to better synchronize the pulse with the completion of the carton. But again, this won't matter a great deal.

If you add another pulse target per carton, you will have to change your math to accommodate 2-pulses per revolution. This will increase your update-rate and, while speed is changing, your current rate will be more correct twice as often.

BE AWARE! The additional pulse target must be located at exactly 180-degrees from the first!

If the second target is off by just a bit then, depending on your actual speed and the timer resolution, you might get a slight fluctuation in the current rate... faster, slower, faster, slower... Whether or not this shows up on the display depends on the actual rate calculated on each pulse and the resolution displayed.

For example, if your actual current rate is 17.000 cartons per minute and the second target is off by a degree or two you might get values displayed ranging between 17.010 and 16.090 (ignore the math here... it's just to provide an example). If your display is configured to show ##.# (tenths of cartons) then you will see 17.0 and 16.0 alternatively... even though the real difference is only a small fraction of a carton. It is probably better to use only the one target.

What you are attempting to do is a bit like (maybe a lot like) trying to circumvent the law in physics that says you can not measure both speed and position at the same time.
 
Last edited:
Arrest me. I broke a law of physics. I break it all the time!!!

Terry Woods said:
Terry Woods said:
You are mixing apples and oranges...



"say my production speed is 17 cartons per minute. So basically I produced 17 cartons!"



This is a fallacy. Let's take an extreme example... the conveyor is up to speed but no cartons are on the line. Your line might be running at a rate of 17 Cartons per Minute, but you haven't produced a single carton!



If the line has been running at 17 Cartons per Minute for 2-hours, and then you increase the speed to 18 Cartons per Minute. Seeing 18 Cartons per Minute on the display DOES NOT mean that you have produced 18 x 60 x 2 = 2160 cartons. You have actually produced only 17 x 60 x 2 = 2040 cartons! You need to keep the Rate and Count separate!



You can easily develop two pieces of information... current-carton-rate, and actual cartons produced. Neither should be bound to the other. You need to recognize that you shouldn't use one to derive the other. Generate and maintain each number separately. Use the prox on the conveyor to determine the rate, and another prox, or photo-eye, to count actual production. Keep the two numbers separate.


yes, finally.

Terry Woods said:
Now, if indeed a single carton is produced between consecutive pulses then... using Eric's scheme, you simply need to measure the time between pulses. And of course, the finer the timer resolution the more accurate the result.


Eric's doubling scheme is wrong for reasons Terry just stated and Ron was wondering about. Consider two sensors, one just a little down stream of the other and measure the time between leading edges.

Terry Woods said:
DO NOT COUNT PULSES!


I agree.

Terry Woods said:
Once your conveyor speed stabilizes your rate will be stable. Your rate-of-update will be equal to your pulse rate.


What pulse rate, I thought you said NOT to count pulses! Count cartons.

Terry Woods said:
That is, your rate will be updated on each pulse. Of course, this means that the slower your line is running the slower your rate is updated.



Now, you say that you get a pulse after each carton is produced.



You mean leading edges from the cartons don't you?

Terry Woods said:
If you add another pulse target per carton, you will have to change your math to accommodate 2-pulses per revolution.





Are you suggesting measuring the time of the falling edge of the widget? The widgets had all better be the same length and oriented the same way for this to work.



Terry Woods said:
This will increase your update-rate and, while speed is changing, your current rate will be more correct twice as often.



BE AWARE! The additional pulse target must be located at exactly 180-degrees from the first!



Now you are back to counting pulses which you said not to do. I thought mjamil should be counting cartons. Which is it?

Terry Woods said:
What you are attempting to do is a bit like (maybe a lot like) trying to circumvent the law in physics that says you can not measure both speed and position at the same time.


I measure position and velocity all the time. We are not measuring the position and speed of subatomic particles. I can also calculate accelerations under the right circumstances.

Eric Nelson's example is flawed. Hint, I have written about this many times. Timers and counters on PLC look simple and are simple to use. They just get used incorrectly. Counters and timers don't even get implemented by the PLC companies correctly. You would think the PLC companies would know better.

Down with software timers and counters.
Long live the hard counter or timer with latches!! Another hint.

Ron, you are right about needing some sort of filtering or averaging for best results.
 
Peter, we aren't measuring the rate of widgets passing a sensor here. We are measuring revolutions per minute of a shaft, which just 'happens' to equal cartons per minute in mjamil's application. I think you're picturing cartons moving down a conveyor past a sensor.

Basically, what mjamil is doing is calculating RPM of a slowly rotating shaft using a 1 PPR encoder. Terry's "additional pulse target must be located at exactly 180-degrees from the first!" would be like swapping in a 2 PPR encoder.

Sorry, but I use this method ALL THE TIME, and it works EXTREMELY well for slow machines... :nodi:

🍻

-Eric

P.S. What is my 'doubling scheme'?... :confused:
 
"What pulse rate, I thought you said NOT to count pulses! Count cartons."

If he gets one pulse every .333-minutes... well don't you think that is a rate?

I said...
"Once your conveyor speed stabilizes your rate will be stable. Your rate-of-update will be equal to your pulse rate."

I never said count pulses... I said measure time from pulse to pulse. And I said, count cartons separately... because... since I don't know the true nature of his machine, I have to assume that the line might be able to run without cartons! If so, then the line speed MUST be measured by the pulse-to-pulse time on the conveyor!

I also said... Don't mix the two numbers... keep them separate!

If he gets 1-pulse per ??.?? sec then the update rate is 1-update per ??.?? sec.

Peter, surely you recognize the corollation between pulses per time-unit and time-units per pulse?

You know as well as I do that the rate in cartons-per-minute can be extrapolated from the time from pulse-to-pulse.

If the time from pulse-to-pulse is .333 minutes, then his rate is 1/.333 = 3.003 cartons-per-minute.

If he gets one pulse every .333 minutes then his carton-per-minute rate is updated every .333 minutes. Because there is one pulse per carton (assuming there is a carton), regardless of how/where the pulse and carton are synched, the rates are the same. Pulse-rate = Update-rate.

"You mean leading edges from the cartons don't you?"

Counting cartons has nothing to do with the speed of the line. What if, somehow, an expected carton is missing?

If his code is adequate, it will recognize that a carton is not present and ready to be packed. And yet, because he is watching the pulses from the prox, he can still know the speed of the line.

I also said...
"If you develop your scheme as described above then the timing relationship between the actual production of a carton and the pulse won't be critical.

However, it wouldn't hurt to adjust your prox, or the thing that the prox reads, so as to better synchronize the pulse with the completion of the carton. But again, this won't matter a great deal."

With respect to speed, the important factor is the conveyor... not the carton. After all, a carton might not be present in a particular slot!

"Are you suggesting measuring the time of the falling edge of the widget? The widgets had all better be the same length and oriented the same way for this to work."

Again, I did not say to make speed measurements based on cartons. Speed measurement is a conveyor-only issue. Carton-count is a carton-only issue!

"I measure position and velocity all the time."

I assume that you are saying that you measure both at the same time and that both measurements are accurate.

This is another fallacy.

If you are measuring velocity based on position, then you are measuring speed based on the difference between the last position and the position at "this time".

If the two positions are different, then you will calculate a NON-ZERO velocity at "this time"... EVEN IF THE CURRENT VELOCITY IS ACTUALLY ZERO AT "THIS TIME"!

This is associated with the inherent latency in all PLCs that I described in another thread. It is also associated with the algebraic approximations that we commonly use instead of real calculus.

The algebraic approximations must necessarily be based on time-segments no smaller than scan-time.

The real calculus version is based on time-segments which are INFINITELY close to Zero-Time!

PLCs CAN NOT do this... because of the latency involved in scan-time!

Just to be anal about it (I love being anal), there ain't no "digital system" in the world that can do what real calculus does!

Granted... in normal human scales, an algebraic calculation that is within .000,001 units is pretty damned close to real. However, in astronomical scales, an error of .000,001 could mean an error of millions of miles relative to the destination. Why do you think the concept of "mid-course corrections" exists?

This brings to mind...

There was a time when Newtonian Physics was thought to be the ultimate tool for predicting the future status of the universe and all.

It was found, a few hundred years ago that this wasn't so.

Why? Because, regarding Newtonian Physics, the math was only adequate for "two-body" gravitational relationships.

Later it was relized that there was something else.

Newtonian Physics is absolutely based on the idea that time is constant.

Then, along comes this little upstart named Al...

Al says, Issac, you're really cool and you did good, real good... but... with respect to this gravity stuff... you're full of shiss!

Al says... your gravity stuff would be really cool if you recognized that time is NOT absolute!

Then some other guy comes along (I don't remember who it was.. Hiesenburg?) and recognizes that, along with Al's issue, in order to make long-term (time-wise) and long (distance-wise) projections, initial conditions, such as position, velocity and acceleration must be measured to the n-th degree.

We don't do n-th degree measurements. We CAN NOT make n-th degree measurements.

Therefore... ALL of our great celestial prognistications are only approximate!
If we send a space probe, we must constantly be on the watch for the necessity of making "mid-course corrections".

Isn't funny... we can't accurately predict the long range or the short range. In fact, we can't accurately predict anything!

We can try to be in control... but ultimately, we have to respond to conditions as they occur. From moment-to-moment, we depend on "what really is", even if it ain't exactly what we predicted it would be.

Damn... there's something existential in this...

Oh man... does this open a can-o-worms...
 

Similar Topics

Hi everyone, I don't know much of PLCs but it happened that i need to connect Leuze AMS358i Ethernet laser measurement to Productivity 1000...
Replies
0
Views
1,049
Hello everyone! Firstly I'd like to say that I'm new to this forum and also new to PLC programming world altogether, that said I really would...
Replies
27
Views
4,768
I am looking for a way to determine level in a silo. The material is called Perilite which has a very light density. Bulk density could be...
Replies
10
Views
2,722
In our water cooling tank, I've installed and successfully wired up 4 float switches & updated the PLC (big thanks to @parky for that). As a...
Replies
46
Views
11,271
Hello, I have an application where I need to measure the salt level/volume in a salt saturator. This is a fairly large tank where we load bulk...
Replies
21
Views
6,459
Back
Top Bottom