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
|
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.
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.
