Factory process monitoring & control

I am trying to help out a friend (while holding onto my day job). His employer is suffering huge losses due to scrap, and mis-co-ordination due to the size and complexity of its manufacturing process. He thinks I can design him a custom system from scratch, but his problem is so general and ubiquitous that I'm sure it's been solved many times in the past. I'm trying to save him the expense that engineerng hours cost by locating as much of the system as possible in a pre-manufactured form, and minimum price.

When an order comes in for a specific lot size of a specific final good, the facility starts with raw material, which must be cut, machined, polished, and drilled to tight tolerances at multiple workstations, each feeding the next. A lot starts with a certain amount of overage, to allow for scrap along the way, which can happen at any stage. Some types of damage can be repaired in another stage. Other damaged goods may be recycled in a smaller product, and some must be scrapped.

The chief economic consequence is when remaining semi-finished material falls below the minimum order size in the middle of the process, but the shortfall is not discovered until time of shipment. This begets a make-up order that effectively doubles the production time, leading to unhappy customers.

The employer has tried attaching traveller documents to each lot of material, requiring employees to fill out forms at the beginning & end of their processing steps, but the documents often become separated from their material and are lost. There is no central process monitoring system to catch these shortfalls automatically as soon as they occur, and not means to compile statistics that would identify specific stages/employees/products with the majority of the problems.

My friend wants a bar code scanner and numeric keypad at each workstation, with separate bar codes for each job, workstation, and employee, and a centralized data base management system that is user-friendly enough to allow process monitoring as something less than a full-time job necessitating hiring quality-only employees.

I would estimate the number of stages or workstations at around 12, losses at $4k/month, and total employees at 60. We will have to run the cable for the network ourselves so that is open at this point. I hope to keep the hardware costs under $20k, but this is a guess.

The users would input quantity in & out, times in & out, start & stop times of the stage, and workstation & employee numbers. For output I can see a list of all jobs in progress, and the ability to pull up a graph of the projected final item count vs time, with markings to tell what step is represented by each bar.

As the customer becomes more acquainted with the system's capability, he would want to be able to: - Identify bottlenecks that jam up the pipe, - Compare productivity of different employees or machines, or shifts, etc.

The environment holds a lot of dust, but no grease or oil. It's all within one building, which has a high, open ceiling, which is probably where we'll run the cable/wiring.

Can anyone point me at a framework involving a central PC + (relatively inexpensive) input stations + network that can tackle this situation with a little configuration work and leave the employer with a with a system he can maintain without a full-time network professional to keep it going?

Is there an industry-standard term for this kind of system?

I once worked for an environmental monitoring manufacturer, who built simple input stations around (Intel) 8096-family MCUs, linked together by a proprietary protocol based on DTMF tones. The bandwidth was miserable, but the data was not excessive, and it would work over really cheap wiring (UTP).

I need to make a proposal in the next month or so.

Thanks in advance for your input. ============================================================ Gary Lynch | To send mail, change my bookworm@no$pam.com | domain name from "no$pam" | to "execpc". ============================================================

Reply to
Gary Lynch
Loading thread data ...

An industrial engineer who knows what they are doing?

My 2c is, from the little I know, is that nothing is going to fix the underlying problem, which sounds like shoddy production at all stages.

What you are after sounds like a basic time recording system. If it is ano pen space, perhaps a simple wireless system might work. A simple hand piece that people enter station, employee, item, job, time start/stop, whichit then store and forwards back to the database on the server.

Reply to
Terryc

Sounds way too complex.

The best solutions are the simplest, and sounds like all they need is a cell-container system.

Reserve one for rejects, and it becomes very clear at a glance when the GOOD containers are falling short, and the reject ones are edging to quota.

Can even colour code them, for 'fatal' and 'revival' candidates.

You need something the operators do not lose time using, but that gives 'at a glance' status.

-jg

Reply to
Jim Granville

I agree in that a good computerized system often evolves from a good manual system. Given the current manual system is failing, just throwing computers at it will not necessarily solve the problem.

If you are googling, look for MRP (Manufacturing Resource Planning) systems. They may be overkill for what you want but that is the basic product area that should have modules to do what you want.

It have been a long time since I worked directly on a system like yours, but I have some comments: To be successful, it will require cooperation of the workers. They need to see the benefit for them. Your hardware cost estimate seems low, because you still will require some industrialized devices (which of course cost more). Can you prototype it? Can you put the system in place for part of the production line? Or for a line that does one product? Barcoding may be overkill. Where are the barcodes? on every piece of raw material? Who applies them? When?

The programming itself should be fairly straight forward. That simplicity of the software is perhaps leading you to think the entire system is simple. But the system includes the raw materials & finished products, the machines, the computer hardware, and the workers. You have an advantage in that it is a small company. You should be able to show that better products lead to happier customers and more profits for both the company and the workers. Getting user (worker) buy in is crucial.

HTH, Ed

-- Magic Interface, Ltd.

440-498-3700 Hardware/Software Alchemy
Reply to
Ed Prochak

I see two problems - High scrap - No visible way to see what the progress of a project is.

I think data collection compounds the problem. It gives the illusion of control without actually offering any. This kind of data collection is good for detemining what happened not what is occuring.

My bet would be that if you cleaned up the line and asked the employess what the problems are they would be able to identify most of them. I would also bet there is a fair amout of staging of product between stages, hiding problems until well after they occurred compunding the problem.

Two suggestions - Get the employer out on the floor for a bit. Actually working not just observing. - Read up on lean, maybe get some help in that area. This is the kind of thing lean was developed to combat. Ideally there should be no WIP accumulating between stages. If there is no WIP then at each stage you must have all the items you need for the order and they must be correct.

Sorry not much in the way of technical suggestions but this apears to be more of a process, culture and people problem than a technical one. I think automation would only help by reducing effort if the paper method already produced results. If the paper method is the miserable failure it appears to be from your description I think all automating will do is give you an expensive miserable failure. Changing culture is not an easy task and not for thr faint of heart. It'll require someone with conviction and support, a lot of people will resist changing their waya unless their is a palpable crisis.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

As someone else has already observed, this is essentially a process problem and, until you solve the problems with the process, no end of automated data collection will improve the way it is is going to work. The fact that the paper based attempt failed should have told you this.

The company needs to take a good close look at the way it does it's fundamental job. From the description it is sounding like the raw material is probably metalic and becomes a component to the customers who then build it into their own product.

The plastic crate idea is very workable in such situations. They are cheap and if you get them in several colours you can colour code the good, the recoverable and the total rejects. Adding some of that roller conveyor will help to move the crates around.

There will, of course, be no substitute for you paying the factory a visit and looking over the situation for yourself (preferably with the factory manager in tow). Once you have seen how they operate some solutions are bound to suggest themselves and become very obvious.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett
[story of badly designed manufacturing process.]

Adding computers to a badly designed manufacturing process isn't going to help. If the workers aren't following procedures and filling out forms on paper, then putting the forms on a computer isn't going to help.

Your friend needs to hire a manufacturing engineer, not somebody to cobble together some computers and bar-code scanners.

Automating a broken process still results in a broken process.

--
Grant Edwards                   grante             Yow! ... If I had heart
                                  at               failure right now,
                               visi.com            I couldn't be a more
                                                   fortunate man!!
Reply to
Grant Edwards

I second that. If you can't make it work right on index cards, you can only screw things up faster with a computer.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

Do you have any of this code? I still program i8096 and have been collecting code whenever it presents itself.

Regards,

Michael

Reply to
msg

Apologies for the late follow-up. My time is limited and my UseNet service is not terribly reliable.

I had not thought of this approach. It certa>

That has been bothering me, too. It doesn't sound like they know what is going on.

That, at least, I can f>

I am coming to see that.

Sadly--no. By the time I hired in, they had been adding features to the point it was bandwidth-limited under that system, and were in the middle of a conversion to LonWorks, meaning 2 uPs/node and the end of simplicity.

I think the key insight is I need to see this process in operation, which I have been avoiding as I will have to use my vacation to accomplish that. This has grown way beyond a little personal favor.

Thanks to all who contributed. ============================================================ Gary Lynch | To send mail, change my bookworm@no$pam.com | domain name from "no$pam" | to "execpc". ============================================================

Reply to
Gary Lynch

I am not sure this assessment is correct. If the data processing is done in near real time or even at the end of a day, it can produce very useful compilations of information. I think they are looking for an indication of a problem at day 3 instead of day 7 of a 7 day project.

I'm not sure what you mean here. It seems that the process steps are batch oriented. Since the projects are of limited size, the entire project is run to completion at each process step before moving on to the next process step. This is not like an assembly line where the same thing is made day in and day out with limited, preprogrammed variations. This almost sounds to me like a machine shop where each job is unique and has unique potentials for problems.

I don't understand what you are saying here. If you need all of the materials for each step, wouldn't that mean you have the work in progress at each step?

I agree that it sounds like there may be personnel problems. If they can't keep a piece of paper with the work, how are they going to correctly use a data entry system? It is not uncommon for workers to use passive resistance to management dictated systems, especially when they feel the systems will be used to track the employees and hold them accountable (when they don't want to be accountable).

I read a book once, (honest, I really did read a book once!) that discussed some of this, called "The Reckoning" by David Halberstam. It was a comparison of the US and Japanese auto industries. An interesting account they had was from back when fenders were made by hand using hammers. The company wanted to up production and tried raising the quota from maybe 14 to 16 fenders a day. The workers didn't like that idea and instituted a slow down. There was nothing wrong that the supervisors could point to, but the production went down to 12 fenders a day. After a week or so the quota went back to

14 fenders a day. That is a good example of how workers need to be included in the management process.

I have some first hand experience with places where the workers ran the company, and not in a good way. Management has to work *with* the workers and not against them. But you can't let the workers run over top of you either. Another story, first hand, is in a restaurant. A friend was an assistant manager and worked evenings. I came in to repair some of the cash registers. They were tied into a computer in the office and had fairly robust cables with chains to keep the stress from being on the cable at the connector. When they would have a busy night, the bartenders would 86 the registers and pocket some portion of the cash. They knew they couldn't be fired because there would be no one to work the bar. So they would actually rip the cables from the connectors (it likely took a yank with full body force behind it) so the registers could not be used until they were repaired. They didn't care if they were fired the next day... Funny though, this one guy in particular who did the register damage would get rehired in a few weeks when they were short handed. Pretty crazy, huh? The point is that I couldn't come up with any technology that would keep him from killing the register. Management needed to have better relations with the bartenders ;^) or just fire his ass and ***NOT*** hire him back!!!

Reply to
rickman

My suspicion is that the problem should be obvious within minutes of it occurring. Worst case at the end of the step. Collection of data only gives the illusion of control simply because by the time the problem shows up it's long past the time of simple correction. To get actual control the problem needs to be flagged as it occurs. The further away in time you are from the event the less actual control you have.

That may indeed be the case (that they are batch processing). That doesn't mean that it should be the case or that that it would be easy to change even if it can be done as a more continuous process. But even without going to a fully continuous process it may be quite possible to reduce the amount of staging. That will help catch errors earlier if you can do it.

That's diagnosing by remote control though and it's also where corporate culture would need a dramatic shift to change. Not a job for an outsider unless everyone is in agreement that change needs to happen.

Idealy, not between stages. Each stage should have what it needs to perform its step but there should be no build up between stages. Practically you reduce to a minimum rather than zero of course. Batch sizes of one tend to work better for larger pieces with short setup times than for smaller pieces with large setup times.

Yep, if it doesn't work with paper all automation does is is give you a more expensive failure. However that doesn't mean that the people are at fault. If the production personnel have no reason to believe the data collected is being used to help them produce better (as opposed to being used to punish, generate endless exhortations to improve or simply ignored), they have no incentive to complete it accurately and in a timely fashion. And if it gets in the way of them actually doing their work....

That's why I suggested getting the employer on the floor. And talking to the employees and seeing where the problems lie. - Is training complete? - Are the machines in good working order? - Are the needed parts delivered in a timely manner? - Are they pressured to let thing through to be fixed later rather than do it right to begin with? - Are quality/fit issues only addressed at the final stage?

The first step might be as simple as putting a red tag on a box when the finished product of a production step is not complete due to missing inputs or quality issues. (Maybe yellow for product being worked on and green for waiting for the next step). Trouble becomes apparent at a glance. Each stage then is responsible for checking the incoming is correct as well as the outgoing and can flag bad material. For the final stage to get bad incoming then hopefully, the only ways that can be possible is if the stages immediatedly before missed a quality check or the specifications for the input pieces were wrong.

Automating the tag is simple, of course.

Or maybe the operators need a quick and simple method for checking the output of each stage for proper quality. Maybe a 1:1 printout to check the part.

Or maybe the equipment should be arranged on a project basis rather than a functional basis so that everyone on a project can see the status of all the components rather than having the pieces scattered around the plant.

Or ....

And this sounds like a continuing job for the production manager not for a simple automation quickfix. Making it simple and robust is the difficult part of course.

Robert

** Posted from
formatting link
**
Reply to
Robert Adsett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.