Circuits Assembly - August 2008 - (Page 29)

Program Generation and verified on the machine. When components are loaded on the machine, the new components are verified and adjusted accordingly. The key to Dynamic Programming is to first test the new settings on the machine, and then update the database. Once all the components have been tested at the machine, the program is deleted and a new program generated and downloaded to the machine. Established components are set and there is no need to look at them when debugging floor programs. At that point, confidence is 100% that the offline program generator database is synced with the machine information. As the machine component information changes, so too does the database on the offline program generator. Hence, Dynamic. It is a tedious process that takes discipline and control. This is why, if there are several workers generating programs, they need to be disciplined and follow all the process steps. Support programmers should understand the database workings and be fully aware of the consequences of not following the process. A single individual should be named database Key Master to ensure processes and rules are followed. They should review each program generation. I require my support programmer to fill out a simple form that details changes made. My programmers do this as they make changes to ensure they document everything that was changed. A database is also maintained to track who changes certain component information, when they did so, and for what reason. This also reveals what new components are pending review. In our company, this database is actually linked directly to the component database in the program generation software. Maintaining control. Controlling the offline database is key to this process. Slacking on updating information will return the database to its previous, untested state. Testing the programs at the machine, then entering them into the offline database, then regenerating the program not only ensures the database is correctly aligned with the machine information, it keeps the data integrity intact and under control. circuitsassembly.com And yet, occasionally some programmers will update machine information and forget to do so with the database, or they lack time to update the information. This usually happens when something is fixed on the fly. One of the biggest problems I have is component thickness changes, especially on small chips. Because of this, it becomes necessary to compare the machine library with the offline database. (The software I use has a feature that permits this.) Although not an ideal solution, it does provide a comparison and the ability to reject or accept the changes. On the other hand, it does it globally: The software won’t permit a user to reject an update for a certain part number and then accept another one. To remedy this, detailed notes are taken on the update, and then the necessary corrections made to the machine or offline database. Doing this weekly doesn’t take much time. Less frequent updates have a tendency to increase the update time sharply. Falling short. Equipment manufacturers do understand the importance of having the offline databases in sync with the machine libraries. They often ask about it. But they usually fall short when it comes to making this task as painless as possible. Five to 10 years ago, most machine communication was done over serial communication. Since then, network capabilities have improved and machines come with Ethernet connections. Yet a constant link of the machine library to offline database has yet to be created. It would be much easier if, as soon as corrections were made on the machine, the offline database updated automatically. Of course, that would necessitate tighter security on production machines to ensure library and database integrity. The time from program generation to manufacturing products needs to be reduced. It is possible to shift the majority of the time spent debugging programs directly on machines to offline programming. This task isn’t an impossible task, but requires written procedures and discipline to follow certain rules. n Edward Faranda is a senior manufacturing engineer at QSC Audio Products LLC. (qscaudio.com); ed_faranda@ qscaudio.com. See us at SMTA Int’l, Booth 635 Circuits Assembly AUGUST 2008 29 http://www.seho.de http://qscaudio.com http://circuitsassembly.com http://www.seho.de

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.