Programmieren mit der TestStand​-API​

Überblick

In diesem Einführungsdokument wird die Nutzung der TestStand-API von NI beschrieben. Diese API trägt zur Leistungsfähigkeit und Flexibilität von TestStand bei. Die TestStand-API bietet eine objektorientierte Schnittstelle zu allen TestStand-Funktionen. Bei den meisten grundlegenden Anwendungen ist eine direkte Interaktion mit dem Objektmodell nicht notwendig. Wenn Sie jedoch die internen Prozesse von TestStand verstehen, gewinnen Sie einen Eindruck davon, wie sich in kürzester Zeit erweiterte TestStand-Lösungen entwickeln lassen.

Inhalt

TestStand-Architektur und die TestStand-API


Eine gut konzipierte, modulare Testarchitektur bietet einen enormen Nutzen. Sie können eine generalisierte, anpassbare Architektur bei einer Reihe von Testsystemen wiederverwenden, um die Lebensdauer des Testsystems zu verlängern und die Kosten für die Entwicklung von Tests zu verringern. Die TestStand-Plattform ist modular aufgebaut und vereinfacht somit die Entwicklung von Testsystemen und einschlägigen Tests. Die Stärke von TestStand liegt in der offenen Architektur, mit der Sie komplexe und flexible Testlösungen entwickeln können.

Die TestStand-Engine stellt die Funktionen für TestStand-Komponenten bereit, die über die TestStand-API mit der Engine kommunizieren.


Bei TestStand wird zwischen der Präsentationsebene (für den Benutzer sichtbare Inhalte) und der Business-Logik-Ebene (die Aktionen hinter dem Benutzerverhalten) klar getrennt. Diese Ebenen kommunizieren über die TestStand-API miteinander. Aufgrund dieser Methodik können Sie TestStand erweitern, indem Sie zusätzliche Komponenten erstellen, die via TestStand-API auf die TestStand-Engine zugreifen. So können Sie beispielsweise individuelle Benutzeroberflächen erstellen, Testabläufe dynamisch steuern, Sequenzen spontan einrichten und andere erweiterte Lösungen entwickeln.

 

TestStand-API-Architektur

Die TestStand-Engine ist ein ActiveX/COM-Automatisierungsserver, der Funktionen über eine API bereitstellt. Microsoft hat den Kommunikationsstandard ActiveX entwickelt, um die Kommunikation zwischen Applikationen zu erleichtern. ActiveX ist seit vielen Jahren in der Branche weit verbreitet und basiert auf COM-Technologien. Da TestStand auf COM aufbaut, ist die Kompatibilität mit zukünftigen Windows-Versionen über die Lebensdauer von ActiveX hinaus sichergestellt.

ActiveX verfolgt einen Client/Server-Ansatz. Ein ActiveX-Server ist eine Applikation, die bestimmte Funktionen für Clients bereitstellt, die dem ActiveX-Standard entsprechen. Darüber hinaus arbeiten ActiveX-Applikationen mit objektorientierter Programmierung (Object Oriented Programming, OOP).

Die ActiveX-Serverarchitektur sorgt dafür, dass jede Programmiersprache, die in der Lage ist, ActiveX-Code aufzurufen, mit der TestStand-Engine interagieren kann. Zu diesen Programmiersprachen zählen beispielsweise LabVIEW, LabWindows™/CVI™, C#, VB .NET oder C++. Wenn Sie mit der TestStand-API programmieren, hängt die Implementierung davon ab, welche Sprache Sie nutzen. Beispiel:

  • LabVIEW nutzt Eigenschafts- und Methodenknoten für API-Aufrufe.
  • LabWindows/CVI wendet bei API-Aufrufen einen Messgerätetreiber-Wrapper an.
  • C# oder or VB .NET rufen die API mithilfe einer von TestStand bereitgestellten Interop-Assembly auf.
  • TestStand selbst bietet einen ActiveX/COM-Adapter für den Zugriff auf die API. Sie können auch anhand von Ausdrücken direkt auf die API zugreifen.

Ganz gleich, wie Sie auf die API zugreifen: Das Ergebnis fällt in allen Umgebungen gleich aus, da die Funktionalität ungeachtet der von Ihnen genutzten Schnittstelle in der TestStand-Engine implementiert ist.

API-Klassen

Die TestStand-API definiert mehrere Klassen, die für die TestStand-Objekttypen stehen, z. B. SequenceFile oder Execution. Jede dieser Klassen definiert Eigenschaften (Properties) und Methoden für den Zugriff auf relevante Daten oder die Ausführung von Aktionen. Beispielsweise definiert die Klasse "SequenceFile" die Eigenschaft "Path", um den Pfad der Sequenzdatei auf dem Laufwerk zu speichern, sowie die Methode "Save" (Speichern), um die Sequenzdatei zu speichern.

Eine vollständige Liste der verfügbaren Klassen, die in der TestStand-API definiert sind, finden Sie im Themenabschnitt TestStand-API-Hilfe. Klicken Sie auf eine bestimmte Klasse, um mehr über diese Klasse sowie die von ihr definierten Eigenschaften und Methoden zu erfahren.

 

Erbbeziehungen zwischen Klassen

Viele Klassen in TestStand stehen zueinander in einer Erbbeziehung. Dabei kann eine spezifischere Klasse die Eigenschaften oder Methoden von einer allgemeineren Klasse erben. Beispielsweise ist die Klasse "SequenceFile" eine spezifischere Version der Klasse "PropertyObject". Die TestStand-API definiert eine Erbbeziehung zwischen diesen Klassen, damit Objekte einer spezifischeren Klasse auf die Eigenschaften und Methoden von allgemeineren Klassen zugreifen können.

Die Klasse "SequenceFile" erbt Eigenschaften und Methoden von den allgemeineren Klassen "PropertyObjectFile" und "PropertyObject".

 

Fast alle TestStand-API-Klassen erben von der grundlegenden Klasse "PropertyObject". Diese umfasst allgemeine Methoden und Eigenschaften, die von TestStand-Objekten gemeinsam genutzt werden. Die Klasse "PropertyObject" definiert allgemeine Eigenschaften wie "Name" und "Numeric Format" und stellt gängige Objektverwaltungsmethoden bereit, beispielsweise Klonen, Einstellen und Abrufen von Werten, Erstellen und Löschen von Objekten oder Manipulieren von Arrays. Da die meisten TestStand-API-Klassen von der Klasse "PropertyObject" erben, können sie auch auf diese allgemeinen Eigenschaften und Methoden zugreifen. So können Sie etwa mithilfe der Methode "PropertyObject.Clone()" eine Kopie eines Schritts, einer Sequenz oder eines Objekts der Klasse "SequenceFile" erstellen.

In zahlreichen Entwicklungsumgebungen werden Sie am direkten Zugriff auf die Eigenschaften einer Elternklasse gehindert. Ähnlich verhält es sich bei TestStand, wo Sie beispielsweise die Methode "Clone()" nicht direkt über ein Objekt der Klasse "SequenceFile" aufrufen können. Die TestStand-API stellt jedoch Methoden bereit, nach denen sich ein Objekt so umbetten lässt, dass der Zugriff auf Eigenschaften und Methoden der allgemeineren Klasse möglich ist. Damit Sie auf Eigenschaften und Methoden zugreifen können, die in der Klasse "PropertyObject" definiert sind, können Sie das Objekt in die zugehörige Elternklasse einbetten, indem Sie die Methode "AsPropertyObject" aufrufen. Beispielsweise können Sie mithilfe
von "SequenceFile.AsPropertyObject.Clone()" auf die Methode "Clone()" bei einem Objekt der Klasse "SequenceFile" zugreifen.

Weitere Informationen über die API-Erbbeziehungen sowie über die Eigenschaften und Methoden der Klasse PropertyObject finden Sie in der Hilfe zu NI TestStand.


Unterschiede zwischen dynamischen Eigenschaften und integrierten Eigenschaften

TestStand-Objekte weisen zwei verschiedene Arten von Eigenschaften auf:

  • Integrierte Eigenschaften (API-Eigenschaften) sind durch die Objektklasse definiert und für alle Objekte einer bestimmten Klasse vorhanden.
  • Dynamische Eigenschaften (Subproperties) sind nach dem Objekt definiert und können zwischen den einzelnen Objekten derselben Objektklasse variieren.

Ein Objekt vom Typ "Step" weist einerseits dynamische Eigenschaften, die sich je nach diesem Typ voneinander unterscheiden können, andererseits statische Eigenschaften auf, die durch die Klasse "Step" in der TestStand-API definiert sind.


Diese beiden verschiedenen Eigenschaftentypen können leicht verwechselt werden, da beide in einem TestStand-Ausdruck mit "." aufrufbar sind. ​Operator. Wenn Sie jedoch die API in anderen Programmiersprachen nutzen, können Sie nur auf integrierte Eigenschaften direkt zugreifen, etwa bei der Nutzung eines Eigenschaftenknotens in LabVIEW.


Sie können auf dynamische Eigenschaften zugreifen, indem Sie die Methoden der PropertyObject-API anwenden, beispielsweise "GetValString()" und "GetValNumber()", und per LookupString den Namen der dynamischen Eigenschaft angeben:



In einigen Klassen können Sie auf verschiedene Weise auf eine Eigenschaft zugreifen – entweder mithilfe dynamischer oder anhand integrierter Eigenschaften. Wenn die TestStand-API in einem Codemodul eingesetzt wird, empfiehlt sich die Nutzung von integrierten Eigenschaften, da diese direkt und ohne die nötige Pflege von Lookup-Strings zugänglich sind.

 

TestStand-Objektbeziehungen

TestStand-Objekte können weitere Objekte einer anderen Klasse enthalten, was als API Containment bezeichnet wird. So enthält etwa ein Objekt des Typs "SequenceFile" Objekte vom Typ "Sequence" für die in der Sequenzdatei definierten Sequenzen. Alle Objekte des Typs "Sequence" enthalten wiederum Objekte vom Typ "Step".

Objekte in der TestStand-API enthalten häufig weitere Objekte einer anderen Klasse.

Für die Navigation durch bestimmte Objekte ist es hilfreich, die Containment-Beziehungen zwischen einzelnen Objekten zu kennen. Enthält ein Elternobjekt (übergeordnetes Objekt) mehrere Kindobjekte (untergeordnete Objekte) einer bestimmten Klasse, müssen Sie entweder einen Eigenschaftsnamen oder einen entsprechenden Index angeben, um das gewünschte Kindobjekt zu benennen. Bei den meisten Kindobjekten greifen Sie über ein Elternobjekt auf die eingebundenen Objekte zu. Dabei bedienen Sie sich einer bestimmten Abrufmethode, die den Objektnamen oder -index als Parameter zulässt. Wenn Sie beispielsweise auf einen Schritt innerhalb einer Sequenzdatei zugreifen möchten, nutzen Sie folgende Variante:

SequenceFile.getSequenceByName(“MainSequence”).GetStepByName(“RAM Test”, StepGroup_Main)

Darüber hinaus können Kindobjekte über die API auf die zugehörigen Elternobjekte zugreifen. Da es zu jedem Kindobjekt immer nur ein einziges Elternobjekt geben kann, greifen Sie nicht mithilfe einer Abrufmethode, sondern über eine Eigenschaft direkt auf das Elternobjekt zu. Wenn Sie etwa ein Objekt des Typs "SequenceContext" haben und auf die Ausführung des Elternobjekts zugreifen müssen, können Sie folgende Option nutzen:

ThisContext.Thread.Execution

Häufig werden integrierte Eigenschaften bereitgestellt, um auf weiter entfernte Vorfahren zuzugreifen. So können Sie zum Beispiel über ein Objekt des Typs "SequenceContext" direkt auf das Ausführungsobjekt zugreifen:

ThisContext.Execution

 

Navigation durch Objekte der TestStand-API

Zusätzlich zur Navigation anhand von Containment-Beziehungen stehen in vielen Klassen Eigenschaften oder Methoden zum Zugriff auf andere verwandte Objekte zur Verfügung. So stellt etwa die Klasse "Module" die Eigenschaft "Adapter" bereit, damit Sie auf den entsprechenden ausführenden Adapter zugreifen können.

Sie können anhand des Diagramms im Hilfethema TestStand API Reference feststellen, wie Sie vom aktuellen Objekt ausgehend auf ein gewünschtes Objekt zugreifen können. Ein Teil dieses Diagramms ist unten abgebildet.
 

Vom Objekt des Typs "sequenceContext" aus können Sie durch die Objektbeziehungen navigieren, um auf andere Objekte zuzugreifen.

Zugriff auf die TestStand-API​

Üblicherweise können Sie auf zwei verschiedene Arten auf die API zugreifen. Welche davon zutrifft, hängt von der Art der von Ihnen erstellten Applikation ab:

  • Bei eigenständigen Applikationen müssen Sie eine neue Instanz der TestStand-Engine erstellen.
  • Für Codemodule oder andere Tools, die aus einer vorhandenen Applikation aufgerufen werden, müssen Sie eine bestehende Referenz zur TestStand-Engine einbinden.

 

Erstellen einer eigenständigen TestStand-Anwendung

Damit Sie die TestStand-API in einer neuen Applikation nutzen können, müssen Sie zunächst eine Instanz der TestStand-Engine erstellen. Alle TestStand-Applikationen oder -Prozesse, beispielsweise eine TestStand-Benutzeroberfläche, Sequence Editor oder ein benutzerdefiniertes Dienstprogramm, bewahren eine einzelne Instanz der Engine (Einling) zur Ausführung beliebiger TestStand-Funktionen. Die Engine bewahrt Referenzen zu allen In-Memory-Objekten, richtet Ausführungen ein, steuert diese und speichert die Kontextdaten für eine TestStand-Sitzung sowie globale Varianten für Stationen und Benutzerinformationen.

Die TestStand-Engine stellt Methoden bereit, nach denen Sie weitere TestStand-Objekte erstellen können, die mit dem "neuen" Schlüsselwort gekennzeichnet sind. Dazu zählen folgende Methoden:

  • Engine.NewSequenceFile()
  • Engine.NewStep()
  • Engine.NewExecution()
  • Engine.NewPropertyObject()

Eine vollständige Liste der über das Engine-Objekt verfügbaren Eigenschaften und Methoden sowie weitere Informationen finden Sie im Themenabschnitt "TextStand-Engine".

Wenn die Applikation fertig ist, müssen Sie vor dem Beenden der Applikation die TestStand-Engine schließen. Der Schließvorgang muss in zwei Schritten erfolgen, damit der Benutzer die Möglichkeit hat, alle laufenden Ausführungen zu beenden. Dieser Vorgang ist im Themenabschnitt Schließen der Engine in der TestStand-Hilfe erläutert.

Es wird empfohlen, zur Entwicklung von TestStand-Applikationen und -Benutzeroberflächen die TestStand-UI-Steuerelemente zu verwenden, statt direkt ein TestStand-Engine-Objekt zu erstellen, damit sich Ihr Programm weniger komplex gestaltet. Die TestStand-UI-Steuerelemente stellen eine Abstraktionsschicht oberhalb der TestStand-API bereit, sodass die Entwicklung eigenständiger TestStand-Applikationen leichter von der Hand geht. Weitere Informationen zur Nutzung der UI-Steuerelemente finden Sie im Abschnitt [UI-Steuerlemente-API] dieses Dokuments.


Aufrufen eines Codemoduls oder Tools aus einer vorhandenen Applikation

Wenn Sie die API in einem Codemodul oder Tool nutzen, das sie aus einer anderen TestStand-Applikation aufrufen, arbeiten Sie mit der TestStand-Engine, die von der Applikation auf der höchsten Ebene erstellt wurde. Wird der Code aus einer ausführenden Sequenz aufgerufen, etwa einem Codemodul, empfiehlt es sich, einen Eingangsparameter für das Objekt des Typs "SequenceContext" anzuwenden. Diese Vorgehensweise ist gegenüber der direkten Übergabe der TestStand-Engine vorzuziehen, da der Sequenzkontext über das TestStand-Engine-Objekt hinaus auch den Zugriff auf den aktuellen Ausführungsstatus ermöglicht.

"SequenceContext" steht für den aktuellen Ausführungsstatus einer Sequenz und ermöglicht den Zugriff auf einen Snapshot aller Daten für eine bestimmte Ausführungssequenz. Jede ausführende Sequenz in einem Thread weist ein eigenes Objekt des Typs "SequenceContext" auf.

Wenn Sie die Ansicht "Variables" durchgehen, sehen Sie eine Liste der Sequenzkontexteigenschaften auf der ersten Ebene. Darin enthalten sind alle Variablentypen, der aktuelle Schritt und die Eigenschaft "RunState". "SequenceContext" stellt zudem Referenzen zu zahlreichen weiteren Objekten als integrierte Eigenschaften bereit.

 

Unterschiede zwischen RunState und SequenceContext


Die Eigenschaft "RunState" und der Objekttyp "SequenceContext" ermöglichen beide den Zugriff auf viele derselben Objekte, zum Beispiel aktuelle Ausführung, Thread, Sequenzdatei und Sequenz. Allerdings sind diese Objekte in "RunState" als dynamische Eigenschaften enthalten, wohingegen sie von SequenceContext als integrierte Eigenschaften bereitgestellt werden.

Daher sollten Sie die Eigenschaft "RunState" nutzen, wenn Sie auf Informationen über den Status in TestStand-Ausdrücken zugreifen. Hingegen ist "SequenceContext" besser geeignet für Codemodule, bei denen Sie nicht direkt auf dynamische Eigenschaften zugreifen können.


"SequenceContext" stellt Informationen zum Ausführungsstatus über integrierte und dynamische Eigenschaften bereit, während "RunState" Statusinformationen ausschließlich über dynamische Eigenschaften bereitstellt.

Fortbestand von Sequenzdaten

Bevor die Schritte in einer Sequenz ausgeführt werden, erstellt TestStand eine Laufzeitkopie der Sequenz, um separate lokale Variablen und Schritteigenschaftswerte für jeden Sequenzaufruf zu bewahren. Wenn Sie innerhalb einer Ausführungssequenz über "RunState" oder "SequenceContext" auf Objekte zugreifen, handelt es sich bei diesen Objekten zumeist um die erwähnten Laufzeitkopien. Somit bleiben Änderungen, die Sie an diesen Objekten vornehmen, nach Abschluss der Ausführung nicht bestehen. Beispielsweise haben Änderungen an den Werten lokaler Variablen oder die programmatische Erstellung der Untereigenschaft (Subproperty) eines Parameters keine Auswirkungen auf die Sequenzdatei auf dem Laufwerk:

Locals.SetValString("RuntimeVariable",1, "value")

Objekte, die von der Klasse "PropertyObjectFile" erben, etwa Objekte des Typs "SequenceFile", haben keine separate Laufzeitkopie. Daher bleiben Änderungen, die Sie anhand dieser Objekte vornehmen, auch nach Abschluss der Ausführung bestehen. So können Sie beispielsweise eine dauerhafte lokale Variable erstellen, wenn Sie über ein Objekt des Typs "SequenceFile" auf die Eigenschaft "Locals" zugreifen, .

RunState.sequencefile.GetSequenceByName("MainSequence").Locals.SetValString("PersistantVariable",1, "value")

 

Gängige Anwendungsbereiche der TestStand-API

Die TestStand-API ermöglicht die Automatisierung aller TestStand-Funktionen, doch es gibt noch gängigere Anwendungsbereiche:

  • Erstellen von Zusatzeigenschaften
  • Erstellen von neuen Sequenzdateien
  • Ändern von bestehenden Sequenzen

 

Erstellen von Zusatzeigenschaften

Mit der TestStand-API können Sie Zusatzeigenschaften zur Laufzeit dynamisch erzeugen, um beispielsweise die Testergebnisse um spezifische Diagnosedaten zu ergänzen, wenn eine bestimmte Komponente den Test nicht besteht, oder um benutzerdefinierte Daten zum Protokoll-Header hinzuzufügen.

Es gibt viele Möglichkeiten zur Erstellung von Zusatzeigenschaften über die API. Bei primitiven Daten lassen sich neue Eigenschaften am einfachsten anhand der Methode "SetVal" mit der Option "InsertIfMissing" erzeugen. So können Sie zum Beispiel mithilfe des folgenden Ausdrucks eine neue Eigenschaft zum Schritt "Numeric Limit Test" hinzufügen:

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetValString(
"Result.extraResult",
PropOption_InsertIfMissing,
"this string is an extra result")

Wenn Sie eine Zusatzeigenschaft zum Protokoll hinzufügen möchten, müssen Sie zudem das Objekt mit "IncludeInReport" markieren. Anhand dessen wählt die Protokollerstellungsfunktion die zu protokollierenden Ergebniseigenschaften aus:

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetFlags(
"Result.extraResult",
0,
PropFlags_IncludeInReport)

Nähere Informationen darüber, wie Sie mit der API Daten zum Testprotokoll hinzufügen können, finden Sie im Beispiel Benutzerdefinierte Daten zu einem Protokoll hinzufügen.

Bei komplexeren Eigenschaften wie Containern müssen Sie die Eigenschaften direkt nach der Methode NewSubProperty() erstellen, die Ihnen das Erzeugen von Containern, Datentypinstanzen und Arrays ermöglicht. Wenn Sie etwa eine neue lokale Variable des Typs "Error" erstellen möchten, verwenden Sie den folgenden Ausdruck:

Locals.NewSubProperty("ComplexContainer.Error",PropValType_NamedType, False, "Error",0)

Nähere Informationen zum Erstellen von Eigenschaften mithilfe der API finden Sie im Beispiel [Neue Eigenschaften mit der API erstellen].

 

Erstellen neuer Sequenzen

Wenn Sie das Erstellen einer Sequenzdatei auf Basis von Benutzereingaben automatisieren möchten, können Sie mit der TestStand-API neue Sequenzdateien erzeugen oder modifizierte Kopien einer bestehenden Datei erstellen. So können Sie zum Beispiel ein Tool erstellen, das eine Startpunkt-Sequenzdatei anhand bestimmter Benutzereingaben erzeugt oder bestimmte Schrittmodifikationen in einer bestehenden Sequenzdatei vornimmt.

Weitere Informationen zum Erstellen neuer Sequenzdateien mit der API finden Sie im Beispiel Neue Sequenzen mit der API erstellen.

Sie können die TestStand-API auch zum Entwickeln eines Sequence File Translator nutzen, um Sequenzdateien anhand eines benutzerdefinierten Dateiformats zu erzeugen. Beim Entwickeln eines Sequence File Translator erzeugen Sie mithilfe der TestStand-API Sequenzdateien, Sequenzen, Schritte und Eigenschaften auf  Basis der Daten in einer von Ihnen angegebenen Datei. Anhand des Translator-Frameworks können Sie diesen Code in TestStand integrieren und Dateien direkt in einem benutzerdefinierten Format öffnen.

Weitere Informationen zur Nutzung von Sequence File Translators finden Sie in der TestStand-Hilfe im Themenabschnitt Sequence File Translators.


Modifizieren von Sequenzen

Sie können die TestStand-API in benutzerdefinierten Tools nutzen, mit denen Sie Modifikationen an bestehenden Sequenzdateien vornehmen. So können Sie etwa ein Tool erzeugen, das nach Codemodulen auf Basis von absoluten Pfaden sucht und diese durch relative Pfade ersetzt.

Weitere Informationen hierzu finden Sie im Beispiel Iterationstool für Sequenzdatei erzeugen.

 

Zusätzliche TestStand-APIs

Zusätzlich zur mit Kernfunktionen ausgestatteten TestStand-API bietet TestStand weitere APIs, die erweiterte Funktionen und weitere Merkmale umfassen.

  • UI-Steuerelemente-API
  • Adapter-API
  • Synchronisationsserver-API

Anders als die auf Kernfunktionen beschränkte TestStand-API können diese APIs nicht direkt über Ausdrücke aufgerufen werden, sondern durch einen ActiveX-Schritt oder ein separates Codemodul.


UI-Steuerelemente-API

TestStand umfasst UI-Steuerelemente zur schnellen Entwicklung von TestStand-Benutzeroberflächen. Darunter befinden sich sichtbare Steuerelemente zur Anzeige von TestStand-Daten, beispielsweise die Ansichten "Steps" oder "Variables", sowie "Invisible Manager"-Steuerelemente, die einen Großteil der Kommunikation mit der TestStand-Engine-API innerhalb einer TestStand-Benutzeroberfläche abwickeln.

Es wird empfohlen, zur Entwicklung von eigenständigen TestStand-Applikationen die TestStand-UI-Steuerelemente zu verwenden, statt direkt eine TestStand-Engine-Instanz zu erstellen.

Mit der UI-Steuerelemente-API können Sie gängige Benutzeroberflächenaufgaben anhand der Steuerelemente des Managers implementieren, beispielsweise Öffnen und Ausführen von Sequenzdateien, Beantworten von UI-Nachrichten und Schließen von Applikationen. Die UI-Steuerelemente-API stellt auch Verbindungsmethoden zum Konfigurieren der UI-Steuerelemente bereit.

Weitere Informationen zur Nutzung der UI-Steuerelemente und der UI-Steuerelemente-API finden Sie in den folgenden Hilfethemen:


Sie können sich die TestStand-UI-Steuerelemente als Softwareschicht vorstellen, die auf der TestStand-Engine-API liegt. Diese Steuerelemente umfassen viele der Funktionen, die Sie in einer Benutzeroberfläche benötigen, unter anderem Öffnen von Sequenzen, Ausführen von Tests und Anzeigen des Testfortschritts. Die TestStand-UI-Steuerelemente zeichnen sich durch Funktionsreichtum und eine eigene API aus. Eine ausführliche Beschreibung der Funktionen dieser UI-Steuerelemente würde zwar den Rahmen dieses Dokuments sprengen, dennoch sei an dieser Stelle ausdrücklich darauf hingewiesen, dass diese Steuerelemente zusätzliche Funktionen auf Grundlage der TestStand-Engine-API umfassen.

 

Adapter-API

Die Adapter-API stellt spezifische Klassen für die verschiedenen in TestStand enthaltenen Adapter bereit. Üblicherweise wird die Adapter-API für adapterspezifische Informationen oder Funktionen genutzt, wenn die Adapter- oder Modulklassen in der API mit den Kernfunktionen verwendet werden. In diesem Fall binden Sie das Objekt in die entsprechende Adapter-API-Klasse ein. So können Sie beispielsweise über die Klasse "LabVIEWModule" auf LabVIEW-spezifische Eigenschaften und Methoden für das Modulobjekt in einem Schritt des Typs "LabVIEW" zugreifen.

Nutzen Sie die Adapter-API, um auf adapterspezifische Eigenschaften und Methoden für die Modul- oder Adapterklassen zuzugreifen.

 

Eine Liste der in der Adapter-API bereitgestellten Klassen finden Sie in der Referenz zur TestStand-Adapter-API.

 

Synchronisationsserver-API

Die Synchronisationsserver-API ermöglicht den direkten Zugriff auf TestStand-Synchronisationsobjekte wie Warteschlangen, Sperren und Benachrichtigungen. Damit Sie diese API nutzen können, muss zunächst eine Referenz zum Synchronisationsserver nach der Methode "Engine.GetSyncManager" erstellt werden. Nachdem Sie dieses Objekt auf die in der Synchronisationsserver-API definierte Synchronisationsmanager-Klasse angewendet haben, können Sie damit auf Synchronisationsobjekte zugreifen oder neue Synchronisationsobjekte erstellen.


Nutzen Sie den SyncManager und die Synchronisationsserver-API, um kodierte TestStand-Synchronisationsobjekte zu erstellen und darauf zuzugreifen.

 

Diese API ist nützlich beim Entwickeln von Applikationen, die neben einem TestStand-Test ausgeführt werden und auf Informationen zum Ausführungsstatus zugreifen müssen, beispielsweise eine Applikation zur Statusüberwachung.

Weitere Informationen zu den verfügbaren Klassen finden Sie im Themenabschnitt Referenz zur Synchronisationsserver-API.