Homepage » Technology » Applications »

Matrix maintenance in PXI

Efficient way to aid identification of problems
Matrix maintenance in PXI

Switching systems, and in particular matrices are a key part of many tests systems, they allow a single core set of test equipment to be connected to the UUT, saving the cost of duplicating test equipment. That places the switching matrix in a very vulnerable position, the matrix can be subjected to abuse or accidents during development and in use due to programming errors in development, wiring errors or unexpected UUT faults. In this article, we will explore the reasons for concerns, and a way that one manufacturer has found to aid identification of problems in the matrix.

David Owen, Business Development Manager Pickering Interfaces, Clacton on Sea, UK

The relays used in most matrices are mechanical devices and the moving parts, as well as the contact materials, means they have limited life. High quality EMR’s (Electro- mechanical relays) can often have life times quoted of the order of 100 million operations under light load conditions, instrument grade reed relays have lifetimes in excess of 1 billion operations.
Lifetime factors on relays
The practice key factor that affects matrix life in test systems is the conditions under which the relays are operated since impacts the integrity of the contact materials, and for relays which are switches under significant load it is the contact characteristics that primarily determine lifetime. As the relay has to close or open signal connections that have significant voltage or current present, the operation of the relay becomes a “hot switch” event. At the point that the contacts close or open they are carrying a signal that creates mechanical wear, or even generates an arc between the relay contacts, which erodes or stresses the precious metal contact materials. Relay life is strongly influenced by the load present during these hot switch events, a variation of three orders of magnitude is a common change in life time between a light load and a full load. System designers try to avoid hot switching, but the reality is some tests require hot switching of the signals to keep test times low, avoid having to restart systems between tests or to simulate conditions such as intermittent faults or changing connectivity. Hot switching is a compromise that designers have to manage in their test systems. Hot switch events are also accidentally introduced when the loads significant capacitive or inductive content when high inrush currents or high back EMF voltages are generated.
Even so many failures in test systems are not caused by the relays reaching their normal end of life. A few are due to infant mortality caused by manufacturing defects that are not initially detectable; many more though are caused by accidental events that occur in the system. A common source of accidental events is the integration of the test system – cabling and software errors can accidentally connect parts together that were never intended to be connected, for example shorts on power supplies or accidental hot switch events into capacitive loads. The relay may withstand these accidents, but the relay could have partial damage to its contacts which will shorten its operational life as the system is used and ages. Even when the system is operating correctly an attempt to test a faulty UUT can stress the switching system, forcing operation beyond the specification for the relays.
Fault diagnostics
The vulnerability of the switching system has resulted in users requiring a system check that includes a way of testing the switching system. Some platforms, such as VXI, have historically offered a self test facility for the relays. The degree of coverage such a self test gives though is patchy, sometimes it simply tests the control system and not the relay contacts (the most likely part to fail), some products test the relay contacts but are unable to test isolation relays. VXI products have included this capability because the prime customers (usually military or aerospace) have demanded it and there is enough room in the product to allocate space to self test hardware. Smaller footprint products, such as PXI, have not provided self test. The burden on the design to include self test has been high in terms of space, which reduces the density that can be achieved in the module and increases cost. For these lower cost and space constrained products vendors have added perhaps one of the most misguided tools as a way of managing the issue – relay operation counting. In relay counting the software counts how many times a relay has been operated, the intent then to be to replace the relay when the number of operations reaches some threshold. As a tool this method is deeply flawed for a number of reasons:
  • Relay life changes by three orders of magnitude according to the load present. The software has little or more commonly no knowledge of the load, it is simply a counting system
  • It takes no account of the accidents that happen in systems, such as UUT failures, that shorten relay life
  • Real relays are subject to significant variations by batch in their life, the data sheet estimates should reflect the worst batches rather than the best batches.
The consequence of this is that real switching systems can have a much shorter or a much longer life than a relay operation counting system will indicate, and the error bands are measured in orders of magnitude rather than a few percentage points. The situation gets worse if the user then performs maintenance based on relay operation counting. Modern devices always work better and for longer the fewer the number of rework operations that are carried out on the assembly there are. Early “preventative” replacements risk disturbance of other parts and damage to tracks, particularly in the case of surface mount parts. There is much to be said for a philosophy that says “if it’s working leave it alone until you have good reason to suspect it is going to or has a problem”.
System level test
System integrators often include a degree of self test at the system level where the switching system is used to route signals back so a self test can be performed, for example by using a DMM to measure different paths. The investment required to do this can be quite high, and the more complex the system the harder self test gets. The integrator has to understand the way the system routing is performed both at the cable interface level and within the switching parts themselves. Such self test routines will certainly identify most gross faults in the connectivity, but they do not find intermittent paths easily or isolate where the fault is – for example which relay in the switching system or whether the fault is a relay or cable.
Built in self test
The status on self test though is changing. Pickering Interfaces has now launched the first of a new generation of matrix solutions in PXI which includes a built in self test facility, called BIRST or Built In Relay Self Test. BIRST is implemented as a very compact hardware addition to the PXI modules that allows the supplied software to explore a matrix switch, measuring each path in the matrix for path resistance with a repeatability measured in a few milliohms. Every relay is checked for its operation so welded closed and open relays can be quickly found, the high resolution of the measuring hardware is capable of identifying variable contacts. The location of individual faulty relays is quickly identified, in most cases without ambiguity or to within a very few devices. All the user needs to do is to disconnect the PXI module from the test system and then run the supplied program. The test process is fast, each relay requiring just a few 10’s of milliseconds to fully test. The software then displays the test results as a graphical representation of the matrix, highlighting the relays that are faulty and allowing the user to quickly identify the physical position of the faulty device within the PXI module. The use of thru hole relay components allows users to simply service the module with commonly available tools and get the module back in service after running BIRST again to check that all faults have been cleared. The tool addresses the shortcomings of the older self test systems and the relay counting methods. It allows users to get the maximum out their relays and the modules that contain them with little additional investment, it only identifies those relays which need attention for maintenance and avoids unnecessary disturbance and system downtime. The tool can identify relays with higher than expected path resistance, allowing users to change those relays before they fail. It also compliments system level tools. When running diagnostic tests the system level tools can concentrate on the testing of the cable interfaces and switching systems without BIRST, leaving exploration of the BIRST enabled matrices to the tool.
The technology is being included in a new generation of Pickering Interfaces BRIC matrix solutions. These matrices feature crosspoint counts – up to 4406 – in a compact PXI module. The upgraded BRIC modules are identified as having an “A” suffix in their part number and the majority of the current BRIC solutions will support the tool in the future. There is no impact on the cost of these solutions – and old versions of the BRIC’s will remain available for those requiring legacy support. In addition a new range of EMR matrix solutions are being introduced which have a BIRST capability offering single slot PXI matrix modules. The range of modules with BIRST support will continue to expand, marking a major improvement in the capabilities of PXI matrix solutions and improving their market acceptance in critical test applications.
productronica, A1.433

ZUSAMMENFASSUNG
Schaltmodule, insbesondere Matrizen, sind ein wichtiger Bestandteil in vielen Testsystemen. Doch ist zu bedenken, dass bereits in der Entwicklung und auch im Einsatz viele Fehler entstehen können. Dieser Artikel diskutiert die Gründe dafür und stellt eine Lösung vor, Probleme in der Matrix frühzeitig zu identifizieren.
Les modules de commutation, en particulier les matrices, sont un élément important dans de nombreux systèmes de contrôle. Mais il ne faut pas oublier que de nombreuses erreurs peuvent survenir dès la conception, mais également en cours d’utilisation. Cet article discute les causes de ces erreurs et présente des solutions permettant d’identifier précocement les problèmes survenant dans les matrices.
Current Issue
Titelbild EPP EUROPE Electronics Production and Test 11
Issue
11.2024
READ
Newsletter

Subscribe to our newsletter now

Webinars & Webcasts

First hand technical knowledge

Whitepapers

Find all current Whitepapers here

Videos

Find all current videos here


Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de