Introduction
EOL, end of line, testing is a testing procedure to validate if manufactured devices work as specified. This test procedure is done right before the PCB is shipped.
One of our customers had a need for EOL testing and contacted Nalys to create a proof of concept of an end of line setup. This article describes the implementation and the encountered challenges of the developed EOL setup.
About the project
The customer was in a situation where a lot of manufactured PCBs malfunctioned. For example, a few prototypes were created for the R&D team and they concluded that one of the components didn’t work. This took some time to discover, because in development you’re not always sure where the problem comes from.
An advantage of having EOL tests is that defects can be detected very early in the process and repairs can be performed. In this project the customer chose to repair the PCB instead of replacing it, because a few components were too expensive to replace a complete PCB.
Nalys mission
The mission for this project was to develop an EOL setup that detects hardware malfunctions in different phases of the production cycle. This consisted of creating test equipment, development of the tests and storing all test results.
The most important modules that needed to be validated where UART, Bluetooth, a LED and memory.
Nalys Solution
The tests that needed to be executed were already available in the programmed firmware. To begin a test, a command is send over UART where the firmware performs the actual test. After completion of the test, the firmware sends the result back over UART. To enable the test equipment to connect to the UART, a needle bed was created that connects to the UART pads of the PCB.
The needles are provided with springs such that PCBs carefully connect to the needle bed. Furthermore, the needle bed provides security against damaging the PCB, and keep the PCB in place.
This needle bed is then connected to a Janztec, an industrialized Raspberry Pi, which manages all tests.
The application developed, to manage the tests, was written in python. To guide the operator, who connects the PCB and starts the tests, a GUI was created with the dialog library, which is similar to ncurses in C. This library provides the possibility to create text-terminal like GUIs such as the Buildroot menus. The reason that this kind of GUI is used is that it’s very straight forward and easy to use for the testers.
An example menu can be seen in following image.
In the end the developed test cycles are executed 3 times during the complete production process. This to have fast feedback if a component should malfunction. The results of each test cycle are stored in a Redis database and can be exported as pdf or csv.
The complete setup then looks like this:
Project challenges
The main challenges encountered regarded the design of the needle bed. The pads on the target PCBs were not designed to follow a standard format, which caused some difficulties to design the needle bed.
First approach
The first approach was to solder the needles directly on the 3D-printed model. A couple of issues where encountered with this approach.
- The needles are very small
- Difficult to align the needles perfectly with the pads on the PCB
- The heat of the soldering could melt the tooling
Solution to challenges
In the final solution, a copy of the PCB was made and all paths and components stripped. Because the pads were still present on the PCB, the needles could be attached by metallization on the copied PCB. By doing this, the needles are immediately in the correct position to connect to the PCB to test. This solution only requires the PCB stand to be 3D-printed.
Key facts and figures
- 1 test cycle takes 5-7 minutes
- In total 3 test cycles are performed at different phases of production
- First order was for 1000 PCBs