Get MBLogic at SourceForge.net. Fast, secure and Free Open Source 
	software downloads

Help Topics

Topic Details for Communications Basics

Help - SBus Basics


Overview:

SAIA Ether SBus is an industrial control protocol used by SAIA Burgess. This help page will discuss some of the basic concepts, but does not provide a detailed description of the protocol itself.


Types of SAIA SBus:

SAIA SBus comes both serial and Ethernet versions. The two versions are very similar, but the Ethernet version (known as Ether SBus) has some additional information included in the protocol header. All further references to SBus here are intended to refer to the Ethnet version used by HMIServer.


Communications

Client/Server or Master/Slave:

Like most communications protocols, SBus uses a client/server type protocol. This is also sometimes referred to as master/slave. A "master" is the same thing as a "client", while a "slave" is the same thing as a "server". Typically, the client is the PLC or controller, while the server is a field device such as a valve bank or sensor block.

Station address (or Destination):

The station address or destination is used by RS-232 or RS-485 networks to deliver an SBus message to the correct address on a serial network. Ether SBus also has the station address in its messages, but the Ethernet TCP/IP address is used to decide where to actually delivery the message. If a station address is specified, the client version of HMIServer will include it in its messages. HMIServer itself however will ignore any station address in messages it recieves.

Sequence:

When an SBus message sends a request, it includes a sequence number. This is a number from 0 to 65,535. This number is normally incremented by the client for each request (and allowed to roll over to 0 again when it overflows). This sequence is echoed back by the server. The client can use this number to determine if any messages are being lost or delayed in transmission.

Ethernet Parameters:

SAIA Ether SBus uses UDP/IP communicate over Ethernet. The "standard" port number for Ether SBus is port 5050. However, it is possible to run Ether SBus on alternate port numbers provided that all devices that are participating in the communications can be configured to use the alternate port.


SBus Data Representation:

Data Table

SBus uses the concept of a data table to refer to data. Data tables should be familiar to anyone who has used a PLC. A data table is an array or block of memory used to store data. Data is referenced using data table addresses. SBus data table addresses come in several types. Not all SBus types are supported by HMIServer, but the following are:

Data Table Addresses

SBus data table addresses are simply integer numbers. Each address type (inputs, outputs, flags, registers) has its own numbered set of addresses. For example, input 42 and flag 42 are two separate addresses.

HMIServer will recognise up to 65,536 addresses of each type. The number of addresses actually implemented in a particular device (sensor block, valve bank, PLC, etc.) may however be much less that this. Each device designer is responsible for deciding what makes sense for their application. They will then normally supply a "memory map" or list of addresses for their device listing what addresses were implemented, and what each one does.


SBus Commands:

Command Codes:

SBus commands are numerical codes which act as commands to read or write a data table address. The following commands are implemented in HMIServer:

Count:

SBus functions may read or write multiple addresses. The "count" parameter specifies the number of consecutive addresses to read or write.

Maximum Number of Addresses Which Can be Read or Written at Once:

The SBus protocol specifies the maximum number of addresses which can be read or written at one time. This limits the amount of data which must be transferred in a single command to no more than 255 bytes. For flags, inputs, or outputs the limit is 128. For registers, the limit is or 32 registers.


SBus Errors:

When an Sbus message is received by a server it is analysed to see of all the parameters are correct and also if the included checksum is correct. If everything is OK, the server will send a response. This response may consist of data, or it may just be an acknowledgement that the message was received.

If there are any error however, the server may do one of two things. If the message could not be decoded at all (e.g. there was a bad check sum), the message is simply discarded. If the message could be decoded but one or more parameters was incorrect (e.g. an attempt was made to read a non-existent address), then the server will send a response containing a NAK code. Although there are several different NAK codes, only NAK code "1" is applicable when reading or writing data. HMIServer will simply treat any non-zero NAK code as an unspecified error.