Parts Per Minute calculation

Peter Nachtwey said:
BCD timers, yet another computer crime.
Click to expand...

I have still not had a chance to test the cycle counter againg. The mechanical engineer still has issues he needs to fix so I will not get the machine again until next week from the looks of things. But since everyone has shown such a great intrest,which I do appriciate, I will try and give more details from my earlier attempts.

For non AD PLC this may not make much sense. This may not be the exact code we were using. I doing this from memory right now. I blew away the code we started having problems with so I could work on something else.
Anyway here goes

Rung 1

STR T1 (one shot rising)
MOV TA2 to V2000

Rung 2

STR SP1 (always on)
T1 (oneshot rising)
TMRAF T2 K6000

Rung 3

STR
LD K6000
DIV V2000
OUT V3000


Basically what I did is say that everytime T1 came on we moved the data from the timer T2 to a register. We reset timer T2. We then divided 6000 by our moved data and put it in another register. Seemed simple enough. Have used the same setup many times on AB PLC's with no problem. We used the T1 timer as the trigger so that if we bounced at the prox we would not create a false cycle time. Backlash on this machine is pitiful, hince the mech engineer needing to do some more work.

But here things get kinda odd. What would happen is we would get answers that were 2 digits long and then some answers that were 3 digits long and others where 4 digits long.

I do not have the exact numbers I was seeing in front of me. I focused on the fact the number of digits in the register was changing. I know that with AB PLCs the frational part causes a round up if you are using integers so if your answer was 15.5 your integer would read 16. If your answer was 15.3 your integer would read 16. Not sure how AD handles this.

My thought is that there is something screwy (technical term) with the BCD and the way this PLC does math. I am just not seeing it.

This is a rotatory filling machine. The table is driven by a motor gearbox that is chained to the shaft of the table A VFD controls motor speed and a Clutch Brake is used to stop. So the motor speed is constant and we flip the Clutch Brake to stop and start the table.

FYI... I did not pick this drive train, the mech engineer did, hince he has some work to do.

The reason I posted my original question the way I did was to make sure my concept was correct. I figured the odds where pretty good someone else had been down this road and has seen what I did.

Anyway there is what I have right now, it will be sometime next week before I can test again.
 
I had made an error in my previous program posting. The timer chould have been in a rong on its own. here is the corrected program.

PLC 06
// Rung 1
// Address 0
STRPD X0
OUT C0
// Rung 2
// Address 2
STR C0
AND TA0 K1
LD K6000
DIV TA0
OUT V2000
RST T0
// Rung 3
// Address 9
STR SP1
TMRF T0 K6000
// Rung 4
// Address 13
END
// Rung 5
// Address 14
NOP

#BEGIN ELEMENT_DOC
"X0","Input","",""
"C0","Input One Shot","",""
"T0","Space Time","",""
"TA0","Accum Time","",""
"V2000","Rate PPM","",""
#END
 
Clay B., keep in mind that if you are going to use an accumulating timer (TMRAF) you need to babysit resetting of the accumulated value yourself.

Also, rung 3 doesn't take advantage of the extra rangy you have available since you are only loading the lower 8 digits of the BCD accumulated value. You might want to consider:

Rung 1
STR T1 (one shot rising)
LDD TA2
OUTD V2000


Rung 3
STR
LDD K6000
DIVD V2000
OUT V3000


I don't think you need to worry about moving the timer accumulated around but it won't hurt you either.

Keith
 
Timer abuse

Abuse 1. Timers will only tell you that at least so much time in scan times units have gone by. Timers are NOT to be used for measuring the time between the evens. You have know idea when the rising edge for T1 occured and therefore really don't know the interval the pulses.

Abuse 2, you admit to reseting the timer. You shouldn't reset the timer but it doesn't make much difference because of abuse 1. How many time period have gone by since the input going high and the time you reset the the timer. All that time is lost.

There is only one proper way to do this kind of application. First you need a FREE RUNNING CLOCK and the ability to latch the clock data when the input turns on. This probably requires a special high speed counter card. The other possibility is that a faster interrupt also the programmer to save away the free running clock but the response must be very fast. The free running clock should NOT BE BCD. BCD MAKES CALCULATIONS HARDER. The previous latched value is subtracted from the current latched value to calculate the interval between events. I prefer the hardware solution but responding to a interrupt on input may be OK. Note, the free running clock is NEVER RESET. This way no time is lost. Don't give me some lame excuse like the AD doesn't have a free running clock.

Here is a thread that basically covers the same topic
http://www.plctalk.net/qanda/showthread.php?t=15890&page=2&pp=15&highlight=timer

I can easily setup a free running clock and latch on just about any small 8 bit micro controller. If the micro controller can do it the PLC should be able to do it. If not then buy the hardware card that can or buy a better PLC.

TIMERS ARE NOT FOR MEASURING INTERVALS!!!!
 
Peter Nachtwey said:
Abuse 1. Timers will only tell you that at least so much time in scan times units have gone by. Timers are NOT to be used for measuring the time between the evens. You have know idea when the rising edge for T1 occured and therefore really don't know the interval the pulses.

Abuse 2, you admit to reseting the timer. You shouldn't reset the timer but it doesn't make much difference because of abuse 1. How many time period have gone by since the input going high and the time you reset the the timer. All that time is lost.

There is only one proper way to do this kind of application. First you need a FREE RUNNING CLOCK and the ability to latch the clock data when the input turns on. This probably requires a special high speed counter card. The other possibility is that a faster interrupt also the programmer to save away the free running clock but the response must be very fast. The free running clock should NOT BE BCD. BCD MAKES CALCULATIONS HARDER. The previous latched value is subtracted from the current latched value to calculate the interval between events. I prefer the hardware solution but responding to a interrupt on input may be OK. Note, the free running clock is NEVER RESET. This way no time is lost. Don't give me some lame excuse like the AD doesn't have a free running clock.

Here is a thread that basically covers the same topic
http://www.plctalk.net/qanda/showthread.php?t=15890&page=2&pp=15&highlight=timer

I can easily setup a free running clock and latch on just about any small 8 bit micro controller. If the micro controller can do it the PLC should be able to do it. If not then buy the hardware card that can or buy a better PLC.

TIMERS ARE NOT FOR MEASURING INTERVALS!!!!
Click to expand...


Ok I read the thread you posted and I think I see your point. But to make sure I am going to put it in my own words and see if I get it.


Use a Free Running Clock. Do not ever stop the clock. When you see a cycle event take the value of the clock accumlator. Subtract from that value your previous sample. The difference between the two is your cycle time in whatever base you set you clock at. In my example I use a base of .01 seconds. So I then take my cycle time and divide it into 6000 to get my parts per minute.

Ok I think the light came on and I can get my bloomers out of the wind. Still not sure if that explains everything I saw but I believe I see your point.

My plans now:

Ok hardware change is out. This boat anchor of a machine is so far out of budget now changing the PLC is not going to happen. Know that is going to make you rant Peter but buiness is buiness, you can not build a cadillac on a pinto budget, all you can do is polish the Pinto.

So here is my half brained idea. Have a clock that runs "almost" continuous. What mean by this is the clock is still running but once the accumlator gets to 9999 thats it.

So I do as you said Peter and let it run and take my values and do my calculations as I get my part pulses. when I get to 9999 I reset my clock on the next part pulse. Since I reset my values I set a condition that prevents me from calculating that cycle. On the next part pulse I start calculating. What that means is if I use a .01 preset I lose one cycle time every 99.99 seconds. Pretty sure I could live with that on this machine. Can see where that would be an issue on other machines. As for filtering I think I will see if I really need it.



BCD timers, yet another computer crime.
Click to expand...

I can not believe you said that Peter I figured you wrote BCD.


Sorry couldn;t resist. Seriously though thanks Peter, once again I learned something new.

Also, rung 3 doesn't take advantage of the extra rangy you have available since you are only loading the lower 8 digits of the BCD accumulated value. You might want to consider:
Click to expand...

I think this is part of my problem also and explains the funny digits. Can see some serious tests to figure out what crazy things Peter's BCD causes to my math.


Once again thanks for everyone's help and as soon as I get the machine back I am going to test this. If I get impaticent I will setup some type of simulator and go at it again.
 
Clay B. said:
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.
Click to expand...

Clay,

This sounds like the verbage that comes out of the production manager's office where I work. I do find it hard to believe that an even 60 parts a minute is the magic number. I would believe 59.885 parts per minute or 63.47 PPM or some other fractional number.
Peter Nachtwey said:
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.
Click to expand...
I know what I'm about to suggest is not what Peter had in mind, but here it goes anyway.

Set up a timer (TMRF) with .01 second resolution. Set the preset on this timer at 1 second. If another part comes out before the timer times out, sound a really anoying horn that has a duration of 1 second. As you can see from Peter's numbers .01 resolution will get you close enough for the production managers I have worked with. I belive this setup would be more accurate than any manager's stopwatch.
 
Great sounding advice Peter - if the application called for such precision. The one proposed by the original poster didn't have that ring to it. I stand by my quick and easy method. At the rate he mentioned the difference in precision between the easy/quick method and the involved - drawn out method would probably be less than 1%. Even at 60 a minute my typical scan time (less than 10 ms) yields a precision of 1/100 of a case per minute. Close enough for me.
 
Originally posted by Clay B.:

Can see some serious tests to figure out what crazy things Peter's BCD causes to my math.
Click to expand...

There isn't anything crazy with the math. The firmware of the processor was designed to operate with BCD data entries. I'm reasonably sure that the plc converts the numbers to binary before operating on them anyway. So don't focus on the data type; focus on what the numbers are doing.


Originally posted by Clay B.:

What mean by this is the clock is still running but once the accumlator gets to 9999 thats it.
Click to expand...

Are you 100% sure of this? Are you sure the number doesn't wrap around? I couldn't find any information on the AD website that discusses this either way.

Originally posted by Peter Nachtwey:

TIMERS ARE NOT FOR MEASURING INTERVALS!!!!
Click to expand...

Agreed, but Bernie rirght on this one. Unless he tells us different, when Clay B. says that the parts per minute number is changing by 2 and three digits he isn't talking about the right side of the decimal point. He's talking about the left side of the decimal point. Furthermore, he stated that the issue occurs when he is at very slow speeds. At slow speeds the difference due to inaccurate time measurement become a smaller percentage of total time and makes less difference in the total number.

Keith
 
bernie_carlton said:
Great sounding advice Peter - if the application called for such precision.
Click to expand...
Why pollute the forum with bad technique so this question will occur over and over and over again? I must be exact because every once in a while a customer really cares about the precision. I am making a product. I have no idea how demanding my customers will so I assume they are all as exacting as I am.

The one proposed by the original poster didn't have that ring to it. I stand by my quick and easy method.
Click to expand...
OK if it works for you. I don't have the luxury. Perhaps the next person reading this needs the best way.

At the rate he mentioned the difference in precision between the easy/quick method and the involved - drawn out method would probably be less than 1%.
Click to expand...
What about the time lost when the timer is reset? 1% of 1 second is 10 milliseconds which is the resolution of the timer. The error will be at least 1% due to timer resolution and time lost. The true production rate will be under reported by at least 1%. Clay B may be exceeding his 60 RPM rate by a few percent and not know it. I don't know how important that is.

What I find is interesting is people think in terms of the tools they have. If PLCs didn't have timer and counter blocks then these blocks couldn't be abused.

Timers aren't really needed. All one needs is ONE free running clock. It amazes me that many PLCs don't have a free running clock. If you look at the hardware of just about any micro-controller you will see that it is easy to set up a free running clock so why hide it from the programmer? This is insane. Most hardware free running clocks will run at some rate slower than the processor clock frequency but this still means that multi mega hertz processors can still have sub microsecond clocks. Obviously that brings problem with overflow. It is the 2000s! 32 bit free running at 1 KHz clocks should be common place. A 32 bit free running at 1 KHz clock will over flow in 49+ days and with proper techniques it is not a problem.


So how does one just a a free running timer?
1. On the rising edge of the input store away the current value of the free running clock. This should be done in hardware. This means the current value should be latched. A more reasonable way would be to generate an interrupt as a response to the input. The current value of the free running clock is then saved away.
2. When checking the elapsed time the current value of the free running clock is read and the previously save value is subtracted from the current value and the difference is then compared to any timeout value.

IT IS EXTREMELY IMPORTANT THAT THE MATH IS DONE LIKE THIS.
Code: 
If (CurrentValue-InitialValue) >= TimeOut then
 
/* if this is cyclic then one must adjust the InitialValue */
	InitialValue:=InitialValue+TimeOut;
endif

Note this does not work!!! There will be over flow problems that cause the comparison to yield the wrong results.

Code: 
If CurrentValue >= TimeOut+InitialValue then
 
/* if this is cyclic then one must adjust the InitialValue */
	InitialValue:=InitialValue+TimeOut;
endif
 
Originally posted by Peter Nachtwey:

Why pollute the forum with bad technique so this question will occur over and over and over again?
Click to expand...

While that has some validity, I don't think the failure analysis explains the original issue. You remember the original issue? You know, the one way back in post #1? That part where he says he's in good shape at machine speed but it all goes to Hades at really slow speed?

While everything you say is true, Peter, it is it's own form of forum pollution if the solution doesn't fit into the scope of the problem. It's like explaining the importance of properly honed cylinder walls to a guy with a broken valve spring. Sure it's important. It's even related. But it doesn't address the problem.

Keith
 
Well here are the possiblities

1. Bad technique. I could see that that wrong technique was used. Good technique always works given good input. See 4 below.
2. Timer Over flow. That would be 99.99 between inputs. Like I said above it easier to just say the speed is 0 when the timer overflow. After all the speed will not be exceeding the 60 RPM that seems to be critical.
3. Mixing data types and operators. Is is possible to do a BCD divide when the dividend is an integer? I expected Bernie to catch that one. Does AD do an automatic type conversion like Rockwell?
4. Multiple inputs instead of just one while going slow. Some how the input would have to drop out and come back on again causing two rising edge close together. Unlikely but possible.
 
I agree with Peter to an extent; there is no better way (or easier in my opinion) of accurately timing intervals than using a free running clock and interrupts.

The problem I can see is what does the measurement mean? Parts per minute, updated when each part is produced, may be a meaningless figure especially if the intervals between successive parts are not similar, the number will jump around each time a new part is produced. The question to be answered is what is the reading to be used for? An averaged figure over, say, 5 minutes may be more useful to production than the instantaneous rate, allowing any trends to be more easily observed.
 
I'm going for Peter's #4. I had this exact problem on a machine being fed a pulsse from a downstream machine. At higher rates the time between the two pulse which were actually coming in were masked by the filtering of the input. At slower speeds they caused havoc. When I finally realised (after much head pounding) what was going on a simple minimum time requirement fixed the situation. I didn't have access to the source of the signal so I couldn't make it right on that end.
 
I'm leaning toward #2 but I don't have an AD plc in front of me so I can't test what it does when it reaches it's limit. Let me amend that. If he really is using a TMRAF and only using the low word I DO know what will happen when it reaches 9999. With a TMRF I'm not sure.

The AD plcs don't perform automatic type conversion. In a twisted way I kind of like that. However, most items are BCD unless otherwise converted, including constant entry. I think the analog stuff comes in binary but I don't remember.

Keith
 
Could Not Wait for the machine.

Ok I set up a simple (well what I would call a simple) test. This is going to be long winded so get you a drink and get comfortable before you start thru this.

First the componets I used for my test.
1/4 HP 90 VDC Motor
K&M Drive for motor with a 10 k pot for speed control
(Fancy huh)

Automation Direct DL260 PLC with a standard 24VDC 16 bit input card. I used this because I did not have a DL06 handy. Both PLC's are kissin cousins so I do not think it will matter.

A non contact RPM digital rpm guage as a control reference.


I mouted the motor in a steal plate and attached a flag to a pulley and put this on the motor shaft. Next I mounted a prox to the steel plate that would trigger once and only once off the flag. I confirmed this by running and counting revolutions then checking the PLC to see how many pulses it couted. After several of these tests at various speeds from 14 to 70 RPMs no ghost pulses appeared.

Now I started to build my code.

My Code:

PLC 260
// Rung 1
// Address 0
STRN T0
TMRF T0 K9999
// Rung 2
// Address 4
STRPD X0
AND TA0 K200
ANDN TA0 K9900
MOVEW V2000 V2010
// Rung 3
// Address 23
STRPD X0
AND TA0 K200
ANDN TA0 K9900
MOVEW TA0 V2000
// Rung 4
// Address 42
STRPD X0
AND TA0 K200
ANDN TA0 K9900
MATHBCD V2020 "V2000 - V2010"
// Rung 5
// Address 62
STRPD X0
AND TA0 K200
ANDN TA0 K9900
MATHBCD V3000 "K6000 / V2020"
// Rung 6
// Address 86
STR X0
OUT Y20
// Rung 7
// Address 88
END
// Rung 8
// Address 89
NOP


My results: The RPM value in adress V3000 matched my RPM guage with a variance of +2 at 100 RPMs to less than +1 at 15 RPM. I ran the motor slower but it would not run steady below 15 RPM's.

Yes I could have adjusted the IXR gain on the drive and smoothed it out but that was not what I was looking for.

What I was looking for was to see extra digits in my RPm register. I never saw any.

I am still not sure of the cause of my orginal problem and while I have my test rig set up I may see if I can recreate it. As you can see from my code I make no data conversions, so all data is in BCD. Also note that I only moved a single word and not 2 words. as I watched this count up it went to 9999 then stoped. That is why I have the done bit resetting the clock. By my calculations I can lose 3 pulse events when I restart my clock. That number depends on rate of speed. I can probably get that down to 2 but I want to test more for a run away condition (cycle goes over 70 Parts Per Minute). The 60 Parts Per Minute comes from the job scope, the customer is looking for this speed as a minum and 70 comes from the fact that the equipment before and after the filler has issues with that speed.

Next week when I get the actual machine back I am going to try this code and see what happens.

Experments left to try:

Setup with a timer for a trigger and see what effects this has.

See how high/low I can get my check values (MIN/MAX to allow for speed check)

Run code as close to what I had last week and see what happens.

Figure out how this PLC rounds the remainders from math, so far it appears to go up on everything, just would like to confirm this.

Anyway thats what I have so far.
 

Similar Topics

K
calculating parts per minute using S7 300 and a positioning cam
Hi All, Could anyone give me some pointers of how to calculate the parts per min, on a simple semi auto machine, using S7 300 PLC and a...
Replies
5
Views
6,575
PLucas
PLucas
J
Parts per Minute Display
I have one customer that i programmed a parts per minute display. I used without much thought on my part the "number of parts per time period"...
Replies
5
Views
6,798
Bob O
B
P
Parts Per Min /Rolling Average
Does anyone have any logic for Allen Bradley for parts per minute, and rolling averages. Im trying to write logic for uptime / downtime /...
Replies
6
Views
5,335
parky
P
M
Parts per hour display
What is the easiest way of programming a omron plc to calculate parts per hour :D .The value will be displayed on seven segment displays
Replies
14
Views
5,251
Bitmore
B
P
Detecting small cracks in stamped metal parts
I am looking at an application where I will need to detect small hairline cracks in stamped metal parts. The sensing will need to be done in the...
Replies
10
Views
1,109
LadderLogic
LadderLogic
Back
Top Bottom