6. Messsynchronisation

Die Messsynchronisation ist einer der wichtigsten Punkte, die bei der Entwicklung einer Fernsteueranwendung beachtet werden müssen. Bei Vernachlässigung dieses Aspekts Ihres Programms drohen unvorhersehbares Verhalten, Ergebnisse, die sich nicht reproduzieren lassen, und viel Frust. Ein klares Zeichen für eine fehlerhafte Messsynchronisation ist, wenn Ihre Anwendung nur zum Laufen zu bringen ist, indem feste Pausen eingefügt werden.

Klären wir zunächst, was Messsynchronisationim Kontext dieses Kapitels bedeutet:

Heutige Messgeräte sind komplexe Systeme mit eigenen Betriebssystemen. Ihre Messapplikation muss sich nicht ständig um den Status des Geräts kümmern. Die Messsynchronisation soll sicherstellen, dass sich Ihr Gerät an wichtigen Punkten des Programms (SyncPoints) wirklich im erwarteten Zustand befindet.

Ein Beispiel für die Messsynchronisation mit einem Oszilloskop und einem Prüfling, der ein nicht-periodisches Signal erzeugt:

Im Bild oben sehen Sie, dass das Programm Leerlaufabschnitte aufweist, in denen gewartet wird, bis das Gerät aufgeholt hat. Beachten Sie, dass die Länge dieser Leerlaufzeiten dynamisch ist. Sie müssen an unterschiedliche Betriebsbedingungen angepasst werden (z. B. Geschwindigkeit Ihres PCs, unterschiedliche Einschwing- und Erfassungszeiten des Geräts). Wie lässt sich eine solche Anpassung vornehmen? Am besten ist es, das Gerät selbst mitteilen zu lassen, wann es wieder bereit ist. Im Anschluss an die folgenden Hinweise werden verschiedene Synchronisationsmethoden vorgestellt.

Zusätzliche Hinweise:

• Betreiben Sie ein Erfassungsgerät (Oszilloskop, Spektrumanalysator, Leistungsmesser…) immer im Einzelerfassungsmodus. Nur dann können Sie sicher sein, dass Ihre Messergebnisse von der letzten abgeschlossenen Erfassung stammen und nicht von der vorherigen oder noch laufenden Erfassung. Wichtig: Sämtliche Synchronisationsmethoden funktionieren nur im Einzelerfassungsmodus.
• Die Grund- und Triggereinstellungen müssen nicht synchronisiert werden. Der einzige wichtige Punkt kommt am Ende, wo Sie sicherstellen sollten, dass alle Einstellungen angewendet wurden (SyncPoint „SettingsApplied“).
• Nachdem der Trigger eingetroffen ist, beginnt das Oszilloskop mit der Messkurvenerfassung. Ihr Programm muss warten, bis die Erfassung beendet ist (SyncPoint „AcquisitionFinished“).
• Durch das Auslesen der Messkurve nach diesem SyncPoint wird sichergestellt, dass das Ergebnis von der letzten Erfassung stammt.

Übersicht über Synchronisationsmechanismen

In den folgenden vier Kapiteln stellen wir verschiedene Synchronisationsmechanismen vor. Wir fangen mit den einfachsten an und gehen dann zu komplexeren über:

• *OPC? Query
• Status Byte (STB)-Abfrage
• Warten auf Service Request (SRQ)
• Service Request (SRQ) Event

Synchronisation durch *OPC? Query

Dies ist die einfachste und am häufigsten verwendete Synchronisationsmethode.

Wenn Sie die *OPC? Query an ein Gerät senden, verzögert dieses die Antwort, bis alle ausstehenden Operationen abgeschlossen sind. Daher entfallen die Leerlaufzeiten in Ihrem Programm auf VISA Read-Operationen, bei denen das Programm darauf wartet, dass das Gerät auf die *OPC? Query antwortet. Dabei kommt es nicht auf die Antwort selbst an, sondern auf die Verzögerung, die sie einführt.

Wichtig! Da es sich bei *OPC? um eine Query handelt, dürfen Sie nicht vergessen, die Antwort des Geräts mit der VISA Read()-Funktion auszulesen. Andernfalls erzeugt Ihr Gerät bei der nächsten Abfrage den Fehler „Query Interrupted“. Dies ist nicht nur für die *OPC? Query, sondern alle Abfragen wichtig.

An dieser Stelle ist ein weiterer Parameter zu erwähnen – VISA Timeout. Sie können mit VISA Timeout die maximale Wartezeit definieren, bis VISA Read-Operationen mit einem VISA Timeout-Fehler beendet werden. Da dieser Wert individuell ist und von der Dauer der jeweiligen Aufgabe abhängt, achten Sie auf eine geeignete VISA Timeout-Einstellung – ein zu kleiner Wert kann im Normalbetrieb zu unerwünschten Fehlermeldungen führen, während das Programm bei einer zu langen Zeiteinstellung nicht reagiert, falls tatsächlich ein Fehler auftritt.

Vorteile:

• In den meisten Fällen einfach und effektiv.
• Verwendet nicht den Control Channel der Sitzung (siehe STB-Abfragemethode), funktioniert daher auch mit RawSocket-und serieller-Verbindung.

Nachteile:

• Blockiert die Kommunikation mit dem Gerät, bis es antwortet. Dies kann besonders bei langwierigen Operationen kritisch werden, die zur Folge haben, dass Ihre Anwendung nicht mehr reagiert.

Synchronisation durch Status Byte (STB)-Abfrage

Diese Methode wird von den Rohde & Schwarz Gerätetreibern verwendet. Wenn Sie direkte SCPI-Befehle verwenden, finden Sie entsprechende Implementierungsbeispiele am Ende dieses Kapitels. Schauen wir uns zunächst das Flussdiagramm an, das den Ablauf zeigt. Die Erklärung folgt im Anschluss.

Um das Flussdiagramm zu verstehen, müssen wir einen Blick auf das Status Subsystemeines Messgeräts werfen – eine hierarchische Struktur von Registern, an deren Spitze das Hauptregister namens Status Byte(STB) steht. Es handelt sich um ein 8-bit-Register, das im IEEE 488.2-Standard definiert ist. Jedes seiner Bits hat eine andere Bedeutung und dient als zusammenfassendes Flag für die untergeordneten Statusregister. Die vollständige Struktur des Status Subsystems finden Sie in jedem Rohde & Schwarz Benutzerhandbuch zur Gerätefernsteuerung (suchen Sie nach dem Begriff „Status Byte“). Das folgende Bild zeigt das Status Byte-Register sowie das zweite Register Event Status Register(ESR):

• Mit der ersten Operation des Flussdiagramms wird das ESE Filterauf 1 gesetzt (Bit 0 = 1). Das heißt, uns interessiert nur das ESR Bit 0 - OPC. Sie müssen diesen Befehl nur einmal senden – nach der Initiierung der Verbindung oder nach dem *RST-Befehl.
• In der nächsten Operation wird der ESR-Registerwert mit dem Befehl *ESR?abgefragt. Dieses Register ist ein EVENT-Register – mit dem Auslesen wird sein Wert gelöscht. Das ESR-Bit 0 - OPC wieder dadurch auf 0 zurückgesetzt.
• Mit der nächsten Operation wird der Befehl gesendet, den Sie synchronisieren möchten. In unserem Fall ist es der SCPI-Befehl SING, mit dem das Oszilloskop für eine einzelne Erfassung armiert wird. *OPC (ohne Fragezeichen!) am Ende der Zeichenfolge teilt dem Gerät mit: Nachdem alle Befehle in dieser Zeichenfolge ausgeführt und abgeschlossen wurden, soll ESR Bit 0 - OPCauf 1 gesetzt werden. Aus diesem Grund musste es vorher auf 0 zurückgesetzt werden. Andernfalls hätte es durch einige der vorherigen Aktionen auf 1 gesetzt worden sein können. In diesem Fall würde die STB-Abfrageschleife nach der ersten Iteration mit falschem Resultat beendet.
• Die nächste Operation ist die Status Byte-Abfrageschleife. Das Status Byte wird so lange abgefragt, bis Bit 5 - Event Status Summaryauf 1 gesetzt wird. Der Status Byte-Wert kann auf zwei verschiedene Arten abgerufen werden – entweder mit dem SCPI-Befehl *STB?oder mit einer speziellen VISA-Funktion namens ReadSTB(). Worin besteht der Unterschied? *STB? ist ein Standard-SCPI-Befehl, der VISA-I/O-Pufferverwendet. Die Funktion ReadSTB() kommuniziert über einen separaten Kanal namens Control Channelund hat keine Auswirkungen auf die gewöhnliche SCPI Write/Read-Kommunikation. Sie ist außerdem für schnelle Antwortzeiten optimiert. Es empfiehlt sich, in diese Schleife eine progressive Abfrageverzögerung einzubauen. Beispiel: in den ersten 10 Iterationen keine Verzögerung, dann in den nächsten 100 Iterationen 1 ms Verzögerung, in den nächsten 1000 Iterationen 10 ms Verzögerung usw... Zur Verhinderung von Endlosschleifen verwenden Rohde & Schwarz Gerätetreiber ein Timeout namens OPC Timeout.
• Nach Beendigung der Schleife wird das ESR Bit 0 - OPC mit dem SCPI-Befehl *ESR? wieder zurückgesetzt.

Vorteile:

• Blockiert nicht die Kommunikation mit dem Gerät. Sie können parallel SCPI-Befehle senden und Antworten empfangen.
• Geeignet für Operationen mit langer Ausführungsdauer. Zum Beispiel Selbstabgleich oder Selbsttest.

Nachteile:

• Komplexer zu implementieren.
• Funktioniert nicht mit RawSocket- und seriellen Verbindungen, da diese die Control Channel-Funktion VISA ReadSTB() nicht unterstützen.

Erweiterte Methoden mit Service Request (SRQ)

Synchronisation durch Warten auf Service Request (SRQ)

Diese Methode ähnelt der gerade beschriebenen Synchronisation durch Status Byte-Abfrage, verwendet jedoch anstelle der STB-Abfrageschleife die Funktion VISA WaitOnEvent(),die zum Warten auf ein Service Request Event konfiguriert ist. Beispiele für diese Art der Synchronisation finden Sie am Ende dieses Kapitels.

Um den Mechanismus zu verwenden, müssen Sie:

• Eine einmalige Einstellung durchführen nach Reset *ESE 1;*SRE 32(siehe Bild der Status Subsystem-Register oben). Dadurch wird das ESE-Filter so eingestellt, dass es auf das ESR OPC-Bit reagiert, genau wie bei der vorherigen Synchronisationsmethode durch STB-Abfrage. Mit „*SRE 32“ wird das SRE-Filterzum Erzeugen eines Service Requestseingestellt, wenn das Event Status Summary Bit des STB-Registers auf 1 gesetzt wird.
• Aktivieren Sie vor dem Senden des Befehls zur Synchronisierung das Service Request Event mit Hilfe der VISA EnableEvent()Funktion.
• Senden Sie den Befehl zur Synchronisierung mit dem ;*OPCam Ende.
• Rufen Sie die VISA WaitOnEvent()Funktion auf. Diese wartet, bis ein Service Request Event eintrifft oder der Timeout abläuft.
• Deaktivieren Sie das Service Request Event mit der VISA DisableEvent()Funktion.

Vorteile:

• Gegenüber der vorherigen Methode ist keine STB-Abfrageschleife erforderlich.
• Die IO-Trace ist kürzer und besser lesbar.

Nachteile:

• Ihre Anwendung in LabVIEW und MATLAB kann während der VISA WaitOnEvent()Ausführung nicht unterbrochen werden. Dies kann bei Befehlen problematisch sein, deren Ausführung lange dauert, z. B. der Selbsttest-Query *TST?
• Wird bei RawSocket- und serieller Verbindung nicht unterstützt.

Synchronisation über Service Request (SRQ) Event

Die Grundidee hierbei ist, eine Aufgabe eines Geräts zu starten und sich dann auf etwas anderes zu konzentrieren. Wenn das Gerät die Aufgabe abgeschlossen hat, ruft VISA eine Funktion Ihrer Wahl auf. Diese Funktion nennt man Event Handler.

Beispiele für diese Art der Synchronisation in C# und LabWindows/CVI finden Sie am Ende dieses Kapitels.

Für die Synchronisation per Service Request Event müssen Sie:

• Eine einmalige Einstellung durchführen nach Reset *ESE 1;*SRE 32(siehe Bild der Status Subsystem-Register oben). Dadurch wird das ESE-Filter so eingestellt, dass es auf das ESR OPC-Bit reagiert, genau wie bei der vorherigen Synchronisationsmethode durch STB-Abfrage. Mit *SRE 32wird das SRE Filter zum Erzeugen des Service Requests eingestellt, wenn das Event Status Summary Bitdes STB-Registersauf 1 gesetzt wird.
• Vor dem Senden des Befehls zur Synchronisation müssen Sie Ihre Rückruffunktion mit der VISA InstallHandler()Funktion registrieren und den Service Request-Mechanismus mit der VISA EnableEvent()Funktion aktivieren.
• Senden Sie den Befehl zur Synchronisierung mit dem ;*OPCam Ende. Nachdem die Befehlsausführung abgeschlossen ist, ruft VISA Ihre registrierte Funktion auf.

Vorteile:

• In der Zwischenzeit können Sie andere Aufgaben erledigen.
• Ideal für Multithreading-Anwendungen.

Nachteile:

• Komplexer zu implementieren.
• Wird bei RawSocket- und serieller Verbindung nicht unterstützt.
• Wird in LabVIEW und MATLAB nicht unterstützt.

Beispiele für direkte SCPI-Befehle

Beispiele für die obige Messaufgabe mit *OPC? Query-Synchronisationund:

• Synchronisation durch STB-Abfrage
• Synchronisation durch Warten auf Service Request
• Synchronisation über Service Request Event (in Python, C# and LabWindows/CVI)

Beispiele für Gerätetreiber

Beispiele für die obige Messaufgabe:

Andere Ressourcen

Weitere Informationen zum Thema Messsynchronisation finden Sie hier:

• 1EF62: Tipps und Tricks für die Fernbedienung von Spektrum- und Netzwerkanalysatoren
• 1GP79: Top 10 SCPI Programmiertipps für Signalgeneratoren