Production tempo

rQx · Dec 5, 2014

Hi!

We have a packing machine that is producing maybe 1 pack / 3sec.
We will now collect this data and show a production tempo in pack / minute
First time I do this and it's always nice to talk to someone who have maybe experienced this before. Why make same mistake twice?

I have a few ideas, the first one is to count the elapsed time between two packs and transform this value to a pack/min value. Problem with this is that maybe the value will not be stable and it is a sensible system. The product can alternate from 5packs/min to 30packs/min.

Another solution would be to each minute count number of packs and display it. This would be a value of "packs the last minute". This value would update every minute, but it wouldn't be the actuall pack/min I'm showing on the screen since it's the latest minute I'm counting. But it would be stable.

Another solution is to increase the 2nd alternative to update like every 10second.

How would you do it? This should be showed to the people that is standing and control the machine aswell as be logged and displayed on a graph with a time axis.

Thanks
/Tim

Bering C Sparky · Dec 5, 2014

If you are using RSLogix5000, then look at post #6 of this thread.
Another forum member gave me this yesterday for counting Pieces per MIn and it can be imported directly into your Logix5000 program.
My process was counting a bit faster than yours 180pcs per min max,
but this should work for you also.

http://www.plctalk.net/qanda/showthread.php?t=91853

BCS

rQx · Dec 5, 2014

Forgot so say that I use s7-1200 for this. Don't know if I can see the program, and write in s7-1200. I have only program for ML1400 and I think it is called RSlogix Developer maybe?

Bering C Sparky · Dec 5, 2014

No that will not work, attached is a GIF in a ZIP file.
Maybe you can figure out the same instructions for Siemens.

Good Luck
BCS

RonJohn · Dec 5, 2014

rQx, I suppose it all depends on what your log requirements are. Your first and second solutions could both work. I don't know if my terms are correct, but your first solution is basically an instantaneous rate while your second solution looks at a slightly larger time frame. If you were able to get away with filtering/averaging your rate the stability issue you bring up could be improved.

I know that in S7-1200, you can use a CALCULATE instruction to program a simple filter. I've attached a JPG to show what I've done. I broke it up into two networks for simplicity. You can execute the filter logic every time your value updates using the same one shot.

X is your input, Y is the filtered output.
Tau is your filter constant. 1 = no filter. Filtering increases as Tau => 0

Looking at the network comment, Y1 is the new output (calculated this scan) and Y0 is the previous scan's output.

goghie · Dec 5, 2014

You can measure time between circles and divide 60 with measured value.

rQx · Dec 6, 2014

Bering C Sparky said:
No that will not work, attached is a GIF in a ZIP file.
Maybe you can figure out the same instructions for Siemens.

Good Luck
BCS

Thanks alot, I can figure that out in Siemens for sure

RonJohn said:
rQx, I suppose it all depends on what your log requirements are. Your first and second solutions could both work. I don't know if my terms are correct, but your first solution is basically an instantaneous rate while your second solution looks at a slightly larger time frame. If you were able to get away with filtering/averaging your rate the stability issue you bring up could be improved.

I know that in S7-1200, you can use a CALCULATE instruction to program a simple filter. I've attached a JPG to show what I've done. I broke it up into two networks for simplicity. You can execute the filter logic every time your value updates using the same one shot.

X is your input, Y is the filtered output.
Tau is your filter constant. 1 = no filter. Filtering increases as Tau => 0

Looking at the network comment, Y1 is the new output (calculated this scan) and Y0 is the previous scan's output.

Hm, I tried to understand those two ladders but I don't know if it's saturday but I have a hard time

goghie said:
You can measure time between circles and divide 60 with measured value.

Yes, but then I would have a very unstable value. Since the cycles can vary very mush. 2 second one cycle and 10seconds next cycle. Resulting in 30p/min and 6p/min.

Lancie1 · Dec 6, 2014

It seems that you want to find an average count of Packs Per Minute, averaged over a time that is not too short or too long.

Counting packs for 10 seconds then multiplying by 6 will give you a reasonable average of Packs/Min. If that jumps around too much, then step up to 12 seconds and a multiplier of 5.

Possible Averaging Times

Seconds | Multiplier

      6 | 10    

      8 | 7.5   

     10 | 6     

     12 | 5     

     15 | 4     

     20 | 3     

     30 | 2     

     60 | 1

osmanmom · Dec 6, 2014

omron method

rQx · Dec 7, 2014

Lancie1 said:
It seems that you want to find an average count of Packs Per Minute, averaged over a time that is not too short or too long.

Counting packs for 10 seconds then multiplying by 6 will give you a reasonable average of Packs/Min. If that jumps around too much, then step up to 12 seconds and a multiplier of 5.

Possible Averaging Times
Seconds | Multiplier
6 | 10
8 | 7.5
10 | 6
12 | 5
15 | 4
20 | 3
30 | 2
60 | 1

Yes, exactly! Good suggestions, thanks alot!

osmanmom said:
omron method

Thanks alot, I'll try to understand it

cwal61 · Dec 7, 2014

The Time pulse between packets will show real time PPM and yes it will be erractic if your machine does not run constant volume. That is why it would be referred to as Real Time. If you want a trend display then your last minute method would be the way to go. Personally, I would do both on my display. Current Speed and PPM. Also, for my trending numbers I would not multiply an interval as this would only show the interval at which the trend was captured at the minute pulse. A Simple counter and capture of Accumalation and Reset counter would do. If Trend Chart is going to show Multiple Time Captures then Set up a Count and Trend for each Time Shown.

One More thing to remember is the Real time Pulse needs to be zero if machine is off or your cycle time is greater than 1 minute. Or create a tach time to compare to real time and display which ever one is less. Do this by creating a one second pulse. Use that pulse to do the same thing your Real Time is doing. Dividing time between pulses into 1 minute. Every second your checking to see if the Real time pulse has been reset. If your chugging along at 30PPM you are resetting your pulse every two seconds. If 3 seconds goes by and no pulse then your tach pulse would show 20PPM and that would be displayed. And it would continue to count down every second.

RonJohn · Dec 8, 2014

rQx said:
Hm, I tried to understand those two ladders but I don't know if it's saturday but I have a hard time

Sorry for the confusion. I posted rather quickly as I was heading out the door for the weekend.

Those two ladder rungs work as a filtering algorithm that can be used to smooth out your "time between packs" value that's bouncing around so much.

The logic executes the function Y_n = Y_(n-1) + Tau * (X - Y_(n-1))

The best way to understand how this works is to set up this logic in a PLC and run a test with three real tags: Inputs Tau & X and Output Y. Once online, open up a watch table and change the value of X and observe what happens to Y.

Notice that if Tau = 1, the function reduces to Y = X or no filtering.
If 0 < Tau < 1, then the value of Y equals a fraction of X along with a fraction of the previous value of Y. Each time the filter logic updates, Y will be a value closer to X than is was the previous scan. Eventually they will match.

The smaller the value of Tau, the heavier the filtering and the less bounce you will see in the value of Y. Of course the smaller value of Tau, the longer it will take for Y to equal X.

This type filter is used in many applications. I use it often to filter speed feedback from drives as the instantaneous speed from a motor may be bouncing all over the place, but the filtered value is much more useful for display purposes.

The other methods posted are good and useful too. Using a filter algorithm will more closely represent a running average rather than the total from the most recent time span. I hope this helps.
RonJohn

PS: Good explanation and idea cwal61.

rQx · Dec 8, 2014

RonJohn said:
Sorry for the confusion. I posted rather quickly as I was heading out the door for the weekend.

Those two ladder rungs work as a filtering algorithm that can be used to smooth out your "time between packs" value that's bouncing around so much.

The logic executes the function Y_n = Y_(n-1) + Tau * (X - Y_(n-1))

The best way to understand how this works is to set up this logic in a PLC and run a test with three real tags: Inputs Tau & X and Output Y. Once online, open up a watch table and change the value of X and observe what happens to Y.

Notice that if Tau = 1, the function reduces to Y = X or no filtering.
If 0 < Tau < 1, then the value of Y equals a fraction of X along with a fraction of the previous value of Y. Each time the filter logic updates, Y will be a value closer to X than is was the previous scan. Eventually they will match.

The smaller the value of Tau, the heavier the filtering and the less bounce you will see in the value of Y. Of course the smaller value of Tau, the longer it will take for Y to equal X.

This type filter is used in many applications. I use it often to filter speed feedback from drives as the instantaneous speed from a motor may be bouncing all over the place, but the filtered value is much more useful for display purposes.

The other methods posted are good and useful too. Using a filter algorithm will more closely represent a running average rather than the total from the most recent time span. I hope this helps.
RonJohn

PS: Good explanation and idea cwal61.

Thanks alot for a good explination! I think it's the language barrier between us that confused me, I though I should have values above 1 for Tau. It makes sense now when I see that it should be 0.5, 0,2 etc etc

Thank you all for your inputs. I have an idea now of how I'm going to do this. I will post my solution when I've done it

A mash-up between that we have discussed.

Production tempo

rQx

Lifetime Supporting Member

Bering C Sparky

Lifetime Supporting Member

rQx

Lifetime Supporting Member

Bering C Sparky

Lifetime Supporting Member

RonJohn

Lifetime Supporting Member

goghie

Lifetime Supporting Member

rQx

Lifetime Supporting Member

Lancie1

Lifetime Supporting Member

osmanmom

Member

rQx

Lifetime Supporting Member

cwal61

Member

RonJohn

Lifetime Supporting Member

rQx

Lifetime Supporting Member

Similar Topics