TestStand - Prüfschritt zur Steuerung eines Multifunktionsprüfsystems für die Elektronikfertigung

Author(s):
Dipl.-Ing. (FH) Jürgen Dodek - MTU Friedrichshafen GmbH – Abt. TEE - Elektronik Entwicklung

Industry:
Industrial Controls/ Devices/ Systems, ATE/Instrumentation

Products:
LabWindows/CVI, PXI/CompactPCI, CAN, NI TestStand

The Challenge:
Der folgende Beitrag zeigt die Realisierung eines TestStand-Prüfschrittes, im folgenden StepType genannt, für ein Multifunktionsprüfsystem der MTU - Elektronikfertigung

The Solution:
Die Steuerung aller Geräte erfolgt über einen einzigen TestStand- StepType. Mit diesem lässt sich eine bestimmte Mess- und Stimuliaufgabe realisieren.

Kurzfassung

Der folgende Beitrag zeigt die Realisierung eines TestStand-Prüfschrittes, im folgenden StepType genannt, für ein Multifunktionsprüfsystem der MTU - Elektronikfertigung. Das Prüfsystem besteht aus Mess- und Stimulationsgeräten mit unterschiedlichsten Kommunikations-schnittstellen. Über GPIB werden Spannungs- und Kalibrierquellen in 19“-Racks angeschlossen. Die Steuerung sämtlicher Relais, Multiplexer und Matrizen erfolgt über SCXI. Multimeter, Counter sowie Signalgeneratoren kommunizieren über PXI.

Die Steuerung aller Geräte erfolgt über einen einzigen TestStand- StepType. Mit diesem lässt sich eine bestimmte Mess- und Stimuliaufgabe realisieren. TestStand dient dazu ein sequenzielles Ablaufprogramm mit beliebig vielen dieser StepTypes zu realisieren.

Einleitung

Die MTU Friedrichshafen GmbH ist einer der führenden Hersteller von schnelllaufenden Dieselmotoren im Leistungsbereich von 20 kW bis 9100 kW. Weiterhin entwickelt und fertigt die MTU elektronische Motormanagement-, sowie Automatisierungs- und Überwachungssysteme für diese Motoren.

Alle produzierten elektronischen Baugruppen und Geräte werden auf Prüfadaptern mit unterschiedlichsten Prüfgeräten geprüft. Die Prüfgeräte sind hauptsächlich oder Eigenentwicklungen. Eigenentwickelt bedeutet hier, dass Mess- und Stimulationsgeräte wie Multimeter oder Spannungsquellen am Markt zugekauft und mit einem Industrie PC zu einem Prüfsystem intergriert werden. Als Entwicklungsumgebung für die Programmerstellung dient TestStand. Bisher wurden zur Programmerstellung ausschließlich die Standard Step Types von TestStand benutzt.

So konnten z.B. beim “NumericLimit” Step-Type Adaptoren wie LabVIEW, CVI und Dll’s benutzt werden. Es wurde dabei meist immer nur auf ein Gerät zugegriffen. Folge war, dass für eine bestimmte Messaufgabe mehrere “Action“, “Statement” und “Wait” Step-Types zuvor aufgerufen sein mussten. Daraus resultierte dass die Programme groß und komplex wurden und eigentlich konnte nur noch derjenige das Programm lesen und editieren der es auch geschrieben hatte.

Bei der Neuentwicklung des Funktionstestsystems NOVA wurde darauf geachtet, die enorme Freiheit die TestStand dem Entwickler eröffnet zu begrenzen. Unter anderem musste eine Lösung gefunden werden, welche es erlaubt die Mess- und Stimuligeräte einfach einzustellen. Resultat war ein Step-Type mit dem sich alle Geräte des Prüfsystems über ein User-Interface Panel graphisch editieren lassen und in der Laufzeitumgebung die Einstellungen automatisch durchläuft.

Hardware

Wie in der Einleitung erwähnt besteht der Funktionstester NOVA aus mehreren Geräten mit unterschiedlichen Kommunikationsschnittstellen. Alle Komponenten befinden sich in einem mobilen 19“-Prüfturm. Das Prüfgerät besteht im Wesentlichen aus:

Standard Industrie-PC mit:

            PCI/PXI-Bridge, USBtoGPIB, CAN, RS422

12 Slot PXI Chassis mit

            NI-PXI/PCI Bridge

            NI-PXI 5401 (Funktionsgenerator)

            NI-PXI 6624 (Counter)

            NI-PXI 6704  (Analog Output)

            NI-PXI 6224 (Analog Input)

            NI-PXI 4072 (DMM)

12 Slot SCXI Chassis mit:

            4 x NI-SCXI 1129 (Matrix)

            2 x NI-SCXI 1130 (Multiplexer)

            3 x NI-SCXI 1169 (SPDT Relais)

            3 x NI-SCXI 1166 (General Purpose Relais)

DC-Spannungsquellen:

            Agilent 6700 (N6752A, N6744B, N6743B, N6742A)

            Gossen SSP 1000-52

Sonstiges

            Burster RTD 4530 (Widerstandssimulator)

            Burster 4462 (Kalibierquelle)

Das Herzstück des Funktionstesters ist die PCI/PXI-Bridge. Über sie wird das PXI-Chassis mit dem Industrie PC verbunden. Es wurde bei dieser Entwicklung bewusst auf einen PXI-Controller verzichtet, da keine Echtzeitanforderungen und keine hohen Messdatenraten zu erwarten sind. Im übrigen bietet der Industrie-PC die Standartschnittstellen wie Seriell, Parallel, CAN, Ethernet und USB zu einem besseren Preis/Leitungsverhältnis an. Das PXI Chassis wurde aufgrund seiner hohen Dichte an sehr kompakten Mess und Stimulieinheiten gewählt. Sämtliche Relais befinden sich im SCXI-Chassis, das im Vergleich zu PXI-Relaiskarten eine noch höhere Relaisdichte hat. Gesteuert wird das Chassis über das NI PXI 4072 Multimeter mittels der Aux I/0 Leitung. Sämtliche weiteren Geräte sind über GPIB angeschlossen

Software

Der StepType wurde als Windows Dynamic Linked Library (DLL) entwickelt. Als Programmierentwicklungsumgebung wurde Visual Studio C++ mit MFC Unterstützung gewählt. Die gesamte Bedienoberfläche wurde mit LabWindows/CVI erstellt und anschließend in das Visual Studio Projekt integriert. Dadurch konnte die Mächtigkeit von C++ Objekten und die Einfachheit von CVI Panels und deren Controls gebündelt werden.

Als Gerätetreiberschnittstellenarchitektur wurde IVI benutzt. IVI wurde aus zwei wesentlichen Gründen gewählt:

1. besaßen die meisten der benutzten Geräte schon IVI -fähige Treiber.
2. bietet IVI mehre Möglichkeiten der Simulation. Grundsätzlich haben alle IVI-Treiber intern einen Simulator, der Pseudo- oder Defaultwerte zurück gibt. Eine weitere Option wäre die Verwendung von speziellen Simulationstreibern. Durch die Simulation ist es möglich, den StepType auf Desktop-PCs ohne die vorhandene Hardware auszuführen. Nicht vorhandene IVI-Gerätetreiber wurden mit dem LabWindows/CVI IVI Treiberwizard erstellt.

Die DLL besitzt zwei globale Zugriffsfunktionen - EditStep und PostStep. Bei beiden Funktionsaufrufen muss der TestStand Sequnence-Context übergeben werden. Damit wurde eine Schnittstelle zu Teststand geschaffen, die es erlaubt den Step schon während des Programmierens eines Prüfprogramms im Editor laufenzulassen. Dadurch ist es früh möglich Fehler und Toleranzverschiebungen zu finden oder in der Laufzeitumgebung den StepType graphisch zu „debuggen“.

Realisierung

Die Messartenauswahl des Multimeters erfolgt durch aktivieren des jeweiligen Messartenbuttons (Bild 1 links). Je nach Messauswahl sind die Steuerelemente für den Wertebereich sowie die Auflösung automatisch angepasst. Das Editieren der ScanListe ist einfach. Ein Klick in der Tabelle erzeugt ein Popup-Fenster, in dem der Messkanal, der Messname sowie die Min- und Maxwerte angeben werden können. Über die Buttons Einzel- und Scanmessung kann schon während der Programmerstellung auf das Messsystem zugegriffen und eine Messung bzw. komplette Scanlisten-Messung durchgeführt werden. Das Ergebniss der Messung wird in der Tabelle dokumentiert.

Das Layout der 2-Drahtmatrix (Bild 1 rechts) wurde an die benutzte Virgina Panel Receiverschnittstelle des Prüfgeräts angepasst. Grundsätzlich zwei Pins(+,-) bilden einen Spaltenkanal der Matrix. Über die vier Bus-Toggle-Buttons werden die Zeilen der Matrix bestimmt. Der jeweils Aktive bestimmt den aktuellen Bus. Ein Klick auf einen Spaltenkanal legt die Spalte auf den Bus und umgekehrt. In Bild 1 ist Spalte 9 mit Spalte 19 über Bus 3 verbunden.

Die Ansteuerung der Relais ist selbsterklärend. Es wird immer der Soll-Zustand der Relais angezeigt. Ein Klick auf das Relais lässt es „toggeln“.

Das Panel für die DC-Spannungsversorgung deckt den Grundumfang eines Kanals ab. Hat ein Gerät mehere Kanäle so wird dieses Panel mit der jeweiligen Kanalzahl mehrfach als Childpanel im Gerätepanel implementiert und initialisiert. Wichtig für die Prüfprogrammerstellung ist hierbei die Freischaltung des Kanals (Checkbox überhalb der Kanalnr.). Damit kann der Netzgerätekanal einmalig eingestellt werden und bleibt solange über mehere Steps hinweg erhalten bis erneut eine Freischaltung erfolgt.

Zusammenfassung

Durch die Entwicklung des StepType wurde eine Plattform geschaffen, die es erlaubt, innerhalb einer kleinen Bedienoberfläche sämtliche Funktionen des Mess- und Stimulisystems zu benutzen. Dabei muss der Anwender über keinerlei Programmierkenntnisse in LabVIEW, oder C/C++ verfügen. Desweiteren sind Kenntnisse über sepezielle SCPI-Kommandos mit denen die meisten GPIB-Geräte arbeiten, nicht relevant.

Die Verwendung der IVI-Architektur hat sich bereits zweifach in der Praxis bewährt. Zum einen konnten durch die Verwendung der treiberinternen Simulation bereits viele Teststand “Errors“ z.B. Verwendung einer unbekannten Variable, auf dem Desktop-PC lokalisert und behoben werden. Zum anderen konnte ohne die Software zu veränderen über den Measurement & Automation Exlporer die Verwendung unterschiedlicher physikalischer Schnittstellen eines Gerätes umgeschaltet werden.

Ausblick

Nach Fertigstellung des Prüfgeräts und des StepTypes wurde ein weiteres Prüfgerät entwickelt, welches prinzipiell eine Untermenge des Bestehenden darstellt. Aufgrund der modularen Softwareobjekte wurde mit geringem Zeitaufwand ein zugehöhriger StepType neu erzeugt.

Problem ist, es exitieren nun zwei StepTypes. Langfristiges Ziel sollte es sein, nur einen StepType für unterschiedliche Prüfgeräte zu haben. Der StepType muss während seiner Initalisierung prüfen welche Station TestStand benutzt und sich dementsprechens selbst zusammmenzusetzen.

 

Author Information:
For more information on this Case Study, contact:
Dipl.-Ing. (FH) Jürgen Dodek
MTU Friedrichshafen GmbH – Abt. TEE - Elektronik Entwicklung
Maybachplatz 1
Friedrichshafen 88045
Germany
Tel: +49 7541 90-6138
Fax: +49 7541 90-906138
juergen.dodek@mtu-online.com

Browse All Case Studies »