AOI KohYoung

Zde popíšeme integraci AOI KohYoung. Předpokládáme AOI KohYoung, který automaticky otestuje desku a uloží výsledek do databáze. Chyby na výsledku jsou pak dodatečně rozhodnuty na rozhodovacím pracovišti. TracePRO se k datům připojuje přes databázi MS SQL, která je lokálně na počítači připojeném k zařízení KohYoung.

Výrobní linka v TracePRO

Pro zpracování výsledků KohYoung je třeba zařadit zařízení do výrobní linky a nainstalovat výrobní linku na serveru. Použije se obsluha KohyoungAoiHandler, který funguje následovně:

• Každých 30 sekund zkontroluje, jestli je nový záznam v tabulce KY_AOI. Hledá záznam s vyšším číslem pcbid, než je poslední známé.

• Každý nový záznam zpracuje následovně:

  • Z řádku tabulky KY_AOI vezme údaje: pcbguid , resultdbname , imagedbname.

  • Otevře databázi v resultdbname a vyčte z ní údaje k výsledku pod pcbguid.

  • Pokud řádek nemá vyplněn program (jobfileidshare), tak jej odloží na později (docházelo tam patrně k nějakému souběhu - TracePRO zpracovalo záznamy dřív, než byly hotové, a nenašlo k výsledku Výrobní objednávku / příkaz)

  • Z tabulky TB_AOIResult vyčteme: barcode (nebo allbarcode pokud je bacode prázdný, nebo pcbid pokud je allbarcode prázdný), startdatetime, enddatetime, jobfileidshare - použije se jako jméno programu, userid, lot, resultdbname, imagedbname, pcbguid. Také informace o review: reviewstartdatetime, reviewenddatetime, a reviewuserid

  • Jestliže je lot rovno skip nebo test, výsledek je ignorován.

  • Dále z tabulky TB_AOIDefect spojené s TB_AOIDefectDetail přes ComponentGUID vyčteme jednotlivé výsledky pro desku. Bereme pouze výsledky, které nejsou dobré.

  • Pokud je výsledek rozhodnut, zapíšeme jej pod operací AOI z postupu.

  • Pokud ještě výsledek není rozhodnut, zapíšeme jej jako operaci aoi_unresolved, a zároveň jej vložíme do fronty k pozdějšímu zpracování.

• Frontu ke zpracování zpracováváme přibližně každé 3 minuty.

  • Nejprve znovu načteme výsledek z databáze.

  • Zjistíme, zda je rozhodnut.

  • Pokud ano, zapíšeme v rámci postupu a smažeme z fronty k pozdějšímu zpracování.

  • Pokud, znovu jej zapíšeme do fronty ke zpracování s aktualizovaným časem posledního pokusu.

  • Záznamy starší, než několik dní, se už automaticky nezpracovávají.

Zpracování výsledků detailně

Předpokládáme režim, kdy celou skupinu označujeme zaráz (tedy označení jednoho detailu v TB_AOIDefectDetail způsobí označení celé skupiny TB_AOIDefect toho detailu).

##FIXME: screenshot

Výrobní objednávka, operace, …

Potřebujeme zjistit, pod jakou objednávkou a operací zapíšeme výsledek. Pro zjištění objednávky postupujeme následovně:

• Potřebujeme zjistit ID výrobku. Projdeme všechny aktivní výrobní objednávky, a vybereme ty, jejichž jméno je součástí jména programu. Vybereme pouze nejdelší.

• Podle TOP nebo BOT ve jménu programu rozhodneme, zda se jedná o TOP nebo BOT stranu.

• Pokusíme se najít v TracePRO konkrétní existující položku podle barkódu. Pokud neexistuje, tak ji založíme v libovolné z vybraných objednávek. Pokud existuje, tak máme tím pádem i její objednávku.

• Z objednávky se pokusíme vybrat operaci odpovídající straně TOP nebo BOTTOM. Pokud nenajdeme, vrátíme úkon AOI, operaci nic.

Pro zjištění čísla pracovníka:

• Použijeme jméno uživatele vyčtené z výsledků AOI.

• Pokud není v TracePRO takové jméno ani číslo, použijeme [global] workerid_fallback z parametrů aplikace.

Co se děje v databázi

Zajímají nás detaily u TB_AOIDefect ( + TB_AOIDefectDetail).

• Pokud je pole ResultBefore GOOD, nebo PASS (11000000, 12000000), je výsledek bez chyby, ignorujeme jej.

• Po otestování: Pokud je výsledek chybový, ResultBefore je 13000000, a zůstane tak i po review a opravách.

• ResultAfter: Nelze použít. Pokud chyba, tak po otestování je 13000000, jenže pozor, když se udělá review na kterékoliv desce, tak to nastaví ResultAfter = 12000000 na úplně všech!!!

• ResultRepair: Po otestování 0, po review nastaveno na 12000000 pokud OK, 13000000, pokud NG, ale pozor. My při review neoznačíme jako GOOD nebo NG, my mačkáme next. Kdybychom zmáčkli GOOD nebo NG, tak by se výsledek uzavřel, a už by nebyl vidět na repair station. Každopádně, vypadá to, že když je tohle nastaveno na 12000000, tak je chyba rozhodnutá jako GOOD, jinak to zůstává 0.

• InspType je typ chyby odhadnuté strojem, použijeme.

• Failure: 13000000 po celou dobu života záznamu.

• Defect (u detailu): Na začátku nastaven na 30000000. Po review nastaven buď na 12000000 pokud je GOOD, nebo zůstane 30000000, nebo může mít konkretizovanou chybu (300000XX), pak ji použijeme místo InspType.

• Repair: No, tohle je asi zase nepoužitelé, protože při review nebo opravě se to sice nastavuje na 1, jenže když je víc výsledků pod jedním, tak se na repair nastaví 1 jenom na jeden.

• ReDefect: Po otestování je zde 0. Po rozhodnutí je zde: 30000000, ikdyž je třeba ten řádek rozhodnutý jako dobrý. Vypadá to, že tato hodnota se nastavuje na 30000000 průběžně během toho rozhodování. Když je částečně rozhodnuto, tak sem se zapisuje 30000000 jen u rozhodnutých řádků. Když je tady 12000000, tak to bylo opraveno na repair station.

• Status: Na začátku 0, potom to vypadá, že při opravě se to nastaví na 1.

Jak tedy na to

Dorazil nový výsledek. Jak ho zpracujeme?

• Má nějaké řádky v TB_AOIDefect? Pokud ne, tak je rozhodnuto a bez chyb. Zapíšeme přímo AOI.

• Pokud má řádky v TB_AOIDefect, tak je projdeme, a v této fázi tam jistě budou nerozhodnuté záznamy. Zapíšeme tedy operaci AOI Nerozhodnuté, a zapíšeme si záznam do fronty k překontrolování.

Procházíme frontu k překontrolování. Zde:

• Pokud už mají všechny záznamy redefect !=0, tak je aspoň reviewed. Pokud nemají, tak končíme, a zkontrolujeme to později znovu.

• Pro jednotlivé záznamy:

  • Pokud je defect = 12000000, tak je rozhodnuto (reviewed) jako OK (bez opravy)

  • Pokud je defect = 300000XX, tak je rozhodnuto jako s chybou, a defect obsahuje typ chyby. Speciální případ je defect = 30000000, což je unknown, ale řekl bych, že je rozhodnuto, jenom neoznačen typ chyby.

  • Pokud je defect 300000XX a redefect 12000000, tak je opraveno.

Chybový řádek?

V tabulce TB_AOIDefect pole ResultBefore říká, jak stroj vyhodnotil výsledek. 11000000 (GOOD) a 12000000 (PASS) znamená, že výsledek není chybový. Takové výsledky přeskočíme.

Pokud je hned po otestování všechno GOOD nebo PASS, nebo nejsou žádné defekty v tabulce, tak bereme výsledek jako rozhodnutý už na testu, a rovnou zapíšeme operaci AOI.

Rozhodnuto?

Výsledky v databázi jsou označeny číslem chyby. My se konkrétně díváme na výsledek jednotlivých řádků (v tabulkách TB_AOIDefect pole ResultBefore a ResultAfter). Zdá se, že výsledek 11000000 (GOOD) a 12000000 (PASS) znamená, že výsledek není chybový. Jestliže ResultAfter je 0, tak výsledek ještě nebyl rozhodnut. Jinak může být výsledek GOOD nebo PASS - bereme jej jako dobrý, nebo jiný - bereme jako chybu.

Kus byl rozhodnut, pokud byly rozhodnuty všechny řádky.

Fronta na pozdější zpracování

Pokud ještě výsledek nebyl rozhodnut, jsou informace o něm odloženy do pomocné databáze. Data z ní jsou periodicky kontrolována. Při každé kontrole je celý výsledek načten z databáze KohYoungu. TracePRO zkontroluje, jestli už byl zpracován. Pokud ano, uloží se do TracePRO jako výrobní operace z postupu. Pokud ještě ne, je znovu odložen do fronty.

Testovací výsledky

Pokud chcete testovat program bez zapsání výsledků do TracePRO, použijte pro lot jméno skip nebo test. Takové výsledky jsou úplně ignorovány.