The BCC communication protocol has been designed in order to have an efficient communication protocol between Robox devices and Robox application and development tools.

Typical usage

This protocol is never used directly over a communication device but is carried by a lower level transport layer: normally we use our DLE/CRC16 transport layer.

This protocol is intended to be used as a point-to-point communication: multi-point communication is available, for example, by using in conjunction the BCC protocol over TCP/IP network connection.

Message format

The BCC message is divided into two parts:

•an header, of a fixed length, that contain all routing information and message content;

•an optional data area, whose size in contained in header, that contain message specific data.

Message header

The BCC message header is a fixed 9 byte structure with the following informations:

Destination fields (DST,DCH)

These information area used to route the message correctly to the message target.

Source fields (SRC,SCH)

These information are used by the receiver to send answer or other messages back to the sender.

More about destination and source

DST is not intended as target device number, but is only used internally by the software to route correctly the message itself. By default, DST has the following meaning:

•0x00 is used to route to a local connection (begin-point)

•0x01 is used to route to the end-point connection

•0x02 is used to route to a socket connection (begin-point)

•0x03 is used to route special commands for network end-point

•0x04 to 0x7F are reserved to Robox

•0x80 to 0xFF are available for user applications

An example:

If you connect your PC to an RBXM via RS232 standard cable, the begin-point is the PC and the end-point is the RBXM.

When you want to send a message from PC to the RBXM, from a local connection (SRC=0, a begin-point) you send it to (DST=1, the end-point): channel ID are depending on the message type. Note that 0 and 2 area both begin-point.

When an answer come from the end-point, DST and SRC are swapped, so the message is routed back to the local connection (DST=0, begin-point) to the correct original sender. The same example could be applied to the socket connection too.

The DCH field normally is 0 if the message is a new request, or other value as requested by particular group or sequence of messages

Message code (MSG)

This code identify the meaning of the message, and can have a range from 0 to 0x7FFF: the 15th bit is reserved to be used as reply flag: is that message is not handled and the bit is on, a nack or error reply will occur, otherwise if bit is not set the message is simply lost. This bit should avoid some dead-loop condition.

To have more information about the message, see the messages specification.

Note: in message documentation, when the reply bit is required, the message code is printed as 'AS + <msgcode>' (AS indicate the 0x8000 bit), otherwise only <msgcode> is printed.

Data size (LEN)

Specify how many bytes of data are following the message header: if 0, the message has no data. The LEN field can have a value between 0 and 255.

Protocol ID (ID)

This field can be used to avoid wrong and confusing answer for some messages, especially to distinguish multiple answer from multiple query. Normally is used as a cyclic value from 0 to 255.

For each command message (especially type Ack/Nack), the answer PID must be the same of the request, otherwise the answer will be invalidated.

Reserved (RES)

This field (ex DLC) is now reserved for future use.

Please use 0xFF has default value in order to avoid troubles with existing communication devices.

Message data area

The message data area is optional: if not present, the LEN field in the message header is 0. otherwise it specify the exact size in bytes.

The message data area is always transmitted immediately after it's header: an incoming message should not be considered completed until it's full data area (if present) has been received.

Unused or reserved fields inside data area (and data size field) must be zero filled.