Details of the S-Bus driver

This chapter is for advanced WinCC OA users. It describes the debug options for the WinCC OA S-Bus driver.

Debug Levels

To recognize sources of error when running the driver, following command line options for debugging can be used.

Debug Description
-dbg array Debug Flag for the information of an array object
-dbg conn Debug flag for the connection of the S-Bus driver to the PLC
-dbg queues Debug Flag for the information of the driver's used queues.
-dbg recv Debug flag for received information
-dbg send Debug flag for sent information
-dbg verb Debug flag for verbose information

Structure S-Bus Ethernet Telegram (UDP)

Table 1: Structure UDP Package for S-Bus

S-Bus Header S-Bus
UDP Header incl. CRC L V T S AT S-Bus Adr., S-Bus Cmd, Data S-Bus CRC
Designation Description Size (Bytes)
L* Length The length of the S-Bus telegram including the header and the CRC 4
V* Version The used protocol version 1
T* Protocol Type For faster protocol type recognition (S-Bus = 0) 1
S* Sequence S-Bus sequence number (incriminated on client side for each telegram if it is no retry) 2
AT Attribute Char

To indicate the telegram type of the actual frame. Data frame, response frame or ACK/ NAK

  • 0 => Request

  • 1 => Response

  • 2 => ACK/ NAK

1
S-Bus Adr., S-Bus cmd., Data S-Bus telegram Max. 130
CRC S-Bus CRC (over the whole data including header and AT) 2

* = Header

Example

Hereafter, two example packages of the S-Bus communication are shown.

S-Bus station 75 (A: 4B hex) receives the command: Read Register (C:06 hex) 0 (Count: 0 (= 1 element) 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 response: value from register 0 is 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 response format

Following table gives information about possible responses for a received S-Bus telegram.

Table 2: ACK/ NAK response

AT (1 Byte) Response (2 Byte) Meaning
0x02 0x0000 ACK
0x02 0x0001 NAK
0x02 0x0002 NAK due to password
0x02 0x0003 NAK due to incorrect port configuration.
0x02 0x0004 NAK due to inactive PGU

Extended reference entries

Extended reference entries can be used for the address types register (R), text (X) and data building blocks (DB) and are used to restrict the length of text (address type text) or for the definition of array addresses (address type register or data building block).

Length of text

The read and write length of the address type text can be restricted to a certain part of the whole adress block (maximum size of the block is 256 bytes). The starting point and the number of bytes that must be read can be specified. The information must be added to the reference, parted by a semicolon.

Example: text address, reading: SBusDevice_1.X2:20,5 access address X2 and reads 20 bytes starting at position 5.

Array addresses

The definition of array addresses allows to read or write a defined number of addresses. The information (array length) is added to the reference, parted by a colon.

Example: register address, writing: SBusDevice_1.R1:20 describes 20 register addresses starting with R1, i.e. R1, R2, R3, ... R20.

Array addresses are available for the transformation types int32, uint32 and float and will be presented as dynArray on the DPE.

Writing Array Adresses

When writing array addresses the number of stated values (corresponding to the length of the dynamic array) is compared with the number of configured array addresses. If the numbers don't match a warning will be sent to the LogViewer and no data will be sent to the PLC.

Reading Array Adresses

Reading requests for long addresses are split into multi telegrams due to length restrictions of the S-Bus telegram protocol. The answers to the request is merged by the driver to the complete array and only written to the data point after all telegrams are received.

The config entry StableRead defines how the array is merged and written to the datapoint. SteableRead = 0 (default) defines that the array is written as soon as all answers arrive, i.e. values form a retransmit can also be part of the array.

StableRead =1, all received values will be checked if they are from the same reading request. If a value from a retransmit is received, then the array is dropped and a new request is sent.

The maximum time offset when using StableRead = 0 is approx. 2 x Retransmit Tim-out (approx. the half connection time-out).

Retransmit Protocol

The S-Bus driver uses a UDP procotcol and unlike to a TCP protocol, no monitoring of a correct delivery of telegrams is performed on the connection layer. Due to this circumstance the S-Bus protocol can send up to two retransmits. The PLC must acknowledge the receiving of a telegram. If the driver doesn't receive an acknowledge within a defined time span (retransmit time-out), a retransmit will be performed. After the third attempt of transmission (the second retransmit), the driver will disconnect and issues an appropriate notification in the LogViewer. After the next AliveInterval, the driver tries to establish a connection again.

Error messages of array addresses

Following error messages can be found inside the LogViewer and can be used to adjust poll frequency and array length.

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

The messages indicates that a read request has been sent to the address R1:4 before the answer of the last read request has been received. If this error messages appears multiple time it can indicate that the poll frequency must be adjusted.

The S-Bus protocol restricts the number of register addresses inside a telegram to 32. Longer array addresses are split into multiple telegrams. Due to that fact the array length and poll frequency must be adjusted to this circumstance.