AB Logix 500 & 5000

rayc · Sep 4, 2006

Hello everyone,

My boss just threw me a project on data acquisition from our PLC, and being a recent graduate with no experience in PLC programming, I don't have a glue on how to do it. We have a couple of in-house PLC programmer but little they know about other software e.g. VB, C++ etc. The purpose of this project is to capture downtime instances in our production line and present it in maybe excel. I understand that there are many SCADA system out there but our management needs "proof" that a 20k investment will help to increase our OEE. Can someone please provide a start off point for my research? Can I write a C program to perform data acquisition? Please pardon my ignorance and many thanks in advance.

Ray

consys · Sep 4, 2006

I assume that you already have Allen Bradley PLC's and programmers on site. If so then you may already be using RSLinx. Check with your Rockwell supplier, certain versions of RSLinx have OPC server ability. If you rs does (or you can upgrade to one that does) then you should be able to access your plc data with any package that can act as OPC client (VB, Excel etc.)

Clay B. · Sep 4, 2006

First question: How many PLC's and what types.

Second question: What kind of data are you trying to get.

Third Question: How does you boss think this will improve production thus justify cost

There are alot of different systmes out there that have "canned" features that monitor all kinds of data. It really depends on the kind of data you want as to what system you go after.

For a place to start and this is making an assumption off of your Thread title I would start on Rockwell's home page.

PLCRookie · Sep 4, 2006

Downtime??

Just my opinion (mostly based on experience), but the most difficult part of what you a embarking on is not the recording of the downtime, but actually correcting the cause of the downtime. As for gathering the data, you will find that a piece of paper and a pen will work just as well as a computer program. I will bet dollars to doughnuts that all you need to do is ask some of your experienced operators to log the downtimes that are occurring, and offer their suggestions as to some possible solutions. Then ask "why" 5 times. Make sure not to treat the symptom, but the root cause of the problem. Software will not do this for you.
Most people fail at this point.

Clay B. · Sep 4, 2006

PLCRookie said:
Just my opinion (mostly based on experience), but the most difficult part of what you a embarking on is not the recording of the downtime, but actually correcting the cause of the downtime. As for gathering the data, you will find that a piece of paper and a pen will work just as well as a computer program. I will bet dollars to doughnuts that all you need to do is ask some of your experienced operators to log the downtimes that are occurring, and offer their suggestions as to some possible solutions. Then ask "why" 5 times. Make sure not to treat the symptom, but the root cause of the problem. Software will not do this for you.
Most people fail at this point.

Good answer: The way I have been taught when it comes to production monitoring is that it will give you the "what" not the "why". If you want the why you havew to get on the floor. But from Rayc's post I am guessing this is a dog and pony for his boss so wheither or not it really matters is inmaterial. HWat matters is that Rayc comes up witha system his boss can sell to his managers.

One thing I did not ask in my earlier psot is have you thought about expandablity. Cause when you give this new toy to management you will get requests for all kinds of data not being asked for now. Remeber what you are doing is putting a little window into the production floor on there desk. They always want a bigger window when you do that.

TimWilborne · Sep 4, 2006

PLCRookie said:
As for gathering the data, you will find that a piece of paper and a pen will work just as well as a computer program.

I disagree with this statement.

For one you can't stare at a machine for 24 hours a day 7 days a week with a stopwatch breaking down every process. A good data logging system can

Operators don't run their machines the same when someone is watching them. Some run faster, some run slower, some do anal steps they normally skip to gain a few more parts.

Time of day is a big factor in operator performance. For instance we have two machines that are identical in every aspect. Operator 1 starts out the day running hard and operator 2 can't get it together. By morning break operator 1 has almost twice the parts as operator 2. By lunch operator 1 and 2 are usually tied for parts. By quiting time operator 2 has 30 to 40 % more parts on average.

Mondays and Fridays are always bad days.

Morning to evening sequence times differ because things such as hydraulic oil temperature change through the day

The pace of equipment up and downstream affects the output of the machine

I can go on and on. I feel it is best to do the data logging, examine the data after you have enough data to have a good control specimen, then go ask the operator questions. And definitely tell the operator about the monitoring. My operators have gotten really involved in it. They can view much of the data logging on the touchscreens and adjust the machine to try to get the most out of them too.

And if this is just a dog and pony show for management, forget about doing any of this. Go on the internet and get the lottery numbers for the last month and put them down on your report. They will have more relevance

lendyck · Sep 4, 2006

Probably the simplest method to grab data is to use VB scripting in Excel. Even though the technology is old, I've never had any issues using DDE to read or write data to/from AB PLCs. Of course, RSLinx (Enterprise?) is needed...someone correct me if I'm wrong!

Probably the harder part though, will be finding what data you need to get. Having a thorough understanding of the machine would be essential here...plus having some help from the PLC programmers wouldn't hurt.

If you need examples of VB scripting in Excel, I can give you some.

monkeyhead · Sep 4, 2006

Another solution is to use Cimquest's Active X module to read data in from the PLC.

http://www.ingeardrivers.com/allen_bradley/allen_bradley.htm

You could have your PLC programmers setup the PLC collect the data and store it in an agreed upon area in the PLC memory. Then you read the data in using the activeX module and use your PC programming skills to output it however you need.

I'm personally a fan of .csv (comma seperated variable) files because they are plaint text (easy to work with) and can be imported or opened in a variety of programs including Excel.

rayc · Sep 5, 2006

consys said:
I assume that you already have Allen Bradley PLC's and programmers on site. If so then you may already be using RSLinx. Check with your Rockwell supplier, certain versions of RSLinx have OPC server ability. If you rs does (or you can upgrade to one that does) then you should be able to access your plc data with any package that can act as OPC client (VB, Excel etc.)

Yes we have a combination of logix 500 & 5000 onsite.

I just found out from a RSLinx trainer software that our RSLinx Lite doesn't support DDE/OPC, RSLinx Gateway, OEM and Professional are.

rayc · Sep 5, 2006

Clay B. said:
First question: How many PLC's and what types.

Second question: What kind of data are you trying to get.

Third Question: How does you boss think this will improve production thus justify cost

There are alot of different systmes out there that have "canned" features that monitor all kinds of data. It really depends on the kind of data you want as to what system you go after.

For a place to start and this is making an assumption off of your Thread title I would start on Rockwell's home page.

1. 20 PLC combination of 500 & 5000.

2. For a start, we will try to capture information from sensors, e.g. starting and stopping of machine.

3. Well this "software" we are going to develop will NOT improve production but allow us to identify missing downtime minutes and once all the books are correct, we then hope to fix problems on the line, hence improve OEE.

TimWilborne · Sep 5, 2006

There is also a "Single Node" version if you are only going to work with one processor but I would recommend this option if you work at a facility with numerous PLCs

TimWilborne · Sep 5, 2006

Ok I see you posted that you have 20. I would go with OEM

Your RsLinx Lite will have the documentation for doing this. Goto help and on the Index tab type in DDE. There as some good example there

rayc · Sep 5, 2006

PLCRookie said:
Just my opinion (mostly based on experience), but the most difficult part of what you a embarking on is not the recording of the downtime, but actually correcting the cause of the downtime. As for gathering the data, you will find that a piece of paper and a pen will work just as well as a computer program. I will bet dollars to doughnuts that all you need to do is ask some of your experienced operators to log the downtimes that are occurring, and offer their suggestions as to some possible solutions. Then ask "why" 5 times. Make sure not to treat the symptom, but the root cause of the problem. Software will not do this for you.
Most people fail at this point.

Correct, knowing the figures will not solve any problem. Our major problem is missing downtime hours. We have 6 different machines on a particular production line that works 16 hrs, 5 days a week. And when we compared our "ideal" throughput with the actually throughput, we can have up to 1000 mins not accounted for. From my wee experience in production factory I learned to know that it's all those small and frequent stoppages that kill us. For example, a particular machine stops 5 times in a hour for 10 seconds, that will easily give over 200 mins unaccounted for. This is what we need to know, as least for now.

Well after we can justify that human errors do exist, then we can look into the 5 whys you mentioned. You are right, software won't soft my problem.

rayc · Sep 5, 2006

Clay B. said:
One thing I did not ask in my earlier psot is have you thought about expandablity. Cause when you give this new toy to management you will get requests for all kinds of data not being asked for now. Remeber what you are doing is putting a little window into the production floor on there desk. They always want a bigger window when you do that.

Bloody oath!

rayc · Sep 5, 2006

TWControls said:
I disagree with this statement.

For one you can't stare at a machine for 24 hours a day 7 days a week with a stopwatch breaking down every process. A good data logging system can

Operators don't run their machines the same when someone is watching them. Some run faster, some run slower, some do anal steps they normally skip to gain a few more parts.

Time of day is a big factor in operator performance. For instance we have two machines that are identical in every aspect. Operator 1 starts out the day running hard and operator 2 can't get it together. By morning break operator 1 has almost twice the parts as operator 2. By lunch operator 1 and 2 are usually tied for parts. By quiting time operator 2 has 30 to 40 % more parts on average.

Mondays and Fridays are always bad days.

Morning to evening sequence times differ because things such as hydraulic oil temperature change through the day

The pace of equipment up and downstream affects the output of the machine

I can go on and on. I feel it is best to do the data logging, examine the data after you have enough data to have a good control specimen, then go ask the operator questions. And definitely tell the operator about the monitoring. My operators have gotten really involved in it. They can view much of the data logging on the touchscreens and adjust the machine to try to get the most out of them too.

And if this is just a dog and pony show for management, forget about doing any of this. Go on the internet and get the lottery numbers for the last month and put them down on your report. They will have more relevance

Anal steps!!!!!! lol

AB Logix 500 & 5000

rayc

Member

consys

Member

Clay B.

Lifetime Supporting Member

PLCRookie

Member

Clay B.

Lifetime Supporting Member

TimWilborne

Lifetime Supporting Member

lendyck

Member

monkeyhead

Member

rayc

Member

rayc

Member

TimWilborne

Lifetime Supporting Member

TimWilborne

Lifetime Supporting Member

rayc

Member

rayc

Member

rayc

Member

Similar Topics