Years ago, I was a technical support manager for a company that manufactured modular test and measurement equipment. While our support team successfully resolved most issues over the phone, there were instances where the troubleshooting task list was exhausted, and a return to the factory for diagnosis and repair was the only option left. The likelihood of a successful diagnosis and repair was highly correlated with the detail included in our customers' failure reports. The more detailed the report, the higher the probability that we could:
- Repeat the failure
- Identify the root cause
- Repair
- Return a working unit to our customer’s satisfaction.
But when a product was returned to us with no or limited failure data, it created guesswork for our technicians, making it difficult for them to identify the reason for the return.
A Returned Product That Leads to a Guessing Game
We would often receive a system self-test failure report without meaningful data relating to the returned module. In these instances, and when there was no ability to contact the end-user to get more failure detail, the best we could do was run the returned unit through our production test and hoped we could find a failure. Any failure. If the returned unit failed our test, we assumed that was the reason for the return, then repaired it and sent it back. That was the best-case scenario, and even then, we weren’t certain that we had duplicated the symptom the customer was experiencing. The least desirable outcome was when the returned unit passed our production test. We didn’t just want to immediately ship it back to the customer as a No-Fault-Found mainly because it was understood that some due diligence took place before the unit was shipped back to us. Attempts would be made to get more detail about the failure (were there specific conditions that were required to duplicate the failure)? This was a time-consuming process that could delay getting the unit back into the customer’s hands.
The improperly diagnosed and No-Fault-Found scenarios are the scourge of any manufacturing company. They drive up Mean-Time-To-Repair metrics and often result in frustrated customers who receive ‘repaired’ product that still does not function properly. It’s a drain on resources, sucking in multiple levels of an organization, from procurement, shipping, receiving, engineering and production, while exhausting logistics budgets.
A False Repair
At Pickering, we know all too well about end-users challenges when a test system failure has taken down their production line. The heat is on the test support engineer to get that system back online to turn the product into revenue. Our PXI switching modules are used at the heart of many automated test systems and provide the connection paths between test instrumentation and the product under test. Because the switch modules are used throughout the test process and have mechanical relays that are subject to wear and failure, they are often identified as a prime suspect causing the failure. Simply swapping in a spare module may resolve a system failure, and the suspect unit can then be sent off for repair with a system self-test failure report attached. But was it really the module that was at fault, or was it a bad connection somewhere in the system that was corrected during the module swap? Was a faulty relay identified, and if so, can the symptoms be described in detail? There are just too many variables when fixing a signal routing path failure that can potentially result in a repair process that seems like it has no end.
Check out our other blog post if you'd like more information about relays: Relay 101: The Different Types of Relays and How they Operate
The Built-in Solution for a Speedy Recovery
The good news is we’ve developed a solution for this challenge; an automated utility that can be used to quickly test switch modules that are suspected as failing, in isolation from all other system components (such as system wiring and interconnects). eBIRST is an automated built-in test utility consisting of an adapter connecting to our switch modules with a graphical software interface to execute a relay self-test script. The script exercises each relay on the switch module and checks for proper operation, looking for relays that may be welded shut, stuck open or have contact resistance that is out of specification.
Image: eBIRST diagram.
Learn more about our diagnostic test tools here
The eBIRST test doesn’t just stop at the relays; problems in the path, such as an open trace or bent pin on the connector, will be flagged as a failure. The graphical nature of the interface is such that it is easy to identify the relay that has failed. But what drives efficiency into the repair cycle is that our customers speak the same ”language” like us. If they return a module for repair and it comes with an eBIRST test report, we will be running the same test at our facility. We will almost certainly be able to repeat what the end-user was experiencing and can quickly repair and return the module with a clean eBIRST report and confidence that the module will now pass in their system. eBIRST is a DC test, and the adapter can source a limited amount of current, so it is only valid for modules with up to 2 Amp relays. Still, it is a diagnosis tool that can be run in the field to ensure there really is a fault with the module before returning it for repair.
For more information about eBIRST diagnostic test tools and how they can make your troubleshooting process much more efficient, please visit our eBirst webpage.
Image: eBIRST test report identifying a failed relay and its location on the PCB. Pickering customers can repair a PXI switch module on-site without voiding their warranty.
Are you looking for additional resources on this topic? Check out this video: What are eBirst Switching System Test Tools?
