Circuits Assembly - August 2008 - (Page 26)

Program Generation Cutting Machine Programming Time By Edward Faranda How a novel process can avoid repeated online debugging. O ne of the biggest challenges in printed circuit board manufacturing is generating programs offline for production machines. This process is required for every assembly we build. But, for many manufacturing engineers, it means many more hours of online programming when time on the production line is at its most valuable. This costs companies thousands of dollars (or more) in real production time lost – be it overtime or downtime – spent debugging programs while on the machines. How does one create machine programs and have them run perfectly once they get to the machines? I am an ME who battled this for years. I haven’t totally perfected the process, but I have procedures in place to help with this problem. Still, it is a difficult task, despite many years spent in pursuit of perfecting this process. Occasionally I still have to spend time on the floor working on machine programs, tweaking here and there to get them right. This is timeconsuming. With prototype, alpha and beta runs becoming smaller, it becomes more difficult to have a perfected program by the time of production release. In fact, we recently went from prototype to production build in a matter of months, while building less than 10 products. Without a process I call Dynamic Programming, this would be a nightmare at most EMS firms and OEMs. Static programming. I define Dynamic Programming by first describing its opposite. Static programming is the generation of machine programs using a database that defines locations and component information. Every plant has a database that indicates how a particular part looks. This information is pulled as BoM and CAD files require. Good static databases generate error-free programs, but then experience program problems once they are on the machine. The usual result: many hours in program debug on the production floor. Consider how often you have used Part no. 123 on one product, debugged it, and then used the same part on another product only to have to redo the debug. Most production machines contain a part library that defines a particular part. But, there’s still a link file between the placement file and parts library file that says Part no. 123 uses this particular record in the parts library. The problem lies between the libraries on the machines compared to the library in the program software package. Usually, this is where the problem is, and where most engineers fall short in the program development process. How does one keep these pieces of critical information in sync? Hence what I call Dynamic Programming. Dynamic Programming. Dynamic Programming provides feedback to programming software on any information changed on the machine to get it running. It’s surprising how many people fail to do this. Colleagues claim either a lack of time to do double the work or their software doesn’t define that information. To me, both reasons are unacceptable. circuitsassembly.com 26 Circuits Assembly AUGUST 2008 http://circuitsassembly.com

Table of Contents Feed for the Digital Edition of Circuits Assembly - August 2008

Circuits Assembly - August 2008 Contents Caveat Lector Industry News Market Watch Talking Heads Screen Printing Better Manufacturing Auditing a Fabricatior Cutting Machine Programming Time Simultaneous Acoustic Imaging and Surface Mapping Tech Tips Soldering Test and Inspection Process Doctor Pb-Free Lessons Learned Getting Lean Component Advances Product Spotlight Ad Index Assembly Insider Techincal Abstracts

Circuits Assembly - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.