Now that you know all about matrices, let’s start programming them.
Open this relay, close that one, repeat. Easy, right? Let’s look at the schematic here. Two independent matrices with a single Double Pole Single Throw relay (DPST). The relay allows the user to cascade Y1 and Y2 of MX1 to Y5 and Y6 of MX2. Each matrix can operate independently when the DPST relay is open and work together when the relay is closed. Not super complex, but enough room for error.
Matrices set to open circuit
It's important that you create a flow chart for your test program switching so that the status of each relay is known at any given time in the test program. This is necessary so that you do not get unintended shorts between signal paths or power. In the example below, the programmer is developing test code. They want each matrix to work independently BUT forgot to open the DPST relay closure in a previous test sequence. So then X1 of MX1 would be connected to X11 on MX2, and X2 of MX1 would be connected to X12 of MX2, creating additional loading on the device using these channels.
Matrices programmed for signal connections
In this instance, all that happened was a signal was loaded down, degrading the signal, creating a failed test. But what if you were switching 100 V in a particular XY connection and accidentally left it on so that the matrix routed this 100 V to an analog input rated 5 V max? You could call it “Search and Destroy” testing as the smoke from your 100 V “bomb” would tell you there is a problem. Not a good situation, especially if the DUT that was “destroyed” was crucial to a particular product shipment.
This has been a problem with functional test programming since the beginning. And with some of today’s matrices having over 9,000 cross-points, you can see that it is now a more complex situation at times. Fortunately, switching manufacturers like Pickering Interfaces have developed apps that help minimize the damage and make test development faster.
Several companies have signal routing software that can make the decisions for any switch path decision and alert the programmer if there are any conflicts. One of these programs is Pickering's Switch Path Manager, or SPM, which simplifies signal routing through switching systems and speeds up the development of switching system software. As I said, several vendors create such programs, and they all have advantages and disadvantages.
All of these programs rely on data that describes the switch modules configuration – your vendor of choice should provide this data – and the programmer would describe the interconnections (if any) between multiple switch modules and the name of every test point, also called endpoints. The interconnection effort essentially defines one endpoint to another endpoint in the sequence they should occur. The endpoints should be labeled as inputs or outputs. There should be an option to make connections of endpoints automatically or exclude any particular endpoint.
The software should then calculate all of the paths and errors if the following connections make no sense to the software:
As you can see, this method of programming complex switching is much simpler than defining the path on paper and writing the appropriate code. But one caveat; As you are adding an additional layer of software to your test systems, the performance speed of any routing software should be considered separately. Such systems will always be slower than optimized direct programming, mainly when used in small switching configurations with one or very few switch modules. However, these delays are minor, in the order of milliseconds.
So, if your test system will have complex switching configurations, you may want to evaluate the switch routing software packages available in the industry.
For more information about switching, check out our SwitchMate ebook. If you'd like to learn more about Switch Path Manager, watch this quick video, "Accelerate Software Development of Your Automated Test System"