Electronic – PCB in circuit tester design

pcbpcb-designproduction-testing

Imagine you want to produce 1k pcs of hardware(mixed signal) per month and you would like to have tester in order to load firmware, calibrate sensors etc.

How do you approach that problem? I see many of people are talking about in-circuit tester using pogo pins.

Is that something you buy and "just" write firmware and position the pins correctly? Do I need to develop test hardware and then just use pogo pins to connect it with the pcb in testing?

EDIT: Ok, I intendedly asked general question, but I will specify it more.

There is a request to design 4 layer PCB with MCU, external memory, display, eeprom, CAN and Bluetooth Smart. PCB will be produced in 1000 pcs. per month.

Obvious fact is that I must design/buy piece of hardware which I will give to technician in order to test production items before attaching QC marks on it.

  1. Is that kind of hardware something you buy from i.e. NI and use LabView to program the test procedure
  2. Do I need to design PCB with MCU and bunch of analog and digital I/O, program it with production firmware and use it to flash the code to production PCB's. If yes, are the pogo pins and box shown on picture below right way to do it? Example of PCB test box

I agree that the question is too broad but I couldn't find any relevant information regarding the topic online.

Thank you all for your help!

Best Answer

Yes, this sort of thing comes up regularly. We have settled on a system that works pretty well for small boards. Here is one example:

The top part is hinged at back and swings up. You then place the board to test in the cradle for that purpose:

What you can't see in that picture are the pogo pins that stick up from the tester under the board. When the lid comes down, it presses on the board at carefully selected points. This compresses the pogo pins a bit so that they make reliable contact. Pads were designed onto the bottom of the board under test for just this purpose.

When the lid is lowered, a little latch swings over part of the lid arm:

This does two things. First, it locks the lid in place keeping the pogo pins compressed a little. Second, it releases pressure on a microswitch. This switch is wired to the processor on the tester. It is used as the signal to start a new test.

The general design is canned, but the details are not. The pogo pins are held in place by the thick plastic piece screwed to the test board. This has holes in it matching thru-hole pads in the test board below. The pogo pins holders are placed into the holes in the plastic from above. A small piece of each holder protrudes thru the pad in the tester board, and is then soldered from the bottom.

This is a convenient way to make electrical connections to the pogo pins. They are just single-pad thru-hole components from the tester board's point of view.

The tester then contains whatever circuitry you need to test the board. This usually includes controllable power supplies with voltage and current signals going into the control micro. In this example, part of the test procedure was performed on a PC, and the tester communicated with the PC via USB. A PIC 18 was used to run the tester.

The test procedure includes programming a PIC in this case. For that we usually start with our USBProg PIC programmer circuit, but use a larger PIC so that there are a bunch of pins available for the test function. We even added 16 reserved commands to the official PIC programmer protocol to support testers that are USBProgs with added features.

Once we have the test circuit board mechanical details, we send them off to a mechanical engineer that we work with. He then takes the general tester design and adds the details for that specific tester. He designs the bottom plastic part, the lid, the exact mounting holes, the plexiglass top cover, and the like. We've done this a few times, and have the process down to a few $1000, usually for three tester units. Of course the cost of developing the tester firmware and host software is the biggest expense.

In general, figure the tester is roughly of the same level of complexity as the thing it is testing. You need to alert management of this early so that they know it's coming. All too often they think you're done with a project when you get the first prototype working on the bench.

Even if you've warned them all along, you still often find inexperienced managers that don't want to take 2 months to develop a proper tester, after having just spent 4 months developing a product that needs testing. The best solution I've found is to just include a tester in the schedule and budget from the first day, although even that doesn't always work. Particularly inexperienced low level managers have a great capacity for being penny-wise and pound-foolish.