measuring RPM - Siemens S7200

[Terry Woods]

Yes!!! I Do!!!

Reality is a very interesting concept!

Dealing with reality is equally interesting!

 

[elevmike]

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.

mjamil,

In my opinion you need a higher count encoder, so that you can update the RPM once every second. For example if you had a 600 ppr encoder, and the shaft was turning 1 rpm then 1 second would give you 10 pulses. This would provide a more "realtime" & accurate RPM reading.

 

[Eric Nelson]

I still like timing from leading edge to leading edge (or trailing to trailing if you prefer) of one point in the cycle. This gives you the ACTUAL time of one cycle, which is the info needed.

I agree that if the speed was 1 RPM, I would want more than 1 pulse per cycle. Who wants to wait a full minute for an update? 60 pulses might be appropriate, but not 600.

But, what if the speed of the machine varies throughout the cycle. Maybe an eccentric load which goes down fast and up slow. If the figure we're looking for is full cycles per minute, do we really care how fast it's moving at multiple points in the cycle? Yes, I know YOU do, Peter. I'm talking about the rest of us...

Let's say we have an eccentric motion with a 2 PPR encoder. Although exactly 180° apart, one pulse is at the top of stroke, and the other at the bottom. Now we are measuring 2 different speeds. The DOWN speed, and the UP speed. Neither is the actual cycles per minute.

But wait, you say. We can just average the two speeds to get our cycles per minute! Yes, you can, but now you get an update once per cycle, negating the need for more than one pulse per revolution.

Assuming mjamil's application is a constant speed throughout the cycle, I would agree to adding a FEW more pulses per revolution (EQUALLY spaced of course!) to get the updates to around 1 per second. Anything more would be an exercise in futility.



-Eric

 

[Peter Nachtwey]

Terry, you know I know the difference between counting pulses per period or the period between pulses. This is basic encoder 101 stuff.

About measuring postion and speed. You make good a point, but your example assumes the accelerations has made a sudden change. This is not normally the case, but this case can't be ignored. Your example is valid when a hydraulic actuator runs into the end of the cylinder or dead heads against an obstruction.

I have never seen a production line where every slot is full and the speed of the conveyor can be used to accurately indicate the production rate. We counted the boards per time period when programmed lumber sorters. Sorter systems run with a lot of empty lugs so the speed of the lugs was not a good indicator of production. I think counting cartons is the proper way for mjamil to calculate production rates and totals.

More important is the issue of the proper use of counters and timers. Eric still doesn't see the error of his ways. Can any of the PLC/motion experts find the error?

stn564, this problem is simple. So what is Eric doing wrong?
Maybe this is simpe, but not obvious.

 

[Eric Nelson]

Eric still doesn't see the error of his ways. Can any of the PLC/motion experts find the error?

Oh, great. Another one of Peter's nonsensical 'quizzes'...

Must be a typo or poor explanation in my post. I know the program works, 'cause I've got probably 100 machines in the field using it with no problems.



-Eric

 

[rsdoran]

Y'all got into rocket science and left me behind. I do know more than I want about carton (case) makers, carton packers and carton sealers.

I am simple. I also dont understand the original method used to get the "production rate". RPM, revolutions per minute, implies a speed of something like a conveyor.

The simple method is to use time from leading edge to leading edge (or trailing) as Eric mentioned. Using this you "predefine the counts you want..lets use 4 counts and time elapsed is 15 seconds, that would give you a "production rate" of 16 PIECES per minute.

I have found that production (management basically) wants to know the basic rate but what they really want is a "total" and "average" of the production rate.

If "rate" varies alot the HMI could change alot using the above method...ie constantly changing from say 10 to 20 PIECES per minute so after a minute you could switch to Erics method which would update every minute.

TECHNICALLY all or any of this is just to give a display of "WHAT THE RATE IS NOW"...ie a supervisor etc can look and see someone is not running fast enough right NOW. It has no real bearing on actual run rate.

A simple method, to obtain a "running average", is to use a retentive timer and maintain a "constant" count of production then every 15 seconds divide the "count" by the accumulated time in the retentive time. This can provide seveal things, a total count that has been produced, total "actual" run time and the "average" pieces per minute produced, and update the HMI on a regular basis.

I dont have the S7-200 software to provide an example. As Terry mentioned there can be some "timing" issues due to scan and the accuracy of the timers but as long as you have the "actual count" of items produced then you will always be able to determine an "average" production rate and a very close approximation of the "actual" run time for the machine.

As an example, your count is 4 at 15 seconds. 15 divided by 60 equals .25. 4 divided by .25 = 16 pieces per minute. Machine has run for 1 minute (60 seconds) and count equals 17. 60 divided by 60 = 1. 17 divided by 1 = 17. Later ON...the count is 1112 and you have run 65 minutes and 17 seconds (3907 seconds). 3907 divided by 60 equals 65.116. 1112 divided by 65.116 = 17.02.

Just depends on how accurate you want it to be what you will display. I hope I explained this correctly. The original methods talked about "WHAT IS THE RATE NOW" which can vary alot from minute to minute. What I have mentioned is an AVERAGE RUN RATE in a specific time period with the option of having and displaying total count for that time period. With this last method all you do is directly count the product, if missed counts can be an issue then some redundancy may be needed.

 

[Terry Woods]

I'll get to the timer issue later. But, first, let's take another look at the "question".

MJ wants to have a "number" on the screen for the production folks. What is that number supposed to represent?

Here is a timing chart that indicates cartons as they are produced and pulses from the conveyor as they occur.
Let's assume that the conveyor is running at a constant speed.

CARTONS   X_|_|_____|_|_|_|_|___|_____|_|___|___|_|__13-Cartons

CONVEYOR  X | | | | | | | | | | | | | | | | | | | |  20-Pulses

PULSES    |------------------- 1-Min ------------>|

So... What does this tell you?
This particular minute starts at "X".
In this particular 1-minute segment, 13-Cartons were produced and there were 20-pulses from the prox.
It's pretty safe to say that there is 3-seconds between pulses. 1-Pulse every 3-seconds.
And, without a doubt, 13-Cartons were produced in that minute.

Now, let's look at the next 1-minute segment. This segment begins 1-pulse after the previous segment started...

CARTONS   X_Y_|_____|_|_|_|_|___|_____|_|___|___|_|___ 12-Cartons

CONVEYOR  X Y | | | | | | | | | | | | | | | | | | | |  20-Pulses

PULSES      |------------------- 1-Min ------------>|

Now, let's look at the next 1-minute segment. This segment begins 1-pulse after the previous segment started...

CARTONS   X_Y_Z_____|_|_|_|_|___|_____|_|___|___|_|_____ 11-Cartons

CONVEYOR  X Y Z | | | | | | | | | | | | | | | | | | | |  20-Pulses

PULSES        |------------------- 1-Min ------------>|

.
It appears that I'm changing my approach... counting pulses... however, this approach is not based on consecutive time-segments... rather, it is based on over-lapping time segments. The method shown above is a "flying time-frame". The range of the frame is 1-minute and it is updated every 3-seconds.

What does this tell you?
In this particular 1-minute segment, 11-Cartons were produced and there were 20-pulses from the prox.
Again, it's pretty safe to say that there is 1-Pulse every 3-seconds.
This particular minute starts at "Z"... 2 x 3-sec = 6-secs after "X".
And, without a doubt, 11-Cartons were produced in this minute.

So... Which is it? Is the line producing 13-Cartons per minute, or 11-Cartons per minute?
Within 6-seconds, the production rate appears to have been reduced by more than 15% !!!

If carton-flow is going from right to left, then you can see that no cartons were actually produced in the last 2 pulses... What does that mean?

If the operator was told to maintain 13-Cartons per minute, and then he sees "11-Cartons per minute" on the display... do you think he might be tempted to crank-up the line speed?

And yet... even though the "actual carton-rate" has changed... the pulse-rate from the conveyor (the theoretical carton-rate) remains constant. The conveyor is actually running at a speed that would support 20-Cartons per minute... however, for whatever reason, the process is outputting less than 20-Cartons per minute.


So... which number is really meaningful?

If the line is expected to run at 20-Cartons per minute but the displayed number indicates less than 20... all that can be surmised is that, in the last segment, the output was less than expected.

So... What does this mean? Is the line running too slow? Are cartons missing?

Counting cartons in this manner for the sake of a carton-rate is clearly ambiguous. If the carton-rate IS as expected then it would appear that all is well. However, if the carton-rate is NOT as expected... then the reason is lost... it is either because the line is too slow -OR- because there are missing cartons!

So... What is the more important piece of information?
Is it the Line-Speed which provides the Theoretical-Carton-Rate?
Or is it the Actual-Carton-Rate?

To regulate the performance of the process, you need to know the Theoretical-Carton-Rate. This is based on the speed of the conveyor (line speed).

Then, to track the actual output, you need to make an actual carton-count. If there is a chance that cartons might be missing then, in terms of controlling the speed of the line, it would be fruitless to try to calculate a carton-rate from the actual carton-count. You would end up chasing phantoms.

To see how actual output compares to theoretical output, you simply subtract the actual count from the theoretical count for a given period. This will simply indicate the difference between theoretical and actual. This number will be zero if the actual count matches the theoretical count. If not zero, then the number will be Negative. This indicates that the actual count is behind the theoretical count. Actual count should never be ahead of the theoretical count. Is this really useful information? I think not.

If you wanted, if you saw value in it, you could calculate what the theroretical carton-count would be in, say, 1-hour, or 2-hours.

For example, if you need to fill an order of 1000 cartons in 1-hour, then, using the current theoretical carton-rate (line speed) you could display how many cartons will be processed at the current theoretical carton-rate in 1-hour. If that number is less than 1000 then increase the speed of the line until the number shows 1000.

This assumes that you can run the conveyor without cartons. Once you have the speed you need, then push the button that actually starts the cartons feeding through the line. Assuming that the actual count follows the theoretical count, you will get your 1000 cartons in 1-hour. If the actual count does NOT necessarily follow the theoretical count then it's gonna take longer... how much longer??? You could do a calculation that projects how much longer based on the current actual count and the theoretical carton rate. But then... that number is likely to vary quite a bit if your actual rate does not follow the theoretical rate.

Consider the case where you are downloading a pirated copy of your favorite movie from the Internet... the window on the screen shows the "expected time remaining". Depending on traffic (actual conditions) this number might bounce all over the place. This number is NOT necessarily accurate in terms of the final time... it is only accurate with respect to current conditions... and the current conditions might change.

There are all kinds of games that you can play with counts and rates. You just need to be clear on what information is really meaningful.



TIMERS:

The smaller the time segment being measured... the less accurate the measurement. This is especially true with PLCs... because of the scan-time.

6000-pulses in 60-seconds => 100-Pulses per second.

If each pulse-to-pulse represents 2 and 1/3 inches (2.333... inches),
then 100-pulses = 2.333 x 100 = 233.300 inches... this is NOT 233.333... hmmm... small error...

Now, 100-Pulses per second => .010-seconds between pulses.

Now, assuming a constant speed, if the PLC has a scan time of 24-msec, then the range of times between detected pulses is anywhere between .010-seconds to (very close to) .034 seconds.

If .010-seconds represents 2.333... inches, then .034-seconds represents 7.932 inches... hmmm... BIG ERROR!
If .010-seconds represents 1-unit, then .034-seconds represents 3.4-units... BIG ERROR!

More accurate calculations result if the measurements are made on a much larger scale. However, by using a larger scale, the time between calculations is increased. That is, unless you use a "flying time-frame".

There is, however, a problem associated with the "flying time-frame". The frame must be filled before the first accurate result is obtained. Again, however, once the frame is filled, results can be had on every increment of the frame. So... if the frame is 60-seconds wide, and updated every second, then it takes 60-seconds to fill the frame and produce the first result. But then, from that point on, a result is produced every second. This is a "pipe-line" thing.

So... how to resolve the whole issue...?

First, I think MJ needs to really think about what kind of information he wants to provide.

Then, he needs to develop that information in a manner that will provide the most accurate result.

I think that the best way is to calculate the theoretical carton-rate with a "flying time-frame". This works best when the process has stabilized on a constant speed. It is less accurate during speed transitions. However, it becomes accurate again once the line stabilizes. If the speed is decreasing then the average speed will also decrease, however, at a much slower rate than the actual speed is decreasing. Likewise for increasing. In the example given above, it would take 1-minute for the displayed rate to equal the actual rate... this seems a bit too long.

The larger the window, the longer it takes to have the average match the actual. So... the window needs to be as small as possible to cause the average to follow the actual as closely as possible... and yet large enough to overcome the problem associated with error caused by scan-time.

Hmmm... maybe a dynamic-flying-time-frame... one that adapts to the last scan-time... hmmm... that could work.

ooohhh... this is hurting my head!

MJ, what kind of information is the production folks REALLY looking for?

 

[Terry Woods]

Backing up... way back...

1-Pulse = 1-Carton (theoretically)...

Pulse-to-Pulse = Instantaneous Rate
(Subject to Scan-Time Error)

Pulses/Period (Consecutive Periods) = Average Rate for the given Period
(Updated on Consecutive Period Boundaries, Calculated value lags behind actual value during speed transitions)

Pulses/Period (Over-lapping Periods) = Average Rate for the given Period provided on each Pulse
(Updated on Consecutive Pulses, Calculated value lags behind actual value during speed transitions)

 

[Eric Nelson]

I guess they're stumped?...

Eric still doesn't see the error of his ways. Can any of the PLC/motion experts find the error?

OK, it's been a week and none of the "PLC/motion experts" have spoken. Care to clue me in?...



-Eric

 

[Peter Nachtwey]

Don't reset the counter or timer!!!!

1. Every time you reset the counter or timer you lose on average half a count or time tick. Counters or timers should be free running and never stop. Those PLCs that only allow counters or timers to count to 32767 and then stop are flawed.

2. One should latch or read the timer or counter only once per interrupt. Reading counters or timers at variable intervals such as scan times is not very good as scan times vary too much. If counting encoder pulses per time then a timer should latch the count of the pulse. Hopefully this can be done in hardware withour software intervention. Most high speed counters can't do this. They can only reset the timer or counter. If you access the timer or counter twice per scan or interrupt there is a possibity that the counter or timer can change between the two readings.

3. The previous latched value should be subtracted from the current latched value. The difference between two latched readings can be accumulated in a 32 bit counter or timer. This would be easier on a 16 bit computer if there was an easy way to sign extend the difference to a 32 bit number so and 16 bit PLCs provided an easy way to add two 32 bit numbers together.

If your encoder is giving 450 pulse per second and your timer is set to provide an interrupt every 10 milliseconds ( .01 sec ) then you will get 4.5 pulses per interrupt. If you reset the counter during the interrupt then you will get only 4 counts. Now you must hope your counter will provide 5 counts the next time period. Some will, some won't. However, if you never reset the counter and you access it only only once per interrupt then you know that the counter will never loose counts as long as the counte keeps counting. What you loose on one scan is added to the next. In this case the counter should provide 4 counts one scan and 5 the next then back to 4 then 5 again.

The difference in counts should be filtered or averaged as Ron and Terry suggested to calculate the speed. I prefer the low pass filter. As mentioned above, averaging or filtering adds phase delay. The difference can be accumulated in a 32 bit accumulator to calculate distance beyond what the 16 bit counter can provide.

The best way to get the line speed is to read it directly from the drive or motion controller instead of using the PLC to calculate the speed. If the PLC must calculate the speed then it would be better if the PLC can get a +/- 10 volt signal from the drive or motion controller that is proportional to the velocity. This control signal can be filtered along with the speed calculated from the encoder to predicted speed or position that has much less noise or jitter and little or no phase delay compared to just using the encoder counts by themselves.

Eric, in mjamil's case your suggested method would work pretty well and no one may know the difference. However, a S7-200s timers update asychronously in during the scan. This allows one to lose time unless one reads the counter only once. You can see that accessing the timer or starting another timer will lose time. A problem with the S7-200 is that the timer stops at 32767 which is bad. I prefer PLCs that have a millisecond or microsecond hardware system counter that can't be reset and is always counting. A motion controller should be able to keep track of position and speed so it knows where it is at the end of the shift. Nothing should be lost.

PLC counters and timers are fine as long as one is not using them to continously measure the time between the same event.

 

[AutomaticLeigh]

However, a S7-200s timers update asychronously in during the scan.

True for 1ms timers, but 10ms timers update at the beginning of each cycle. The S7-200 also has a 1ms interval timer, which counts up to 2^32, and a calculate interval time instruction which includes rollover calculation.

 

[Peter Nachtwey]

I have micro win.

I couldn't find any info about a free running timer. How do you read the timer? Is it a system register?

 

[DesertDog]

Try This Post from This Thread.

 

[AutomaticLeigh]

I'm not a regular S7 user, so maybe this timer only appeared in the latest versions. Here's a snippet from a program I'm using to make a simulated axis for a conveyor. The speed is nothing heroic - about 140 products/minute, so 1ms timer gives reasonable position indication.

BGN_ITIME reads the current value of the system timer, so this gets read by a cam edge as a start value. CAL_ITIME computes the interval from the input value to the current time, which is my current paddle position.

Hopefully there is a file attached...