Warum manche AOI-Bediener ruhiger schlafen

Transkript

1 Warum manche AOI-Bediener ruhiger schlafen Über die Vorteile einer Referenzdatenbank in der AOI-Software Eine bekannte Situation Jeder Bediener von Automatischen Optischen Inspektionssystemen kennt diese Situation: das Prüfprogramm für eine Baugruppe ist fertig gestellt und läuft auch schon einige Zeit in der Produktion. Es macht genau das was es soll gute Bauelemente als gut betrachten und Fehler bzw. Auffälligkeiten auch als solche erkennen und markieren. Doch plötzlich treten vermehrt Auffälligkeiten (auch als Pseudofehler bezeichnet) auf, die scheinbar keine Ursache haben. Die BedienerInnen an den Reparaturplätzen sind genervt und die Produktion kommt ins Stocken, weil zu viele Baugruppen als fehlerhaft erkannt und ausgeschleust werden. Nun ist Eile geboten. Das Prüfprogramm wird hektisch geändert, Parameter angepasst, Einstellungen verändert. Mit den neuen Einstellungen klappt es dann auch die erhöhte Auffälligkeitsrate sinkt und alles sieht wieder bestens aus. Man nimmt sich vor, die Änderungen noch mal anzuschauen, aber da kommt schon der nächste Einsatz, und bald ist es vergessen. Der Zweifel bleibt, ob das Programm auch noch alle Fehler findet wie bisher. Oder geht das mit den geänderten Parametern gar nicht mehr? Kommen bei der nächsten Charge von Bauelementen wieder die gleichen Auffälligkeiten, die schon einmal beseitigt wurden? Wie könnte eine Lösung aussehen? Hilfreich an dieser Stelle wäre ein Mechanismus, der diese Änderungen an einem bestehenden Programm verifizieren kann. Es müsste eine Methode existieren, mit deren Hilfe man sicher sein kann, dass die geänderten Parameter und Einstellungen am Prüfprogramm auch bei bereits gefunden kritischen Fehlern und natürlich auch bei korrekten Bauelementen und Lötstellen funktionieren. Das Programm müsste die Einstellungen der Prüfschritte von bereits gefundenen Fehlern genauso wie normale Erscheinungsformen von Bauelementen speichern und auf Abruf mit den Einstellungen des aktuellen Prüfschrittes vergleichen können. Und das alles am Besten auf Knopfdruck. Ein PILOT bietet die Lösung Die Software OptiCon PILOT der AOI-Systeme von GÖPEL electronic bietet genau so ein Tool. Am Reparaturplatz oder auch schon während der Prüfprogrammerstellung können kritische Fehler bzw. auch korrekte Bauelemente und Lötstellen in einer Datenbank gespeichert werden. Das

2 geschieht per Knopfdruck. Lediglich ein Kommentar kann noch eingegeben werden, welcher am Reparaturplatz automatisch mit der aktuellen Fehlerklassifizierung ausgefüllt wird. Diese Referenz-Datenbank speichert alle zur Prüfung relevanten Daten. Dazu gehören neben dem Bild auch alle Einstellungen des Prüfschrittes, alle Einstellungen des entsprechenden Bibliothekseintrags, das Prüfergebnis sowie einen Kommentar, um festzuhalten um welchen Fehlertyp es sich handelt bzw. warum dieser Schritt in der Datenbank enthalten ist. Mit diesen Angaben kann zu jedem beliebigen späteren Zeitpunkt die Prüfung nachvollzogen werden. Bild 1: Typische Anwendungsgebiete der Referenzdatenbank Der Sinn dieser Lösung Mit einer ausreichenden Datenbasis können nun ebenfalls auf Knopfdruck Änderungen in einen Prüfablauf automatisch verifiziert werden. Ein geänderter Prüfschritt kann gegen alle Einträge dieses Prüfschrittes in der Referenz-Datenbank geprüft werden. Dabei wird der aktuelle Prüfschritt mit all seinen Einstellungen in den Bildern der Datenbank ausgeführt. Das Prüfergebnis wird mit dem in der Datenbank gespeicherten verglichen. Stimmt alles überein, ist alles in Ordnung. Ist aber zum Beispiel das Ergebnis in der Datenbank FAIL und das gleiche Bild wird nun mit den aktuellen Einstellungen PASS gefunden so ist dies eine Situation, die bedenklich ist. Denn dies bedeutet, dass die Einstellungen des Prüfschrittes so geändert wurden, dass der bereits gefundene Fehler nicht mehr auftauchen würde Schlupf wäre die Folge.

3 Beispiel: Dieser Fehler wurde bereits gefunden. Auf der rechten Seite befindet sich zu wenig Lötzinn. Bild 2: Beispiel für richtig erkannten Fehler Aber die Einstellungen des Prüfschrittes sind im Laufe der Zeit so geändert worden, dass dieses Bauelement als PASS bewertet werden würde: Bild 3: Beispiel für nicht erkannten Fehler Aber welche Eigenschaften wurden denn geändert, welche müssen wieder rückgängig gemacht werden, und auf welchen Wert muss gesetzt werden? Ist es die Schwelle für den Grauwert, der Bildfilter, die Größe der Maske oder eine Toleranz? Fragen über Fragen, die bei Tausenden von Prüfschritten mit vielen Parametern pro Prüfschritt auch erfahrenen AOI-Bedienern die Schweißperlen auf die Stirn treiben.

4 Die geeignete Software kann dabei entscheidend helfen. Bei Feststellung eines solchen Unterschiedes im Ergebnis wird ein Dialog angezeigt, in dem automatisch alle sich unterscheidenden Parameter der beiden Prüfschritte dargestellt werden. In einer Tabelle werden für jeden dieser Parameter jeweils der aktuelle und der in der Datenbank gespeicherte Wert dargestellt. Bild 4: Darstellung widersprüchlicher Testergebnisse Damit reduziert sich die Anzahl der Möglichkeiten in der Regel auf einige wenige Einstellungen. Der Prüfschritt kann nun so geändert werden, dass er sowohl im aktuellen Bild als auch in den Datenbankbildern das entsprechende Prüfergebnis aufweist. Die Gefahr eines Schlupfes ist gebannt, und die Sicherheit des Prüfprogramms ist im Rahmen der Datenbasis gewährleistet. Das Verifizieren ist nicht nur auf Prüfschrittebene möglich. Es können ebenfalls ein kompletter Bibliothekseintrag mit den Datenbankeinträgen der entsprechenden Baugruppe oder auch mit den Einträgen aller Baugruppen verglichen werden. Damit ist es möglich, trotz mehrfach verwendeter Bibliothekseinträge sicher zu gehen, dass diese in allen Prüfprogrammen funktionieren. Die Vorteile der OptiCon Referenz-Datenbank für den Anwender auf einen Blick: - Vermeiden von Schlupf bzw. erhöhten Auffälligkeitsraten - Sehr einfaches Hinzufügen von beispielhaften Fehlern bzw. korrekten Bauelementen und Lötstellen - Einfaches Verifizieren von Änderungen - Vergleich aller prüfrelevanten Einstellungen und übersichtliche Darstellung der Unterschiede auf Parameterebene - Datenbankorientiert damit paralleler Zugriff von allen Anlernstationen, Verifizier- und Reparaturplätzen möglich

5 Nutzer dieses Tools ist unter anderem die Firma HASEC ( in Seebach bei Eisenach. SMT-Techniker Volker Henning ist begeistert: Für uns ist die Referenz-Datenbank zu einem wichtigen Werkzeug geworden, da es hiermit möglich ist die Auswirkung von geänderten Parametern direkt beim programmieren zu prüfen. Mit den gewonnenen Daten ist es möglich bei Parameteränderungen zu verifizieren ob diese evtl. Auswirkungen auf bisher sicher detektierte Fehler haben. Auch ist es wichtig zu prüfen ob durch Änderungen an Parametern ein Schlupf entstanden ist, der evtl. das Auftreten von Anomalien (Pseudofehlern) erhöht. Hierbei ist die Datenbank ebenfalls ein schönes Hilfsmittel da auch Gutbeispiele darin gespeichert werden und zur Analyse beitragen.