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?