Parts Per Minute calculation

What are you going to do with this value (parts per minute) when you get it?

What difference does it make if the value is 59 or 61?

Is this some management knee jerk let us have a metric - we arent gonna do anything with it we just want a number fiasco??

OR is this value going to be used downstream at the next step of the process to control the speed of something?

Dan Bentler

leitmotif said:

What are you going to do with this value (parts per minute) when you get it?

What difference does it make if the value is 59 or 61?

Is this some management knee jerk let us have a metric - we arent gonna do anything with it we just want a number fiasco??

OR is this value going to be used downstream at the next step of the process to control the speed of something?

Dan Bentler

Click to expand...

The cycle rate is needed for setup. 60 parts per minute is the standard and if exceeded causes issues upstream and downstream. We can run less without any issue but when we go above it causes problems.

60 parts per minute is the standard and if exceeded causes issues upstream and downstream. We can run less without any issue but when we go above it causes problems.

Click to expand...

Then measure the time for each part (in seconds) and MULTIPLY that by 60 to get the Parts per Minute.

Parts/Second X 60 Seconds/Minute = Parts per Minute.

If Parts/Minute > 60 Then "Do Something"

If you use a 0.01 second time base for your timer, then multiply its value by 0.6 (instead of 60) to get parts per minute.

As pointed out before by others, if the rate is varying a lot, going above and below 60/minute, then you cannot take action on EVERY part, but you must look at the AVERAGE time per part, not the instantenous time for each part. If that is the situation, you will have to decide over how long a period to take a running average. It seems like in your case it should be a 30 second running average. If the 30-second running average PPM > 60, then "Do Something" so that the 60-second running average never exceeds 60 PPM.

One of the best i've used is to count each part for 10 secs then store values in say 6 registers shifting down data register every 10 secs, add up the registers & divide by 6 (number of registers) this will give you a running total every 10 secs of the true minute count, initialy it will read lower than actual but increase every 10 secs until the actual count is the required value (at the minute interval) however this will rise over the minute, this gives a slow rise/fall in parts per min & when running an average over one minute.

This is not to everyones taste as some like instant rate by counting millisecs between parts to calculate realtime ppm.
Counting every 10 secs & using this by multiplying 6 gives you only the value of ppm only in the 10 second time frame so if you get 10 parts first 10 secs then 15 parts the next 10 secs & so on this is not ppm but parts per 10 secs *6 & assumed to be ppm.

Then measure the time for each part (in seconds) and MULTIPLY that by 60 to get the Parts per Minute

Click to expand...

Measuring the time for each part gives you Seconds/Part not Parts/Second.

If the measurement is done using a 1/100 second timebase as I showed then the value of the accumulator is actually 'hundreths of a second/part'. We then take 6000 which is 'hundreths of a second/minute'. We divide this by the time which is the same as multiplying by the reciprical ('parts/hundreths of a second') which then give parts/minute'

You guys still don't get it.

60/1.02=58.923 Parts per minute
60/1.03=58.252 Parts per minute
60/1.04=57.692 Parts per minute
etc
There is plenty of resolution. The calculations aren't the problem. I can't believe no one has come forward with the answer.

Machine Speed (parts per minute)

I do Machine Speed (up to a few hundred a minute) as follows:
Using S7-400 I use a cyclic interupt OB running every 20mS to count pulses from either a prox. switch "looking at" a cam or from the electronic Machine controller. Either way I pay particular attention to get the Mark Space (ON time OFF time) ratio as close to 1:1 as possible.
I use a time of day interupt OB running every minute to read and reset the counter moving the count into a 10 slot FIFO array.
Every minute the ten values in the array are averaged thus providing an updated Machine Speed every minute that is the average
of the previous 10 readings. The average is of type REAL so there is no loss of precision.

John Gaunt said:

I do Machine Speed (up to a few hundred a minute) as follows:
Using S7-400 I use a cyclic interupt OB running every 20mS to count pulses from either a prox. switch "looking at" a cam or from the electronic Machine controller. Either way I pay particular attention to get the Mark Space (ON time OFF time) ratio as close to 1:1 as possible.
I use a time of day interupt OB running every minute to read and reset the counter moving the count into a 10 slot FIFO array.
Every minute the ten values in the array are averaged thus providing an updated Machine Speed every minute that is the average
of the previous 10 readings. The average is of type REAL so there is no loss of precision.

Click to expand...

You too are doing it wrong. You can see from my example that only one interval is required to provide all the precision necessary. Averaging over one minute hides the flaw in your technique.

Obviously, you can time the interval between pulses and calculate the Machine Speed but I suspect that it will usually increase the load on the CPU over that required to count pulses.
I prefer to count events because the parts count at the machine and at several points thereafter is for me the object of the excercise.
For my application the Machine Speed is just a useful almost no cost "by product".

Can you put a little better technical wrapper around 'haywire' and 'really slow speed'? Does the speed go 'haywire' on the second calculation after you get to the 'really slow speed'? Do you transition from OK to 'haywire' in a very small speed decrease?


Keith

You should just measure minutes per part with the highest resolution available and invert it to get parts per minute.

If the timer has overflow characteristics as in an A/B processor, then make sure you don't lose those milliseconds...

Then, if you know the capable rate of change of the machine, you can filter out bogus values, and should be able to get a smooth running average that is only a few samples behind.

OOPS, Bernie already said that...so it's two votes for the above method...

EDIT:I still want to know what other I/O are available. How are speed cahnges accomplished? Speed pot to a drive? Reeves pulley?

Peter?
What say you?

Lead us toward the proper filter if we have omitted something important to learn from...

OkiePC said:

You should just measure minutes per part with the highest resolution available and invert it to get parts per minute.

Click to expand...

In my example I used 10 millisecond increments. I agree that 1 millisecond resolution would be better but resolution isn't the problem.

If the timer has overflow characteristics as in an A/B processor, then make sure you don't lose those milliseconds...

Click to expand...

Lose milliseconds? Yes, if the time between pulses is greater than 655.35 seconds then the timer will overflow. How do you fix this? The simple thing to do is to say the rate is 0 when the timer overflows. This isn't the main problem.

Then, if you know the capable rate of change of the machine, you can filter out bogus values, and should be able to get a smooth running average that is only a few samples behind.

Click to expand...

No filtering is needed. Isn't my example with 1 reading and 10 millisecond resolution enough to prove that?

Peter Nachtwey said:

In my example I used 10 millisecond increments. I agree that 1 millisecond resolution would be better but resolution isn't the problem.


Lose milliseconds? Yes, if the time between pulses is greater than 655.35 seconds then the timer will overflow. How do you fix this?

Click to expand...

In a/b machines, the timer ACC can overflow the PRE. If the timer is updated and has overflowed by more than 1 (of the units chosen), the ACC will be larger than the PRE.

Peter Nachtwey said:

The simple thing to do is to say the rate is 0 when the timer overflows. This isn't the main problem.

Click to expand...

For this exercise, you may not need those milliseconds in your rate math, but if the PLC he is using has a similar problem and does not store any overflow for use in the math...

If it took 1.02 seconds to make the part, and you measured it as 1.05, then reset the timer (kinda like resetting an encoder in motion) you will lose 30 milliseconds of accuracy...

No big deal, the resolution is there. In applications like shift production projections, that error gets amplified.

In a/b machines, to prevent that error, I don't reset the timer, I just turn it back a known amount, and put the preset at a value it will never reach.

Peter Nachtwey said:

No filtering is needed. Isn't my example with 1 reading and 10 millisecond resolution enough to prove that?

Click to expand...

Yes, but he has a real problem with stability and/or accuracy.

So he is getting bad input data (garbage in/garbage out), or doing the math with imprecision.

My guess is that his pulses are not being picked up correctly in the first place (garbage in). Lately, though, my guesses aren't so good...

Paul

Originally posted by Peter Nachtwey:

This isn't the main problem.

Click to expand...

OK, so now I'm curious. What is the actual symptom. Either you divined something out of Clay B's original post that I completely missed or you have seen issues related to this type of calculation before and are assuming Clay B is having those. I'm kind of curious which it is.

Originally posted by Peter Nachtwey:

Yes, if the time between pulses is greater than 655.35 seconds then the timer will overflow.

Click to expand...

Clay B is limited to much less than that. I'm pretty sure the plc he is using will do something untoward at 99.99 seconds. It's been a while for me and AD but I think it will roll over.

Keith

kamenges said:

I'm pretty sure the plc he is using will do something untoward at 99.99 seconds.

Click to expand...

BCD timers, yet another computer crime.