Eaton MTL838B-MBF Analogue Multiplexer Receiver

Modbus message framing

Modbus messages must be structured (or 'framed') so that the different Modbus

components can detect the start, content structure and end point of a message. It also

allows any errors to be detected.

The framing used depends on the transmission mode chosen - ASCII  or RTU.

ASCII message framing

In ASCII mode, messages start with a 'colon' (:), which in hex is '3A'. The message

end is shown by 'carriage return/line feed' (CRLF) or 'OD OA' in hex .

The allowable characters for all other fields are hexadecimal 0-9. A-F. Networked

components monitor the bus continuously for the 'colon' character and when one is

received, they decode the next field (the address field) to find out if the address is for

that slave. If the address is for another slave, then no action is taken, and the slave

returns to monitoring for the 'colon' character. If  the field following the colon is the

address of the slave in question, then the slave continues to read the message and to

act on it's contents.

Intervals of up to one second can elapse between characters within the message, but

if an interval is greater than this, then the device assumes that an error has occurred.

If the delay occurs in the 'query' to a slave, then the addressed slave will discard the

message received up to that point and wait till the next message (marked by the colon

start character) is received.

RTU message framing

In RTU mode, the message begins with a gap in transmission of at least 3.5 character

periods. Network components monitor the bus continuously and when a 'silent' period

of more than 3.5 character periods is detected, the first character following the

transmission gap is translated to determine if it corresponds to the device's own

address.

The end of the transmitted message is marked by a further interval of at least 3.5

character periods duration. An new message can only begin after this interval.

The entire message field must be transmitted as a continuous stream. If an interval of

more than 1.5 character periods is detected during transmission of the message, then

the message is assumed to be incomplete and the device returns to waiting for the

next device address. The action taken on receipt  of an incomplete message is as for

receipt of an incorrect message, and it is ignored.

If a new message begins within 3.5 characters periods of the end of the previous

frame, the device again ignores the message.

The message fields

The address field

Slave addresses may be in the range 1 to 247 with Modbus (1 to 255 with JBUS). A

slave is addressed by the master placing the relevant address in the address field of

the query message. When the slave sends its response, it places its own address in

the message field to indicate to the master that the correct slave is replying.

Address '0' is used for 'broadcast' messages. All suitable slaves read them, but do not

provide responses to such query messages.

The function field

Function codes may be in the range 1 - 255. though not all functions will be supported

by all devices. When a message is sent from a master to a slave, the function code

defines the action that is required from the addressed slave. Examples of action

requested by the various function codes include: read input status; read register

content; change a status within the slave; etc..

When the slave sends its response to the master, it will repeat the function code

received, to indicate that the slave has understood the query and acted accordingly. If

the query instruction could not be carried out by the slave, an 'exception response' is

generated and the function code and data fields are used to inform the master of the

reason for the exception.

The exception response is generated by returning the original function code from the

master, but with its most significant bit set to '1'. Further information regarding the

exception response is passed to the master via the data field of the response

message. This tells the master what kind of error occurred and allows it to take the

most appropriate action - either to repeat the original message, to try and diagnose

what has happened to the slave, to set alarms or to take whatever action is most

appropriate.

The data field

The data field transmits a number of hexadecimal values, each in the range 00 to FF.

In ASCII transmission mode this is made up of a pair of characters, in RTU it is a

single character.

A significant aspect of the communication between the master and it's slaves, that is

not defined by Modbus, is the encoding of numerical data. Modbus allows the

manufacturers of devices to determine which data encoding techniques are available

to users of the device. The encoding of data is discussed on page 13.

The data field is used to provide the slave with any additional information needed to

perform the function requested in the query. This would typically be a register address,

a register range or a value. With some functions, the data field is not required and will

not be included in the query.

If no errors occur, the data field of the response is used by the slave to pass data back

to the master.

If an error occurs, the data field is used to pass more information to the master relating

to the nature of the fault detected.

Byte count data

The responses to a number of queries require the slave to inform the master of the

number of data bytes that are being returned in the response, and this requires a

special implementation within the data field.

A typical example of this would be when the master has requested the slave to

communicate the status of a range of registers. The slave responds by repeating the

function code and it's own address, followed by the data field. The first byte of the data

field identifies the number of bytes that are being returned that contain the register

status information.

As was mentioned earlier, ASCII mode requires two 8-bit bytes to communicate a

single register content, compared to RTU which only requires a single 8-bit byte. This

difference is ignored when the byte count field is calculated, and the number of bytes

indicated is identical to the number of bytes communicated in RTU mode, but is half

the actual number of bytes communicated in ASCII mode.

The error check field

The error checking technique employed on the Modbus network depends on the

transmission mode selected. With ASCII the technique used is based on an LRC

(Longitudinal Redundancy Check) and with RTU a CRC (Cyclical Redundancy Check).

In both cases, the characters transmitted in the error check field are calculated by the

transmitting device and included in the resulting transmission. The receiving device

calculates what the error check field should contain, on receipt of the message, and

compares it with the error check field in the received message. If these two values do

not match exactly, then the receiving device knows that it has not received the

message correctly, and disregards it.

In both modes, parity checking can be optionally selected.

A fuller explanation of the error checking techniques used by Modbus is given in

Appendix A.

Data Encoding and Scaling

As has been mentioned earlier, an important area of the communication along the

network, that is not defined by the Modbus protocol, is the encoding of numerical data.

A related problem is the adoption of a scaling system for the data once it has been

encoded. (Note: this is an area which requires careful consideration by users of the

MTL838B-MBF.)

There is no problem here for manufacturers who are supplying complete systems,

based on the Modbus network, as they can select a data encoding and scaling system

appropriate to their needs. However, for manufacturers who are supplying products for

general use, there is no possibility that they will be able to determine which data

encoding system will be used by their customers, and they must allow the data

encoding technique to be user selectable.

Three data encoding techniques are the most popular - IEEE, 16-bit unsigned and 16

bit offset.

A further area of difficulty associated with the encoding of data is the way in which the

data is scaled - to provide a resolution of the measured value appropriate to the

requirements of  each application.

Users attempting to configure and scale analogue units via the Modbus master and

network may find considerable difficulty with this issue. If specifically designed

software is available for configuration and scaling of Modbus devices, this may be the

simplest and most convenient method of scaling and encoding data. An example

of this is the PCS83 software, which is available from Eaton's MTL product line for

configuring the MTL838B-MBF. This makes encoding and scaling decisions

transparent to the user.

The difficulties of implementing an encoding and scaling regime for the MTL838B-MBF

via the Modbus host are discussed in depth on page 37. Users are strongly

recommended to read this section before selecting the configuration method to be

used with the MTL838B-MBF.