Downtime tracking

SimonT · Dec 30, 2010

Since this is the fourth time I have tried adding this post I will be less wordy.
Hello All! New to the site so be easy.
I was wondering if anyone has set up a Downtime tracking program with 50+ faults and logic for assigning priority based on first fault in, hierarchy based on fault type and an efficient way to package and post the data. I have done so with mixed results, need some insight. I'll share my program so you don't think I haven't tried to put in the work first. The program is for a plant wide Ethernet Comms, CLX racks with remotes and utilizing (currently) Excel spreadsheets. Any help would be appreciated. Thank You.

Longhorn · Dec 31, 2010

Hey Simon,
I have recently created my own OEE calculator for a production line and incorporated into this is a downtime logging system which logs the stop cause and the start & stop times then calculates the duration of the stop.

Top do this i built the plc code into the line plc which was an s7 300 with a cp343-1 lean card. I then created an in touch application for a front end and wrote all the data to an SQL database.

The system currently logs about 15 causes but we plan to expand this to about 30 causes.
If you are familiar with s7 then I can send you the code to determine what the stop cause is????

Lh

SimonT · Dec 31, 2010

Hello,

Thanks for the reply.
No, I am not familiar with that. All of our stuff is AB, I am familiar with all of the RSlogix code. We also have a SQL server which we talked about writing to but so far we have only used Excel. The biggest problem that I have is the accuracy of the code to track the DT effectively. I was wondering how to time only one fault at a time, like the first fault in tracks time until cleared. Then the second one tracks time. I have done this by utilizing simple ladder logic with XIO and XIC bits but it tends to get complicated. I would like to use a string and view it to see if it changes then set a timer to time the bit that goes high and MOV the value to the associated bit. At the end of the shift calculate the time and send to a server or reporting platform. I understand all of the actions needed to package and send the data to a server. I am having trouble with the code in the PLC. If you have RSLogix 5000 I can post some of the code to see what I mean.

Longhorn · Jan 1, 2011

If you have all of the stop conditions in parallel then using a one shot set a bit called e.g. New event, then when the new event is active all the stop causes are scanned at this point to see which one created the new event, then e.g. If the labeller is the cause then set the "labeller stop" bit.

Is this a production line you are monitoring?

Do you have some sort of hmi or scada system on the line?

Lh

Ned_Flanders · Jan 2, 2011

Longhorn said:
Hey Simon,
I have recently created my own OEE calculator for a production line and incorporated into this is a downtime logging system which logs the stop cause and the start & stop times then calculates the duration of the stop.

Top do this i built the plc code into the line plc which was an s7 300 with a cp343-1 lean card. I then created an in touch application for a front end and wrote all the data to an SQL database.

The system currently logs about 15 causes but we plan to expand this to about 30 causes.
If you are familiar with s7 then I can send you the code to determine what the stop cause is????

Lh

Hi, Mate. I would be interested in this! Currently I have installed some stand-alone OEE loggers/displays but as nearly all our equipment is S7, it seems daft not to use them. It might help justify spending some cash on linking all the lines to a scada system (Most only have HMIs on at the moment).

Mark

Longhorn · Jan 2, 2011

Markie, I ain't at my work pc just now but when I get a minute I will zip up the function block I created and post it along with some screen shots of the oee front end .

Later

SimonT · Jan 3, 2011

I keep getting kicked off here. It says that I am not a registered user. Why does it do that if I have aready registered?

SimonT · Jan 3, 2011

Longhorn said:
If you have all of the stop conditions in parallel then using a one shot set a bit called e.g. New event, then when the new event is active all the stop causes are scanned at this point to see which one created the new event, then e.g. If the labeller is the cause then set the "labeller stop" bit.

Is this a production line you are monitoring?

Do you have some sort of hmi or scada system on the line?

Lh

I have all of the stop conditions in series because this is a continous line. The chain at the end is the master with all of the rest on VFD's following. The fault removes the permanent or temporary FWD depending on fault type. When a fault goes high it sets a counter and timer to track occurances. At the end of the shift the the values are MOV'd to an ARRAY tag and then sent to an Excel spreadsheet.

With all of the tmers and counters, along with the logic to control which timers are accumulating value, the routine gets confusing and uses up too much memeory. It should be more simple. I have only been programming for a couple of years so everything I have learned so far has been out of a book or trial and error. I was hoping someone here could help.

Yes it is a processing line for lumber.

There are currently HMI's on several machines throughout the line. There is also a user interface that tracks overall efficency but doesn't say where the bottlenecks are. This is why I created the original Downtime tracker. That way we could concentrate on the troubled areas.

OkiePC · Jan 3, 2011

What you are doing, since there are a number of possible causes, and you intend to generate reports with it, should probably log the PLC Local Date and Time when production stops, and when production resumes, along with all active fault bits at that time.

So you get a timestamp for each occurance rather than a total. This will produce more useful results in my opinion.

For example, knowing you had 1.75 hours of downtime yesterday becuase of fault "x" is useful. Knowing that they accumulated over 28 different occurences of fault "x", some of which coincided with fault "k" and fault "t" and 85% of them happened right after shift change is very much more useful.

It won't be as easy to make use of this in excel, but it is still possible.

I would create a UDT with room for however many fault bits you have (plus some spares) and 7 DINTs for the timestamp. Then make an array of these for twice the worst case number of faults you want to store in the PLC.

Each time the line stops, and each time the line starts, increment the index of the array, and load it with a fresh copy of the wallclocktime and the states of all the fault bits.

Hope this helps,
Paul

SimonT · Jan 3, 2011

OkiePC said:
"It won't be as easy to make use of this in excel, but it is still possible."

This is where all of the heartburn began. I am not the one that is creating the report. I track occrences and duration for all of the faults. I never thought of time stamping with the wall clock, that would be useful. However, I am still not sure I could send the correct data so that the accumulated values would not compound the overall DT. The report writer is having difficulty writing the report because he thinks the data is inaccurate. This is both true and false since the faults happened simultaneously or close to it. Using the time stamp will help to separate the occurances I guess but like you said it will be difficult in Excel.

Longhorn · Jan 4, 2011

the application i wrote in intouch writes each event to a downtime table which logs even the micro-events and also keeps a running accumulation of downtime per stop cause which gets written to a seperate SQL table at midnight every day.

Attached is the front-end "OEE Dashboard" screenshot.

Ned_Flanders · Jan 4, 2011

Hi Longhorn, I used to (Occasionally) work with Krones labellers at a local brewery - I am guessing you are at a dairy? It's not at Nairn by any chance?

I see performance is your issue (Or is it just a test?) Ours is availability.

Mark

Binaural · Jan 4, 2011

Longhorn - like the downtime screen, nice and clean.

Longhorn · Jan 4, 2011

Thanks for the gd comments folks, as for the figures this was just part of a test.
I am at Arla Lockerbie m8!

Will try and dig out the s7 code for Markie!

Lh

Jack Schit · Jan 7, 2011

markie said:
Hi, Mate. I would be interested in this! Currently I have installed some stand-alone OEE loggers/displays but as nearly all our equipment is S7, it seems daft not to use them. It might help justify spending some cash on linking all the lines to a scada system (Most only have HMIs on at the moment).

Mark

Hi,

I have also recently created a line downtime tracking system for a bottling line. I have linked the individual machine PLC’s (all Siemens S7 or S5) together over Profi DP to a central PLC which calculates machine EFF & OEE and overall line EFF & OEE. This is then shown through a HMI using WinCC in the main production office. The system also collects up to 32 faults from each machine, counting number of occurrences and total time for each fault. The data is logged to excel through WinCC for the production staff to analyse.

Longhorn, I would also be interested to see your function block.

Jack

Downtime tracking

SimonT

Member

Longhorn

Member

SimonT

Member

Longhorn

Member

Ned_Flanders

Member

Longhorn

Member

SimonT

Member

SimonT

Member

OkiePC

Lifetime Supporting Member

SimonT

Member

Longhorn

Member

Ned_Flanders

Member

Binaural

Member

Longhorn

Member

Jack Schit

Member

Similar Topics