Pogo pin testcard bouwen

Momenteel laat ik kleine batches met PCBA maken waarvan de uitval redelijk hoog blijkt te zijn. Er was me verteld dat 3 tot 5% uitval redelijk normaal is, maar inmiddels zit ik al op bijna 15% uitval.

Gevoelsmatig denk ik dat ik nog te kleine batches draai om flying-probe of pinnenbed te laten maken. Bovendien veranderd het design toch wel frequent.

Mijn plan was om een universele testcard te maken met pogo pins erop gesoldeerd waar je de PCBA na productie op kunt drukken. Dus bijvoorbeeld een A4 formaat PCB met een groot grit aan gaatjesprint waar je pogo pins in kunt solderen die via multiplexing zijn te benaderen.

Via een microcontroller kun je dan bijv. zeggen meet pogo pin x/y en pogo pin x/y door. De vraag is wel of je dan ook zaken als I2C en SPI testcommando's door de multiplexing circuit heen kunt sturen.

Ik vroeg me af hoe jullie zoal testing aanpakken.

Je kunt ook een vast aantal pogopinnen gebruiken op vaste plaatsen en dan op je PCB ontwerp steeds test-pads op de plek van die pogos maken. Ik heb wel eens een PCB gezien waar langs de rand van de print een stuk of 30 testvlakjes daarvoor zaten. Als je zo wat groepjes maakt kun je nog een beetje flexibel blijven.

Als je later nog wat meer nodig hebt of op een andere plaats kun je misschien een header plaatsen en zo een verbinding naar je fixture maken.

Kun je niet een eenvoudige opstelling maken die functioneel kijkt of het geval werkt (als mogelijk) Als de uitval gerepareerd moeten worden kun je met gewone test punten en een scoop/DMM aan de gang.

Ik ontwerp geen printen maar ik maak wel vaak meetopstellingen.

www.pa4tim.nl, Reparatie van meet- en calibratie apparatuur, ook oud en exotisch
EricP

mét CE

Zelf 3% vind ik best veel. Bij seeed regelmatig wat laten maken. Meestal 10 bordjes besteld. Dan krijg je er 11 of 12. En die doen het ook allemaal.

Dat gezegd hebbende: je kunt (tegen meerprijs) ook laten testen. Is dat niet een goedkopere oplossing dan zelf knutselen?

Dan komen de componenten die er blijkbaar al op zitten. Dat is wat lastiger. Echter, als er een controller op zit, dan kun je wellicht iets met test firmware. Bussen kun je vaak wel testen (als er op I2C een ACK terug komt en je kunt nog een serienummer opvragen, dan zal het waarschijnlijk wel werken. SPI kun je ook vast wel een nummertje ofzo opvragen).

Ja A4-grid is best lastig. Een pogo-pin is groter dan SMD pads zijn. Dus 'altijd passend' krijg je het niet - tenzij ruimte geen probleem is. Of je moet inderdaad in je ontwerp op bepaalde punten test points gaan zetten.

Als ik zelf SMD assembleer (ik probeer het te voorkomen, maar ja...), dan is het ook eerst de voeding optuigen. ff spanning erop. Kijken of dat leeft. Dan kan er een controller op. Test firmware erin. Kijken of alle meuk er omheen zich zinnig gedraagt. Wellicht nog ff een looplicht oid. op wat LEDs als die er zijn. Als dat het allemaal doet, dan zal het voor de rest meestal wel (dan heb je vaak als best veel van een stuk hardware te pakken). Ga dan maar eens kijken of het zich functioneel correct gedraagt.

Mijn PCBA's mogen van de klant niet in China gemaakt worden.
Is de testoptie die seeed aanbied niet alleen pcb doormeten voordat PnP plaatsvind?

Ik heb aan de onderkant van mijn PCB ontwerpen nu al testpads her en der zitten.

Een vast groepje testpads vergt vaak wel een hoop extra routing door het board heen om accuraat te kunnen test dacht ik om bijvoorbeeld gelijk een via te plaatsen bij het te meten punt. Dan kan daar de pogo pin in vallen.

Mijn batches zitten nu op zo'n 50 stuks per keer.
Zo'n pinnenbed laten maken lijkt me een dure aangelegenheid en is niet makkelijk up to date te houden vrees ik.
Al ken ik die wereld niet goed genoeg om die optie al helemaal af te serveren.

Voor led matrixen heb je leuke multiplex trucjes die ik misschien kan inzetten om mijn pogo pinnenbed te multiplexen. Dan is immers mijn testrig makkelijk te updaten.

fatbeard

Honourable Member

Pogopinnen vastsolderen zou ik niet doen: die dingen slijten en gaan stuk; gebruik hulsjes waar de pennen in passen. Elk zichzelf respecterend merk heeft dat, en zelfs sommige 'budgeteers'.

Neem de juiste maat pogopinnen voor het te testen punt, te grote zijn duurder, nemen (te)veel ruimte in (in zowel X, Y als Z richting) en vergen (te)veel kracht; te kleine zijn hoewel goedkoper vaak erg kwetsbaar en kunnen misschien de stroom niet aan.
Let op het hoogteverschil als je meerdere soorten door elkaar gebruikt.

'Universeel' is in de techniek veelal een synoniem voor 'past niet' ;), ik zou voor elk design een apart testboard maken. Door hetzelfde ontwerp te pakken en de testvlakjes te voorzien van een (zonodig handmatig geboord) gat ben je verzekerd van correcte passing.
Maar dan ben je er nog niet: je zult ook voldoende druk moeten kunnen uitoefenen, én het pennenbed rechtstandig op de te testen PCB moeten kunnen aanbrengen (of andersom), pogopinnen verdragen doorgaans weinig tot geen zijdelingse krachten.
Met Google zoeken op “pogo pin bed of nails”

Ik ben het met EricP eens: 3% is teveel, wij hanteren een bovengrens van 1.5%.
Een gedegen foutanalyse van meerdere uitvallers is noodzakelijk om de oorzaak aan te wijzen, dat kan een procesfout zijn bij de PCB fabricage, het bestukken, het soldeerproces, onderdelen kwaliteit of zelfs een ontwerpfout...

Een goed begin is geen excuus voor half werk; goed gereedschap trouwens ook niet. Niets is ooit onmogelijk voor hen die het niet hoeven te doen.

Een echt pennenbed is zelden echt nodig. Wat ik (in m'n vorige baan) steeds deed was op strategische plekken testpads zetten. Dus plekken waar essentiele spanningen staan: voedingen, input/output, instelspanningen. Punten die je ook al wilt meten als je de proto test.
Daarnaast als er een micro is (bijna altijd), had je testcode of een apart testprogramma. Die test al veel dingen, bv memory access of lezen van analoge signalen. Vaak heb je wel wat analoge inputs over, daar sluit je handige signalen op aan, bv een led-spanning, voedingen (doen!). Die punten kan de micro dan zelf meten, en hoeft dus eigenlijk al niet meer op een TP.
Dan een testboardje met een aantal pogo's erop. Die prikken op die TP's die je hebt. Op het boardje zit wat control en DAC/ADC om te stimuleren of meten.
Bottom line: doe zoveel mogelijk in je micro zelf, BIST dus (Build In Self Test).

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
PE9SMS

Special Member

En als je micro JTAG ondersteund dan biedt dat ook allerlei test mogelijkheden.

This signature is intentionally left blank.

De te testen PCB heeft bijna het formaat van een motherboard, moet er echt zoveel druk op de pogo pinnen uitgeoefend worden?
Eigen gewicht van het board is niet voldoende?

Mijn microcontroller bevat inderdaad JTAG, maar heb daar nooit het echt nut van begrepen.

Stel ik wil een DC driver chip testen, ik schrijf wat testcode en wil dan controleren of de DC driver chip werkt (nog zonder dat de motor eraan hangt)
Kan ik daar op een bepaalde manier JTAG voor inzetten?

Een centrale test connector zou misschien toch wel beter zijn omdat je de monteur dan een handzame testcard kunt meegeven en hij/zij ook ingebouwde boards kan testen.
Je krijgt dan wel een hele hoop meer routing tracks waar er ook tussen gaan zitten die je niet onnodig lang wilt hebben

Met excuses voor het herhalen van de open deur, goed controleren op bestückfouten en testen is belangrijk, maar als de uitval van productie of in bedrijf te hoog is zou ik daar mijn tijd in investeren.
Een pech serie kan, maar producten behoren imo eigenlijk "altijd" te werken.

Zijn er fouten of onhandigheden in de ontkoppeling, routing etc. ?
Allicht is de omgeving ruig en niet alles realistisch te voorkomen. Dan kan een modulaire opzet in plaats van een groot board een handig / economisch idee zijn.

Op 29 juni 2020 15:17:34 schreef EricP:
Zelf 3% vind ik best veel.

Het hangt bij mij erg sterk van de print af. Bij 1 project krijg ik inderdaad richting de 10% niet werkende printen na PCBA.

Bij die print is het dat de uitsparing in het soldermask vrijwel even groot is als de uitsparing in het groundplane. Bij een paar procent is dan het solder mask iets verschoven waardoor er een minuscuul stukje groundplane onder het soldermask vandaan kijkt. Bij het solderen van de through-hole pin weten ze dan met een soldeerballtje kortsluiting tussen de pin en het groundplane te maken. Dat is bij mij de meest voorkomende fout. De through-hole dingen zijn in dit project "schakelaars" en "7 segmenten display(s)". Je ziet dan bij het testen dat ofwel 1 segment het niet doet over alle digits, ofwel 1 digit doet het niet over alle segmenten, ofwel 1 schakelaar doet het niet.

Bij een aantal andere projecten heb ik minder dan 1% uitval. Sommige zo weinig dat ik er gewoon van uit ga dat het werkt. Geen klachten. (testen is duurder dan klachten afhandelen). (voor grote klanten stuur ik dan soms 1/30 of 2/100 extra printjes: Als je er 1 kapot vind: sorry, ik zal hem vervangen, de vervanger heb je al in huis. Als iemand er 1 koopt zal ik een nieuwe op moeten sturen).

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op 1 juli 2020 00:26:32 schreef spruce:
De te testen PCB heeft bijna het formaat van een motherboard, moet er echt zoveel druk op de pogo pinnen uitgeoefend worden?
...
Stel ik wil een DC driver chip testen, ik schrijf wat testcode en wil dan controleren of de DC driver chip werkt (nog zonder dat de motor eraan hangt)
Kan ik daar op een bepaalde manier JTAG voor inzetten?

Je moet de pogos wel een beetje indrukken, actief. Als je board groter is, heb je waarschijnlijk ook meer pogos, dus board grootte helpt je niet.
JTAG, heb ik niet zoveel ervaring mee bij micros, maar in jouw voorbeeld heb je er niets aan denk ik. JTAG is een wat universelere testbus die ook voor programmeren wordt gebruikt. Voor test heb je bv 'boundary scan', waarmee je pinnen kunt forceren of uitlezen. Als je dat forceren met een bepaald patroon doet, kun je bv een flash programmeren, of een driver aanzetten. In jouw geval zou je die driver kunnen bedienen, maar uitlezen moet je dan op een andere manier doen. Ik zou dat dan liever direct in de testfirmware doen.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein