Verbesserung der TestStand-Systemleistung

Die verschiedenen Konfigurationsoptionen von TestStand wirken sich unterschiedlich auf die Leistung aus. In den folgenden Abschnitten werden diese Optionen beschrieben.

• Sequenzverfolgung
• Optionen für die richtige Balance zwischen Ausführungsgeschwindigkeit und Speicherauslastung

Sequenzverfolgung

Die Sequenzverfolgung liefert sofortiges Feedback und den Status des aktuellen Vorgangs, z. B. „Pass“ (Erfolgreich), „Fail“ (Fehlgeschlagen), „Error“ (Fehler) oder „Skipped“ (Übersprungen). Die Sequenzverfolgung wirkt sich jedoch auf die Leistung aus, weil die Ausführungsgeschwindigkeit verringert wird. Mit den folgenden Herangehensweisen können Sie die Ausführungsgeschwindigkeit erhöhen, ohne die Vorteile der Sequenzverfolgung zu beeinträchtigen.

Um die Leistung bei aktivierter Sequenzverfolgung zu verbessern, legen Sie eine hohe Verfolgungsgeschwindigkeit fest, damit es zwischen den Schritten nicht zu einer zusätzlichen Verzögerung kommt. Auf der Registerkarte „Execution“ (Ausführung) des Dialogfelds „Station Options“ (Stationsoptionen) können Sie die Ablaufverfolgung konfigurieren. Klicken Sie dazu auf Configure » Station Options (Konfigurieren » Stationsoptionen).

Selbst bei der schnellsten Einstellung erhöht die Ablaufverfolgung den Aufwand um einige Millisekunden pro Schritt, weil das Fenster „Execution View“ (Ausführungsansicht) nach jedem Schritt aktualisiert wird. Wenn Sie die Ablaufverfolgung vollständig deaktivieren, erzielen Sie die höchste Leistung. In diesem Fall wird das Fenster „Execution View“ (Ausführungsansicht) bei der Ausführung der Sequenz nicht aktualisiert.

Mit der Eigenschaft Sequence Call Trace Setting (Einstellung für Sequenzaufruf-Ablaufverfolgung) deaktivieren Sie die Ablaufverfolgung in bestimmten Untersequenzen und schaffen einen Ausgleich zwischen der Leistung und den Vorteilen der Ablaufverfolgung im Hinblick auf die Benutzerfreundlichkeit.  Wenn Sie so vorgehen wollen, unterteilen Sie Ihre Tests in logische Gruppen und erstellen Sie für diese Gruppen jeweils Untersequenzen.  Beispielsweise können in einer Testsequenz für ein Mobilgerät Tests für die einzelnen Komponenten – Daten der Funkzelle, Benutzereingaben und Audiosysteme – in separaten Sequenzen implementiert werden. Deaktivieren Sie für den SequenceCall-Schritt jeder Komponente die Ablaufverfolgung innerhalb des Sequenzaufrufs.

1. Wählen Sie Properties » Run Options (Eigenschaften » Ausführungsoptionen).
2. Legen Sie für die Eigenschaft „Sequence Call Trace Setting“ (Einstellung für Sequenzaufruf-Ablaufverfolgung) die Einstellung Disable tracing in sequence (Ablaufverfolgung in Sequenz deaktivieren) fest.

Wenn Sie die Testsequenz auf diese Weise organisieren, können Sie die Sequenzverfolgung für die Sequenz der obersten Ebene nutzen, ohne den Leistungs-Overhead für die Verfolgung jedes Teilschritts in Kauf nehmen zu müssen. Diese Herangehensweise lässt sich auch leicht an parallele Tests anpassen, da jede Untersequenz asynchron aufgerufen werden kann. Weitere Informationen zum Parallelisieren Ihrer Testsequenz finden Sie im Abschnitt Improving Test Performance through Parallel Testing (Verbessern der Testleistung durch paralleles Testen).

Mit Sequenzaufrufschritten bei deaktivierter Ablaufverfolgung verbessern Sie die Leistung und sehen den Ausführungsstatus.

Optionen für die richtige Balance zwischen Ausführungsgeschwindigkeit und Speicherauslastung

Mit TestStand können Sie konfigurieren, wann Codemodule in den Speicher geladen und aus diesem entfernt werden. Dies kann erhebliche Auswirkungen auf die Speicherauslastung und die Ausführungsgeschwindigkeit einer Testsequenz haben. Wenn Sie Module so konfigurieren, dass sie länger im Speicher bleiben, verkürzt sich die Ausführungsdauer, da die Module bei der Ausführung von Untersequenzen nicht neu geladen werden müssen.  Wenn jedoch zu viele Module im Speicher verbleiben, kommt es unter Umständen zur Überschreitung der Anwendungsspeichergrenzen oder des verfügbaren physischen Speichers, was auch die Ausführung verlangsamen kann.

Im Idealfall können Sie Verbesserungen an Ihrem Testsystem vornehmen, damit die Speicherbeschränkungen weniger restriktiv ausfallen, anstatt Speicherplatz über das Entfernen von Codemodulen freizugeben. Zum Beispiel:

• Einsatz der 64-Bit-Version von TestStand, da hierbei weniger restriktive Beschränkungen des Anwendungsspeichers gelten. Weitere Informationen zum Beheben von Speicherproblemen unter Nutzung der 64-Bit-Version von TestStand finden Sie im Hilfethema Choosing between 32-bit TestStand and 64-bit TestStand (Die 32- und die 64-Bit-Version von TestStand im Vergleich).  
• Erweiterung des physischen Speichers von Testsystemen.
• Verbesserung der Leistung des virtuellen Speichers durch den Einsatz von Solid-State-Festplatten.

Wenn die Speichernutzung weiterhin ein Problem darstellt, können Sie die Optionen zum Laden bzw. Entfernen auf Schritt- oder Sequenzdateiebene festlegen. In den meisten Testsystemen können Sie die Option Preload when opening sequence file (Vorab-Ladevorgang beim Öffnen der Sequenzdatei) oder Preload when execution begins (Vorab-Ladevorgang bei Beginn der Ausführung) mit der Option Unload when sequence file is closed (Beim Schließen der Sequenzdatei entfernen) kombinieren, um eine optimale Leistung zu erzielen.  

Dateiformat

Das Dateiformat kann sich auf die Geschwindigkeit und Leistung beim Laden großer Sequenzdateien auswirken. Mit TestStand können Sie Sequenzen in den folgenden Dateiformaten speichern: INI, XML und Binärformat.  

• Verwenden Sie das XML-Format nur, wenn die Datei in Anwendungen ohne Zugriff auf die TestStand-Engine angezeigt werden muss, z. B. mit dem Sequence File Viewer-Tool oder einem anderen benutzerdefinierten Anzeigeprogramm.
• Verwenden Sie das INI-Format nur, wenn die Sequenzdatei mit TestStand bis Version 3.x kompatibel sein muss.
• Wenn keiner der oben genannten Punkte zutrifft, empfiehlt sich das Binärformat, da es die schnellsten Ladezeiten bietet.  

So legen Sie fest, welches Format für neue Sequenzdateien verwendet werden soll:  

1. Wählen Sie Configure » Station Options (Konfigurieren » Stationsoptionen).
2. Klicken Sie auf der Registerkarte File (Datei) auf die Schaltfläche File Format Options (Dateiformatoptionen).  

So ändern Sie das Format einer vorhandenen Sequenzdatei:

1. Wählen Sie Edit » Sequence File Properties (Bearbeiten » Eigenschaften der Sequenzdatei). 
2. Wählen Sie die Option File Format (Dateiformat) auf der Registerkarte General (Allgemein).
3. Wählen Sie unter File Format for New Files (Dateiformat für neue Dateien) das gewünschte Format aus.

Im Binärdateiformat können Sequenzdateien am schnellsten geladen werden.

Konfiguration der Suchverzeichnisse

Die Konfiguration der Suchverzeichnisse wirkt sich direkt auf die zum Laden von Sequenzdateien und Codemodulen erforderliche Zeit aus, wenn diese mit relativen Pfaden angegeben werden. Die Konfiguration der Suchverzeichnisse wirkt sich auf die Leistung beim ersten Laden und Ausführen der Tests sowie auf nachfolgende Iterationen aus, wenn Module dynamisch geladen werden. Im Dialogfeld für die Konfiguration des Suchverzeichnisses können Sie die Suchverzeichnisse anzeigen und bearbeiten. Mit der Option Configure » Search Directories (Konfigurieren » Suchverzeichnisse) öffnen Sie das Dialogfeld Edit Search Directories (Suchverzeichnisse bearbeiten). 

Beim Auflösen des relativen Pfads eines Codemoduls geht TestStand wie folgt vor:

1. Der Codemodulpfad wird an den Pfad des ersten Suchverzeichnisses angehängt.
   
2. Es wird geprüft, ob der absolute Dateipfad auf der Festplatte vorhanden ist.

• Falls ja, wird der Pfad aufgelöst.
• Falls nein, wird ins nächste Verzeichnis gewechselt.

TestStand überprüft die Liste der Suchverzeichnisse, um einen relativen Pfad zu einer Codemoduldatei aufzulösen.

Da für jedes Suchverzeichnis nur ein einziger Pfad berechnet wird, wirkt sich dieser Prozess normalerweise nicht deutlich auf die Leistung aus.  

Wenn ein Suchverzeichnis jedoch die Option „Search Subdirectories“ (Unterverzeichnisse durchsuchen) aufweist, wird der Vorgang für jedes Unterverzeichnis innerhalb des angegebenen Pfads wiederholt.  Bei einer großen Verzeichnishierarchie im Pfad kann diese Option die Leistung erheblich beeinträchtigen.  Wenn darüber hinaus in der Hierarchie mehrere Dateien mit demselben Namen vorhanden sind, kann es vorkommen, dass die falsche Datei geladen wird. Vermeiden Sie daher die Verwendung dieser Option für Suchverzeichnisse, die Sie hinzufügen.  Sorgen Sie stattdessen dafür, dass alle Codemodulpfade unter Verwendung eines relativen Pfads zum Basissuchverzeichnis angegeben werden.

Beachten Sie die folgenden Richtlinien, um die Reihenfolge der Suchverzeichnisse weiter zu optimieren:

• Platzieren Sie Verzeichnisse mit den meisten Codemodulen oben in der Liste und weniger häufig verwendete Verzeichnisse weiter unten.
• Platzieren Sie Verzeichnisse auf Netzwerklaufwerken weiter unten in der Liste, da der Netzwerkzugriff langsamer ist als der Zugriff auf die lokale Festplatte.
• Wenn Sie die Option „Search Subdirectories“ (Unterverzeichnisse durchsuchen) nicht vermeiden können, platzieren Sie diese Verzeichnisse ganz unten in der Liste als Auffanglösung.   

Ziehen Sie beim Entwerfen der Verzeichnisstruktur für das Testsystem in Betracht, Codemodule in einem Verzeichnis unterhalb des Sequenzdateipfads oder an einem konkreten Codemodulspeicherort zu speichern.   

• Durch die Verwendung von Pfaden relativ zur Sequenzdatei gibt der erste Suchpfad (das Verzeichnis der aktuellen Sequenzdatei) immer die richtige Datei zurück. Zusätzliche Suchvorgänge sind nicht erforderlich. Auf diese Weise können Sie auch den gesamten Ordner an einen anderen Speicherort oder Computer verschieben, ohne die Suchverzeichnisse ändern zu müssen. Beachten Sie diese Herangehensweise bei Codemodulen, die nur von einer einzelnen Sequenzdatei oder einer Reihe verwandter Sequenzdateien genutzt werden.
• Durch die Beschränkung auf einen konkreten Codemodulspeicherort können Sie auf einfache Weise auf Codemodule aus verschiedenen Sequenzdateien verweisen, indem Sie den Speicherort zur Liste der Suchverzeichnisse hinzufügen.  Beachten Sie diese Herangehensweise bei Codemodulen, die von vielen Sequenzdateien gemeinsam genutzt werden.

TestStand kann zur Ausführung von Testschritten Codemodule in verschiedenen Entwicklungsumgebungen aufrufen. Die Konfiguration dieser Codemodule und Entwicklungsumgebungen kann sich erheblich auf die Leistung auswirken.  In jeder Codemodulumgebung können Sie eine bessere Leistung erzielen, indem Sie nur die erforderlichen Daten an ein Codemodul weitergeben und von dort abrufen. Vermeiden Sie die Weitergabe großer Datenmengen, auf die das Codemodul nicht zugreift bzw. die nicht geändert werden.

Kompilierte Codemodule (DLLs)

Kompilierte Codemodule wie .NET-Assemblys oder C-/C ++-DLLs können die Leistung verringern, wenn Sie eine Debug-Version der DLL anstelle einer Release-Version verwenden. In der Regel nutzen Entwickler in der Entwicklung Debug-DLLs, um Probleme in den Modulen leichter zu finden und zu lösen. Sobald die Testsequenz für die Verteilung bereit ist, erfolgt der Wechsel zu Release-DLLs, die eine bessere Leistung bieten.  

LabVIEW-Codemodule

Da LabVIEW-VIs direkt ausgeführt werden, können sie entweder in der LabVIEW-Entwicklungsumgebung oder in der LabVIEW Runtime Engine ausgeführt werden.  Wenn Sie LabVIEW-VIs in der Entwicklungsumgebung ausführen, können Sie mithilfe von Debugging-Funktionen Probleme mit Codemodulen lösen. Die Ausführungsgeschwindigkeit ist in diesem Fall jedoch geringer.  Verwenden Sie bei Produktionstests die LabVIEW Runtime-Engine zum Aufrufen von VIs. Über das LabVIEW-Dialogfeld „Adapter“ können Sie konfigurieren, auf welchem LabVIEW-Server LabVIEW-Code ausgeführt wird:

1. Wählen Sie Configure » Adapters (Konfigurieren » Adapter).
2. Wählen Sie den LabVIEW-Adapter aus und klicken Sie auf Configure (Konfigurieren).
3. Wählen Sie die LabVIEW-Runtime-Engine oder das LabVIEW-Entwicklungssystem aus.

Um die Ladezeiten für LabVIEW-Code weiter zu optimieren, können Sie Ihre Codemodul-VIs in Packed Project Libraries (PPLs) integrieren.  Da PPLs kompilierte Versionen aller VI-Abhängigkeiten von Codemodul-VIs enthalten, kann LabVIEW die Abhängigkeiten schneller in den Speicher laden.  Wenn Sie Ihren Code mithilfe des TestStand-Verteilungs-Utility bereitstellen, können alternativ im Rahmen des Verteilungsprozesses PPLs für Ihre VIs erzeugt werden.

Weitere Informationen zur Verwendung von PPLs mit dem TestStand-Verteilungs-Utility finden Sie im Hilfethema Organizing Test Program Files with LabVIEW Packed Project Libraries (Organisieren von Testprogrammdateien mit LabVIEW-PPLs).

Sie können die Testgeschwindigkeit meist steigern, indem Sie mehrere Tests gleichzeitig durchführen.  TestStand bietet Funktionen, mit denen Sie das Testen eines einzelnen Prüflings parallelisieren oder mehrere Prüflinge gleichzeitig testen können.   

Parallelisieren einer Testsequenz

Beim Test eines einzelnen Prüflings können Sie möglicherweise mehrere Teile des Systems gleichzeitig testen.  Betrachten Sie beispielsweise die Testsequenz für ein Mobilgerät. Tests für die einzelnen Komponenten – Daten der Funkzelle, Benutzereingaben und Audiosysteme – können in separaten Untersequenzen implementiert werden. Anstatt die einzelnen Sequenzen nacheinander aufzurufen, können Sie den Test beschleunigen, indem Sie den Sequenzaufruf so konfigurieren, dass die Sequenzen asynchron aufgerufen werden.

So legen Sie fest, dass ein Sequenzaufruf asynchron ausgeführt werden soll:

1. Wählen Sie einen Sequenzaufruf-Schritt aus und klicken Sie auf die Registerkarte Module (Modul).
2. Wählen Sie im Menü Execution Options (Ausführungsoptionen) die Option Use New Thread (Neuen Thread verwenden) oder Use New Execution (Neue Ausführung verwenden).

Wenn Sie eine Sequenz in einem neuen Thread aufrufen, können Sie verschiedene Teile eines Prüflings gleichzeitig testen.

Beachten Sie beim Konfigurieren von asynchronen Sequenzaufrufen die Unterschiede zwischen der Verwendung eines neuen Threads und einer neuen Ausführung:

In der Regel sollten Sie die neue Thread-Option für verwandte Tests innerhalb einer Testsequenz verwenden.  Eine neue Ausführung eignet sich besser für unabhängigere Funktionen, z. B. einen Statusmonitor, der unabhängig von der Testsequenz ausgeführt werden sollte.

Weitere Informationen zur Frage, ob ein neuer Thread oder eine neue Ausführung verwendet werden soll, finden Sie unter When to Run a Sequence in a New Execution versus in a New Thread (Wann eine Sequenz in einer neuen Ausführung und wann in einem neuen Thread ausgeführt werden sollte).

Abrufen von Ergebnissen asynchroner Sequenzaufrufe

Um die Ergebnisse der asynchronen Untersequenzen für das Reporting oder die Datenbankprotokollierung abzurufen, nutzen Sie die Warteschritte am Ende der Startsequenz, um auf den Abschluss der asynchronen Sequenzaufrufe zu warten. Sobald der Untersequenz-Thread abgeschlossen ist, hängt TestStand die Ergebnisse der asynchronen Untersequenz an die Ergebnisse der Warteschritte an und stellt sie für das Reporting und die Datenbankprotokollierung zur Verfügung. Um auf eine Sequenzausführung oder einen Thread zu warten, wählen Sie Execution (Ausführung) oder Thread unter Wait (Warten), um festzulegen, auf welche Ausführung bzw. auf welchen Thread Sie warten.  Beachten Sie, dass die zusätzliche Wartezeit zu einer Verzögerung der Ausführung führen kann, wenn die aufrufende Sequenz vor dem Thread abgeschlossen ist. Gehen Sie also nur auf diese Weise vor, wenn Sie die Ergebnisse des neuen Threads benötigen.

Rufen Sie mithilfe eines Warteschritts die Ergebnisse eines asynchronen Sequenzaufrufs ab.

Testen mehrerer Prüflinge gleichzeitig

TestStand verwendet nicht nur asynchrone Aufrufe in der Testsequenz, sondern ermöglicht es Ihnen auch, mehrere Prüflinge mithilfe der Parallel- und Stapelprozessmodelle gleichzeitig zu testen.  Bei diesen Prozessmodellen wird die Testsequenz in mehreren Ausführungen jeweils auf einem separaten Prüfling ausgeführt.  Sie können das Prozessmodell für die aktuelle Station oder für eine einzelne Testsequenzdatei ändern.

Mehrere Prüflinge gleichzeitig mit den Parallel- und Stapelprozessmodellen testen

Wie paralleles Testen die Testdauer reduzieren kann, finden Sie in der Parallel Test Strategies Demo (Demo zu parallelen Teststrategien), die in TestStand enthalten ist.

Auswahl zwischen dem Parallel- oder Stapelprozessmodell

Während das Parallelprozessmodell das Starten und Beenden der Tests von Prüflingen zu unterschiedlichen Zeiten ermöglicht, ist das Stapelprozessmodell so konzipiert, dass die Testsequenz auf allen Prüflingen gleichzeitig gestartet und beendet wird.  

• Das Parallelprozessmodell ist ideal zum Testen mehrerer Prüflinge mit separaten Prüfvorrichtungen, wobei jeder Prüfling unabhängig getestet wird.   
• Das Stapelprozessmodell eignet sich ideal zum Testen von Prüflingen, die als Gruppe mit einer gemeinsamen Prüfvorrichtung oder in einer gemeinsamen Prüfkammer getestet werden, wobei die Prüfung für alle Prüflinge synchronisiert werden muss.

 Zusätzlich zum gleichzeitigen Starten und Beenden jedes Stapeltests können Sie beim Stapelprozessmodell mit Stapelsynchronisierungsschritten und -einstellungen das Testen von Prüflingen im Stapel weiter synchronisieren. Wenn bestimmte Teile des Tests für alle Prüflinge gleichzeitig ausgeführt werden sollen, können Sie synchronisierte Abschnitte für einen einzelnen Schritt mithilfe der Schritteinstellungen definieren. Für mehrere Schritte benötigen Sie den Schritttyp für Stapelsynchronisierungen.

Sorgen Sie mit einer Stapelsynchronisierung dafür, dass bestimmte Teile des Tests für alle Prüflinge im Stapel synchronisiert werden.

Bei allen Arten von Stapelsynchronisierungsabschnitten betreten und verlassen alle Buchsen den Abschnitt gemeinsam.  Sie können die Synchronisierung so konfigurieren, dass sie nacheinander oder nur in einem einzelnen Thread ausgeführt wird.

Weitere Informationen zur Stapelsynchronisierung finden Sie im Beispiel Synchronization Step Types – Batch Synchronization (Synchronisierungsschritttypen – Stapelsynchronisierung).

Überlegungen zur Hardware für parallele Tests

Wenn mehrere Prüflinge gleichzeitig getestet werden, kann die verfügbare Testhardware zu einem Leistungsengpass werden.  Wenn Sie eine gemeinsam genutzte Hardwareressource verwenden, müssen Sie dafür sorgen, dass nie mehrere Threads gleichzeitig auf eine gemeinsam genutzte Hardwareressource zugreifen, damit es nicht zu Ressourcenkonflikten kommt.  In der Regel reservieren Sie über die Sperreinstellungen oder über Schritttypen eine gemeinsam genutzte Ressource.  Wenn jedoch mehrere Threads für den Abschluss eines Tests auf eine einzelne Ressource warten, kann ein Großteil des Verbesserungspotenzials von parallelen Tests nicht realisiert werden.  Damit dies nicht geschieht, können Sie die folgenden Herangehensweisen befolgen:

• Beim Schritttyp „Auto Schedule“ (Automatisch planen) können andere Tests ausgeführt werden, während Sie auf Ressourcen warten.
• Mit der Option „Execution Profiler“ (Ausführungsprofiler) finden Sie die Hardware, die den Engpass verursacht, und können zusätzliche Testhardware hinzufügen.

Automatische Planung

Beim Schritttyp „Auto Schedule“ (Automatisch planen) können Sie eine Reihe von Tests konfigurieren, die in beliebiger Reihenfolge ausgeführt werden können, um die Testzeit und die Hardwareauslastung zu optimieren.  Wenn ein automatisch geplanter Abschnitt unter Verwendung des Parallel- oder Stapelprozessmodells ausgeführt wird, führt jede Buchse den ersten Abschnitt aus, für den keine reservierte Ressource erforderlich ist. Aus diesem Grund kann die Ausführungsreihenfolge zwischen verschiedenen Ausführungen desselben Tests variieren.

Sie können mit der automatischen Planung die Hardwareauslastung optimieren, wenn die Ausführungsreihenfolge nicht wichtig ist.

Befolgen Sie diese Herangehensweise, wenn die Ausführungsreihenfolge von Tests nicht wichtig ist. Nutzen Sie die automatische Planung nicht, wenn für Ihren Test die Testergebnisse in einer bestimmten Reihenfolge dargestellt werden müssen.

Ausführungsprofiler

Das im Lieferumfang von TestStand enthaltene Ausführungsprofiler-Tool hilft bei der Feststellung, welche Testhardware die Ausführungsgeschwindigkeit des Testsystems begrenzt.  Starten Sie den Profiler über den Sequenzeditor mit Tools » Profile Execution (Extras » Profilausführung).

Im Profiler können Sie sehen, wie lange jede Hardwareressource aktiv ist, und fundierte Entscheidungen über die Auswirkungen von zusätzlicher Hardware im Testsystem treffen.  Im Beispielprofil unten ist das DMM vollständig ausgelastet, während der Bereich nur zu 66 % ausgelastet ist.  Auf der Basis dieses Profils würde eine zweites DMM oder ein DMM mit mehr Kanälen die Testdauer für diese Sequenz verkürzen.

Mit dem Ausführungsprofiler können Sie darstellen, welche Ressourcen potenzielle Engpässe in Ihrer Testkonfiguration darstellen.

Sie können die Testdauer verkürzen, indem Sie dafür sorgen, dass die Schnittstelle zur Hardware so effizient wie möglich eingerichtet ist.  In diesem Abschnitt werden Überlegungen zum Verwalten von Hardwarereferenzen und Messtechniken zur Verbesserung der Leistung erörtert.

Optimieren der Messleistung bei Hardware

Bei jeder Hardwarekonfiguration gibt es mehrere allgemeine Faktoren, die die Testeffektivität verringern können. Sie können beispielsweise mit einem Oszilloskop die Anstiegs-, Abfall-, Effektiv- und Spitzenwerte eines Signals messen. Wenn Sie das Oszilloskop so programmieren, dass es die gesamte Wellenform erfasst, die Wellenform an das Testsystem überträgt und dann die Daten nachbearbeitet, um die gewünschten Messungen zu extrahieren, kommt es aufgrund der großen übertragenen Datenmenge zu einer Leistungsminderung. Die Leistung wird auch von der Latenz des Kommunikationsbusses beeinflusst. Sie sollten daher prüfen, ob Ihr Gerät eine hohe Latenz aufweist, z. B. bei einer LAN- oder seriellen Verbindung, oder einen Bus mit niedriger Latenz wie PCI oder PXI nutzt.

Wenn Sie das Oszilloskop so konfigurieren, dass es die Anstiegszeit misst, eine Erfassung auslöst, die Anstiegszeit vom Gerät abruft und dies für jede Messung wiederholt, müssen Sie das Oszilloskop bei jeder Messung neu konfigurieren und erneut triggern. Diese Option ist in der Regel ebenfalls langsam und ineffizient.

Da viele moderne Oszilloskope mehrere Messkanäle haben, können Sie mit den folgenden Schritten die Testausführung beschleunigen:

1. Legen Sie für den Test fest, dass vier Messkanäle (einer für jede der oben genannten Messungen) im Oszilloskop konfiguriert werden.  
2. Triggern Sie eine einzelne Erfassung.
3. Rufen Sie die vier Messkanäle ab.

Verwalten der Lebensdauer von Hardwarereferenzen

Das häufige Öffnen und Schließen von Sessions mit der Hardware kann zu einer geringeren Leistung führen: Beim Initialisieren der Kommunikation mit einem Gerät übertragen viele Treiber große Datenmengen zur Prüfung der Kommunikation und Konfigurationen. Aus diesem Grund ist es am besten, die Hardware nur einmal pro Test zu initialisieren, während ein Session-Handle beibehalten wird, das während des Tests den Zugriff auf die Hardware ermöglicht.

Um die Hardware nur einmal bei einem Test zu initialisieren, können Sie den Prozessmodell-Rückruf „ProcessSetup“ vor dem gesamten Testcode ausführen.  Bei den Parallel- und Stapelprozessmodellen wird ProcessSetup unabhängig von der Anzahl der Testbuchsen nur einmal ausgeführt. Zum Bereinigen von Referenzen können Sie den ProcessCleanup-Rückruf nach Abschluss aller Tests einmal ausführen. Weitere Informationen zur Erstellung und zum Einsatz von Rückrufen für Prozessmodelle finden Sie unter Using Callbacks in NI TestStand (Verwenden von Rückrufen in NI TestStand).

Der Zugriff auf Hardware-Sessions, die in einem Prozessmodell-Rückruf geöffnet wurden, kann über eine globale Dateivariable erfolgen, die von der Rückrufsequenz und der MainSequence gemeinsam genutzt wird.  Alternativ können Sie den Session-Manager verwenden, der die Lebensdauer von Hardware-Sessions mithilfe eines ActiveX-Objekts automatisch verwalten kann.  Weitere Informationen zur Verwendung des Session-Managers finden Sie unter Session Manager Examples (Beispiele für den Session-Manager).

Es gibt verschiedene Möglichkeiten, um die Auswirkungen der Ergebniserfassung auf die Systemleistung so niedrig wie möglich zu halten.

Sofortige Protokollierung

Für die integrierten Ergebnisprozessoren können Sie die Option „On-The-Fly“ (Sofort) auswählen, um die Protokollierung während der Ausführung der Sequenz und nicht am Ende der Testsequenz durchzuführen.  Berücksichtigen Sie diese Vor- und Nachteile bei der Überlegung, ob Sie diese Einstellung nutzen sollten.

Vorteile der sofortigen Protokollierung:

• Ermöglicht dem Testoperator, den Bericht während der Testausführung anzuzeigen.
• Speichert die Ergebnisse bei einem kritischen Fehler im Testprogramm.
• Braucht weniger Speicher bei der Einstellung Discard Results (Ergebnisse verwerfen) bzw. Disable Results when not Required by Model (Ergebnisse deaktivieren, wenn nicht von Modell benötigt) aus den Prozessmodelloptionen.  Wenn diese Einstellung aktiviert ist, werden bereits verarbeitete Ergebnisse aus der Ergebnisliste entfernt, um Speicher freizugeben.  Für die Protokollerstellung müssen Sie in den Einstellungen für die Protokollerstellung auch die Option „Only Display Latest Results“ (Nur die neuesten Ergebnisse anzeigen) aktivieren, um auf diese Weise Speicherplatz zu sparen.  

Nachteile der sofortigen Protokollierung:

• Die Testgeschwindigkeit sinkt aufgrund des erhöhten Overheads, der für eine häufigere Protokollierung erforderlich ist.
• Schwieriger individuell anzupassen, da die Protokollierung auf einem separaten Server implementiert ist, der nicht geändert werden kann.

Wenn eine gewisse Geschwindigkeitsreduzierung akzeptabel ist, um die Vorteile der sofortigen Protokollierung zu nutzen, können Sie die Auswirkungen auf die Leistung durch Anpassen dieser Einstellungen verringern.  So greifen Sie auf diese Einstellungen zu:

1. Wählen Sie Configure » Result Processing (Konfigurieren » Ergebnisverarbeitung).
2. Aktivieren Sie das Kontrollkästchen Show More Options (Weitere Optionen anzeigen), und klicken Sie anschließend auf die Schaltfläche Advanced (Erweitert).

Erhöhen Sie zur Verbesserung der Leistung das Verarbeitungsintervall und/oder die maximale Anzahl der Ergebnisse, um die Häufigkeit zu verringern, mit der TestStand die Ergebnisse protokolliert.   

Offline-Verarbeitung von Ergebnissen

Um den Zeitaufwand für die Erzeugung von Ergebnissen zu reduzieren, können Sie Ergebnisdaten in einer Offline-Ergebnisdatei protokollieren. Hierbei handelt es sich um ein schnelles und kompaktes Rohergebnisformat, das alle Informationen enthält, die TestStand zur Erzeugung eines Berichts oder Protokolls in einer Datenbank benötigt.  Da die Datei nur Rohdaten enthält, dauert die Verarbeitung weniger lange, was sich positiv auf den Testdurchsatz auswirkt.

Mit dem Utility zur Verarbeitung von Offlineergebnissen können Sie Rohergebnisdateien in einem Testbericht verarbeiten oder die Daten in einer Datenbank protokollieren. Da es sich um ein separates Utility handelt, können Sie es unabhängig vom Testen ausführen, sodass Sie die Ergebnisse zu einem späteren Zeitpunkt oder auf einem anderen Computer verarbeiten können. Das Utility ist in Situationen von Vorteil, bei denen es mehr auf die Leistung des Testsystems als auf die sofortige Protokollerstellung ankommt. Weitere Informationen finden Sie in der Hilfe des TestStand Offline Results Processing Utility.

Optimieren der Datenspeicherung

Lokal auf einer Festplatte gespeicherte Daten werden schneller protokolliert als Daten an einem Netzwerkspeicherort, wobei nicht alle Mechanismen zur Übertragung von Netzwerkdaten gleich schnell sind. Wenn beispielsweise die Kommunikation mit einer Datenbank über Microsoft Message Queues (MSMQ) erfolgt, werden lokale Zwischendatendateien erstellt, die dann über das Netzwerk übertragen werden. Dies ist im Allgemeinen schneller und sicherer als der direkte Schreibvorgang in der Remote-Datenbank. TestStand bietet keine systemeigenen Funktionen für die Verwendung von MSMQ. Es stehen jedoch Tools von Drittanbietern zur Implementierung dieser Art von Kommunikation zur Verfügung.

Ausschließliches Protokollieren erforderlicher Daten

Ein weiterer zu berücksichtigender Faktor ist die Datenmenge, die im System protokolliert wird. Die Leistung nimmt mit zunehmender Menge an protokollierten Daten ab. Um nur die von Ihnen benötigten Daten zu protokollieren, können Sie die Ergebnisaufzeichnung für bestimmte Schritte oder Sequenzen deaktivieren.

Sie können die Ergebnisaufzeichnung für einzelne Schritte ausschließen, indem Sie die Option Record Result (Ergebnis aufzeichnen) unter Step » Properties » Run Options (Schritt » Eigenschaften » Ausführungsoptionen) deaktivieren. Sie können auch für eine gesamte Sequenz die Ergebnisaufzeichnung mit der Einstellung Disable Result Recording For All Steps (Ergebnisaufzeichnung für alle Schritte deaktivieren) im Dialogfeld Sequence Properties (Sequenzeigenschaften) ausschließen.

Abbrechen des Tests nach einem Fehler

In einer Produktionsumgebung müssen Sie möglicherweise nur wissen, dass ein Prüfling einen Test nicht bestanden hat, und nicht unbedingt, welcher Test genau fehlgeschlagen ist. In diesen Fällen können Sie den Test beim ersten Fehler abbrechen, um Systemressourcen freizugeben, und später eine detailliertere Fehleranalyse abrufen.  

Abhängig von Ihrem Test können einige Fehler schwerwiegender sein als andere. Möglicherweise möchten Sie den Test nur abbrechen, wenn bestimmte Schritte fehlschlagen.  Sie können das Fehlerverhalten für einzelne Schritte oder Sequenzen konfigurieren

So beenden Sie den Test bei einem Fehler während eines bestimmten Schritts:

1. Wählen Sie in den Schritteigenschaften die Option Post Action (Nach der Aktion).
2. Wählen Sie im Menü „On Fail“ (Bei Fehlschlag) die Option Terminate Execution (Ausführung abbrechen).

So beenden Sie den Test bei einem Fehler während einer bestimmten Sequenz:

1. Klicken Sie im Fensterbereich „Sequences“ (Sequenzen) mit der rechten Maustaste auf eine Sequenz und wählen Sie Sequence Properties (Sequenzeigenschaften).
2. Wählen Sie für „On Step Failure“ (Bei Fehlschlag eines Schritts) die Option Goto Cleanup (Zur Bereinigung gehen).

Sie können diese Einstellung auch für bestimmte Teststationen konfigurieren, z. B. nur beim vorzeitigen Abbruch von Produktionstestmaschinen, wohingegen Sie bei Diagnosemaschinen außerhalb der Produktionslinie den Test immer vollständig abschließen.  So konfigurieren Sie bestimmte Testmaschinen so, dass sie bei einem Testfehler abgebrochen werden:

1. Wählen Sie Configure » Station Options (Konfigurieren » Stationsoptionen).
2. Wählen Sie auf der Registerkarte „Execution“ (Ausführung) die Einstellung Immediately Goto Cleanup on Sequence Failure  (Sofortige Bereinigung bei Sequenzfehler).

Klicken Sie hier, um weitere Dokumente der TestStand Advanced Architecture-Serie mit interessanten Themen für fortgeschrittene NI-TestStand-Entwickler anzuzeigen.