Circuit Breaker Panel Tester
Watch this project on GitHub
What is the purpose?
The tool is designed to take quick connectivity measurements within vast amounts of pins. By saying "vast" I mean 320 in the recent implementation, but that is not a limit.
This connections tester is made of plug-in IO boards, each of which carries 32 pins on it and communicates with a master board via I2C bus, so theoretically, this system may be extended to up to 126 boards, or 126 x 32 = 4032 pins (though I2C bus will be a limit here, wheres 10 boards simultaneously connected to one master board caused the need to shorten the connection cables).
System Diagram
User interface
The user interface mainly consists of the phone application and the .xlsx (Excel) file. Let's focus on the latter one for now.
Xlsx Interface
The purpose of the .xlsx file is to allow the user to:
- Configure the pinout.
- Configure expected results
- Display measurements results
- Display the difference between expected and measured connections
Overall structure:
1. Configuration of pinout
Each IO board has 32 pins on it, the board itself is referenced via its i2c address. When the number of pins grows, it becomes cumbersome to manage all that data, that comes from the measurements, if the pins are not given meaningful names. To address this problem, the "Description" tab is available for the user.
To configure the pinout, the user should create a table similar to that shown below. I have not mentioned this yet, but the user may group these pins into logical groups, e.g. if we have a physical connector on the target device with 40 pins we may take the first 32 from the board with address 1, and the rest 8 from the board with address 2 and group them into some group named "Connector A", so the user will have a more intuitive view into the measurements results.
2. Expected results
The user should provide the expected results if the function of difference search is needed. On the tab "ExpectedResults" expected results are inserted in a simple format:
If the pinout descriptor is given, the user may refer to the pin via its group and assigned id:
GROUP_NAME:PIN_ID -> GROUP_NAME_WANTED:PIN_ID_WANTED(RESISTANCE)
where GROUP_NAME and PIN_ID are the group and pin id of the base pin and GROUP_NAME_WANTED and PIN_ID_WANTED are the group and pin id of the target pin (the pin, with which the connection is expected). The RESISTANCE parameter is optional and may be used to specify the exact resistance that should be measured on that connection. This function is not fully implemented yet.
3. Measurements results
Every time the user pushes "Save" button on the phone, the "Measurements" tab is populated with the data currently available on the phone. Here all the measurements are available for inspection. Pins are divided into columns, each column is given its group of pins, so they are logically separated.
The format used here is similar to the one discussed in the previous paragraph and that is a big feature. Because of the number of connections, the creation of the table of expected results may be cumbersome and error-prone. The user may choose an approach when he is given a fully functional device and use it as a template or standard. For this, the pin descriptor is created as usual, defining the affinity of pins and separating them into logical groups, then, just after that, the measurements are made. Now we have a list of connections inside of the fully functional device, similar to that we want to test. By simply Ctrl-C Ctrl-V of this list into the "ExpectedResults" tab we create a list of expected results. Now we connect our device of unknown state and measure its connections, by leveraging the "ExpectedResults", populated with data from measurements from the fully functional device, we are able to observe the differences between expected and actual connections state.
4. Differences
On the "Differences" tab, we may observe the state of connections compared to the reference given in "ExpectedResults" tab. The connection difference may be caused by the lack of some connections or by the presence of unwanted ones. The image above shows these two types of discrepancies. Additionally, if the pin was not given any expected connection, then, the "not checked" text is placed in the corresponding cell, this feature is intended to diminish the chance for the user to forget to place expected results for pins he wants to check.
