Details zum S-Bus Treiber

Dieses Kapitel ist für fortgeschrittene WinCC OA Anwender. Es beschreibt die Debugmöglichkeiten für den WinCC OA S-Bus Treiber.

Debug Levels

Um mögliche Fehlerquellen bei einem laufenden Treiber zu erkennen, können die folgenden Kommandozeile-Optionen für die Fehlersuche verwendet werden.

Debug Beschreibung
-dbg array Debug Flag für Informationen zu Array Objekten
-dbg conn Debug Flag für die Verbindung des S-Bus Treibers mit der PCD
-dbg queues Debug Flag zur Ausgabe von Informationen zu den vom Treiber verwendeten Queues.
-dbg recv Debug Flag für empfangene Informationen
-dbg send Debug Flag für gesendete Informationen
-dbg verb Debug Flag für umfangreiche Informationen

Aufbau S-Bus Ethernet Telegramm (UDP)

Tabelle 1: Aufbau UDP Paket für S-Bus

S-Bus Header S-Bus
UDP Header inkl. CRC L V T S AT S-Bus Adr., S-Bus Befehl, Wert S-Bus CRC

Bezeichnung Beschreibung Größe (Bytes)
L* Länge Die Länge des S-Bus Telegramms inklusive Header und CRC 4
V* Version Protokollversion 1
T* Protokoll Typ Protokoll Typ, dient zur schnelleren Erkennung des Protokolls (S-Bus = 0) 1
S* Sequenz Sequenz Nummer. Wird pro Telegramm im Client um 1 erhöht (wenn es sich um kein erneut gesendetes Telegramm handelt) 2
AT Attribut Char

Gibt an welcher Typ Telegramm es sich handelt. Werte, Antwort, ACK/NAK

  • 0 => Anfrage

  • 1 => Antwort

  • 2 => ACK/NAK

1
S-Bus Adresse, S-Bus Befehl, Wert S-Bus Telegramm Max. 130
CRC Checksumme über die gesamten Werte mit Header und AT 2

* = Header

Beispiel

Nachfolgend zwei Beispiel-Pakete der S-Bus Kommunikation

S-Bus Station 75 (A: 4B hex) erhält den Befehl: Read Register (C:06 hex) 0 (Count: 0 (= 1Element), Data: 0 hex).

L V T S AT S-Bus CRC
A C Count Data
00 00 00 10 00 00 00 B6 00 4B 06 00 00 00 DC 62

S-Bus Station 75 antwortet: Wert von Register 0 ist 305419896 (Data: 12345678 hex).

L V T S AT S-Bus CRC
Data
00 00 00 0F 00 00 00 B6 01 12 34 56 78 3E 81

ACK/NAK Antwort Format

Die folgende Tabelle gibt Auskunft über mögliche Antworten für den Empfang eines S-Bus Telegramms.

Tabelle 2: ACK/NAK Antworten

AT (1 Byte) Anwort (2 Byte) Bedeutung
0x02 0x0000 ACK
0x02 0x0001 NAK
0x02 0x0002 NAK aufgrund des Passwortes
0x02 0x0003 NAK aufgrund fehlerhafter Konfiguration des Ports
0x02 0x0004 NAK aufgrund einer inaktiven PGU

Erweiterte Referenzeinträge

Erweiterte Referenzeinträge können für die Adresstypen Register (R), Text (X) und Datenbaustein (DB) vorgenommen werden und dienen der Beschränkung der Textlänge (Adresstyp Text) oder der Definition von Array Adressen (Adresstyp Register oder Datenbaustein).

Textlänge

Beim Adresstyp Text kann festgelegt werden, dass nur ein Teil des maximal verfügbaren Bereiches von 256 Bytes gelesen oder geschrieben wird. Dabei können der Startpunkt und die Anzahl der Bytes definiert werden. Die Information wird, getrennt durch einen Doppelpunkt, an die Referenz angefügt.

Beispiel Text-Adresse, lesend: SBusDevice_1.X2:20,5 greift auf die Adresse X2 zu und liest 20 Bytes beginnend an der Position 5.

Array Adressen

Die Definition von Array Adressen erlaubt es, eine festgelegte Anzahl von Adressen zu lesen oder zu schreiben. Die Information (Array-Länge) wird, getrennt durch einen Doppelpunkt, an die Referenz angefügt.

Beispiel Register-Adresse, schreibend: SBusDevice_1.R1:20 beschreibt 20 Register-Adressen beginnend mit Adresse R1, also R1, R2, … R20.

Array Adressen sind für die Transformationsarten Int32, uint32 und float implementiert und werden am DPE als DynArray abgebildet.

Schreiben von Array Adressen

Beim Schreiben einer Array Adresse wird die Anzahl der übergebenen Werte (entspricht der Länge der dynamischen Liste) mit der Anzahl der konfigurierten Array Adressen verglichen. Stimmen die beiden Werte nicht überein, wird eine Warnung im LogViewer ausgegeben, es werden keine Daten auf die SPS geschrieben.

Lesen von Array Adressen

Da das S-Bus Protokoll die Telegrammlänge begrenzt, werden Leseanforderungen bei langen Adressen auf mehrere Telegramme aufgeteilt. Die Antworten auf diese Anforderungen werden vom Treiber wieder zum kompletten Array zusammengesetzt und erst dann auf den Datenpunkt geschrieben, wenn sämtliche Antworttelegramme eingetroffen sind.

Der Config Eintrag Stable Read beeinflußt, auf welche Art das auf den Datenpunkt geschriebene Array zusammengesetzt ist. Bei StableRead = 0 (dem Defaultwert) wird das Array geschrieben, sobald alle Antworten eingetroffen sind, d.h. es können Werte, die auf Grund eines Retransmits empfangen worden sind, in dem Array enthalten sein.

Bei StableRead = 1 wird vor dem Schreiben auf den Datenpunkt überprüft, ob sämtliche Werte Antworten auf den ersten Sendeversuch sind. Ist auch nur ein auf Grund eines Retransmits empfangener Wert dabei, wird das gesamte Array verworfen und neu angefragt.

Anmerkung: Der maximale zeitliche Versatz bei der Verwendung von StableRead = 0 ist ca. 2 x Retransmit Timeout (ca. 1/2 Verbindungstimeout).

Retransmit Protokoll

Durch die Verwendung des UDP Protokolls findet, anders als bei TCP, auf der Verbindungsebene keine Überwachung der korrekten Übertragung von Telegrammen statt. Daher sieht das S-Bus Protokoll einen zweimaligen Retransmit vor. Die SPS muss den Empfang eines Telegrammes mittels ACK bestätigen. Trifft diese Bestätigung innerhalb der Zeitspanne, die durch den Retransmit Timeout festgelegt ist, nicht beim Treiber ein, so wird das betreffende Telegramm erneut gesendet. Nach dem dritten Sendeversuch (dem zweiten Retransmit) unterbricht der Treiber die Verbindung und gibt eine entsprechende Meldung im LogViewer aus. Mit Ablauf des nächsten AliveIntervals versucht der Treiber, die Verbindung erneut aufzubauen.

Fehlermeldungen bei Array Adressen

Die im Folgenden angeführten Fehlermeldungen werden im LogViewer ausgegeben und erlauben es zum Beispiel Pollzeiten und Array-Länge abzustimmen.

Unexpected state, Array object SBusDevice.R1:4 is already in the queue

Diese Meldung bedeutet, dass versucht wird, die Array-Adresse R1:4 abzufragen, bevor alle Antworten für die letzte Abfrage dieser Adresse eingetroffen sind. Tritt diese Meldung gehäuft auf, so kann eine zu kurze Pollzeit die Ursache dafür sein.

Anmerkung: Das S-Bus Protokoll beschränkt die Anzahl von Register-Adressen in einem Telegramm auf 32. Längere Array-Adressen werden auf mehrere Telegramme aufgeteilt. Daher ist es unter Umständen nötig, Array-Länge und Pollzeit aufeinander abzustimmen.