Difference between revisions of "DIN Rail BUS Protocol"

Revision as of 18:06, 21 November 2013

Template:Under construction

Railbus Protocol

The Railbus Protocol is designed to be as flexible as possible while being as easy as possible.

All data is transmitted on the RS485 with a baudrate of 9600Baud; 8N1 as printable ASCII characters. Any data is converted into the corresponding hexadecimal notation.

Packet Layout

Every packet has a fixed length and is created as defined here:

MW - Magic word

The magic word is prepended to every packet and always consists of the two characters 'R' and 'P'.

ADDR - Modul address

Each modul on the bus has a address. In its delivery-state, a modules address is set to 0. On modules equipped with a BCD-Display, the modules address is shown there. The modul address is one byte long and is transmitted as two characters.

CM - command

The command consists of one byte, either an 'R', 'W', 'S', 'K', 'I' or 'N'. The value is not converted to hexadecimal notation. These command characters are not valid hexadecimal digits and therefore can not show up in the rest of the packet.

The different characters define the type of the packet, as shown in the following table:

SADR - Sub address or register address

The sub-address 255 is used for identifying a device and setting the module address. The sub-address 254 is used for communication settings like CRNL append or baudrate. Other sub-addresses are interpreted device specific.

Write requests to read only registers are NACKed by a special nACK with status code "Forbidden", so are read requests to write only registers. Not implemented addresses should respond by an Not Acknowledge.

SADR255 - Modul identification

Layout :

Reading the register will transmit the Devices ID and its current address. On writing the address the 24 higher bits are ignored and only the address will be set to a new value. The corresponding ACK will use the old address but new commands are only accepted on the new one.

The IDs can be like "R66" for the Din Rail Relais 6I6S.

SADR254 - Communication Settings

Layout:

This register is not implemented on all Devices. Default state is all zeroed. If bit noCRNL is set the device suppreses appending of CRNL to packets. If bit noOUT is set the device does not send anything at all.

DATA - the register data and (N)ACK types

In the 'K', 'I' and 'W' modes this field consists of 32bit hexadecimal notated data representing the register content and is transmitted in eight characters. In the 'n' Mode this field contains information about the type or reason for the (N)ACK.

CHK - Checksum

The checksum consists of one byte of data, transmitted as two hexadecimal notated characters. If the MSB is set, the checksumming is enabled, using CRC7 on all of the preceeding data. If the MSB isnt set, checksum is ignored.

Usage

A write should be repeated as long as no corresponding (N)ACK is received. Devices should execute each Write command only once but deliver an Special ACK for each received copy. The special sync command counts as a write command and as such breaks this loop. If currently a command is processed and therefore the queue couldn't be cleared, the Sync is NACKed.

Only one write can be executed at once. Reads can be executed any time.

Special ACKs 'n'

• DATA: 0x01 - ACK Received. The command was received and will be executed.
• DATA: 0x02 - ACK Retransmission. The command was received is currently executed.
• DATA: 0x03 - ACK Done before. The command was already received and finished.
• DATA: 0x06 - NACK Unknown. Unknown Register.
• DATA: 0x07 - NACK Forbidden. Read on Writeonly Register or Write on Readonly one.
• DATA: 0x08 - NACK Busy. Write received but already executing command.
• DATA: 0x09 - NACK Invalid. Command could not be executed. Invalid Data.
• DATA: 0x0A - NACK Error. Command aborted.
• DATA: 0x0B - NACK Abort before. Command was already aborted in the past.
• DATA: 0x10 - ACK Synced. The Sync was succesfully completed.

Railbus Protocol binary extension

the binary extension to the railbus protocol is for automated transmissions of data only.

Packet Layout

Packets using the binary extension do have a variable length and have the following layout:

MW, ADDR and CHKS

the Magic Word and the destination address are encoded like in the railbus Protocol

CM - Command

The command for the binary extension always has the highest bit set to flag the variable packet length.

The defined commands are implementation specific. The command is transmitted as one character.

LENGTH - packet length

The Length field specifies the number of character transmitted for the complete packet. It is a 16bit integer transmitted in 4 hex-coded characters.

SRCA - source address

The source address is defined as the address of the sender. Like the ADDR-field is is transmitted in two characters.

SE - sequence number

An ongoing sequence number. Every packet in an ongoing stream has this field incremented to provide a unique packet identification. The number of the first packet in a stream should be used on a random base.

The sequence number is represented as a 8bit integer, transmitted unencoded in one character.

DATA - variable length data

the rest of the packet consists of unencoded databytes.

Examples

Request for current Status on a DIN Rail Relais 6I6S

For reading the current status on a Relais 6I6S, the first line of the following listing should be send; the board will answer with the second line.

 RPFFR0000
 RPFFK000015002A00

1. Every packet starts with the magic characters R and P.
2. The next two characters contain the hexadecimal encoded address of the board. In this case, the board listens at the address 0xFF (or 255 in decimal notation).
3. Following the address, the command is transmitted
   • In case of the Read Request, an R is transmitted
   • In case of the Read Acknowledge - the answer of the board - an K is transmitted
4. Next the SADR is put on the line. In this example the register 0 is accessed.
5. Only in the Read Acknowledge, 8 characters forming 4 Bytes of data are transmitted. In this case the state of the inputs and outputs is transmitted.
   • In the second Byte of the data, representing bit 23-16 of the register, the state of the inputs is shown. Here DIGIN1, DIGIN3 and DIGIN5 have a voltage detected.
   • In the forth Byte, representing bit 7-0 of the register, the state of the outputs is shown. Here REL2, REL4 and REL6 are on.
6. The last two characters contain the checksum. In this case, the dummy-checksum '00' is used. This means no validity checking is performed.

Adding a valid checksum

The checksum is calculated as CRC7, like used in communication in MMC or SD-Cards. The theory is described in Wikipedia:Cyclic redundancy check. This CRC7 is or'ed with a 0x80, to have the highest bit set and enable the checksum-checking.

To calculate the checksum, the function crc7_calc in the following code can be used:

const unsigned char crc7_table[16] = {
	0x00, 0x12, 0x24, 0x36, 0x48, 0x5a, 0x6c, 0x7e,
	0x90, 0x82, 0xb4, 0xa6, 0xd8, 0xca, 0xfc, 0xee
};

static unsigned char crc7_next(unsigned char crc, unsigned char dat)
{
	crc ^= dat;
	crc = ((crc << 4) & 0xff) ^ crc7_table[crc >> 4];
	crc = ((crc << 4) & 0xff) ^ crc7_table[crc >> 4];
	return crc;
}

unsigned char crc7_calc(const unsigned char *dat, unsigned short len)
{
	unsigned char crc = 0;

	if (len) do {
		crc = crc7_next(crc, *dat++);
	} while (--len);

	return (crc >> 1)|(1<<7);
}

Changelog

v2.1

• Reserved Register 0xFE for Communication Settings

v2.0

• added Packet Type 'S' (Sync)
• added Packet Type 'n' (N)ACK with reason
• Section 'Usage'

v1.0

• initial release