schneiderModbus Master (Serial and TCP/IP) Driver for Field Device System Integrator Modules

technology. Using an Ethernet network, you can 

provide remote access to process data over the 

network.

Redundancy

A pair of FBM231 or 233 modules combine to 

provide redundancy at the FBM level. In redundant 

configurations, one FBM serves as the Master 

module and the other as the Tracker module. (Both 

are Modbus Masters on their respective networks.) 

A communication link between the two modules 

allows each module to monitor the other's health and 

to share information about the health of the attached 

slave devices. For illustrations of typical 

configurations in which redundant FDSI FBMs 

communicate with serial and Ethernet Modbus 

devices, refer to PSS 21H-2Z31 B4 and 

PSS 21H-2Z32 B4.

Detection of communication issues between the 

FBM and the field are determined by the device 

heartbeat or scan message. 

If a message is missed, up to two retries are 

performed. If the retries fail, the device is marked as 

failed in System Monitor displays.

If a device failure is detected, the Master requests an 

automatic role switch and generates a system alarm. 

Role-switching occurs without a loss of data. 

Alternatively, you can initiate a role switch between 

Master and Tracker modules manually using 

I/A Series System Monitor.

If any one FBM fails, the failure is indicated in System 

Monitor. If a role switch has occurred and you are 

running with a failed FBM, the new Master will 

continue to detect and alarm device failures. 

When the System Monitor alerts you to FBM or 

network connection failures, you can then replace the 

faulty FBM or repair the network connection without 

upsetting field input or output signals on the 

functional side. When a failure occurs, it is 

recommended that you repair or replace the faulty 

component as soon as possible to prevent possible 

loss of data if another failure should occur.

Custom Drivers

Device-specific drivers can be created for unique 

process requirements. For example, a custom driver 

can be created to support Modbus slave devices, to 

perform non-standard data type conversions in 

systems that utilize a combination of data types, or to 

support non-standard Modbus protocol 

implementations. Contact your local Invensys 

Foxboro sales representative for information on 

specific custom drivers that may be available for your 

system.

Diagnostics

System Monitor watches for loss of communication 

between the Modbus field devices and the FDSI 

FBM. FBMs scan their connected devices at a userspecified time interval. If the FBM does not receive a 

response from the device, System Monitor displays 

show that the device has failed. 

The driver can be configured to send heartbeat poll 

messages to devices that support function code 8. 

This enables you to monitor device connection.

OVERVIEW OF MODBUS TECHNOLOGY 

The Modbus Protocol was introduced by GouldModicon® in 1979 as a proprietary message 

structure and format that allowed communication 

and transfer of control data between intelligent field 

devices via RS-232. Modbus/TCP was introduced 

later by Schneider Automation® to support Ethernet 

TCP/IP as an additional data transmission 

technology for the Modbus protocol. 

Today, Modbus has evolved into a globally accepted 

and widely used standard for communication 

between multi-vendor field devices. The Modbus 

protocol specifies the master-slave/query-response 

message structure that controllers can recognize and 

use.

Messaging Operation

Query messages, sent by Modbus masters to 

devices, include a destination address, a task 

request indicated by a “function code”, and any 

supporting data required for the slave to carry out the 

assigned task. The message can be sent directly to a 

particular slave by including its unique address in the 

message. 

After receiving a query message from the master, the 

Modbus device responds with a message. The 

response message specifies whether or not the 

requested action was successfully performed and 

confirms that the correct Modbus device responded 

to the requested action. The response message also 

returns any data requested by the master.

Query and response messages both contain error 

checking mechanisms that allow devices to confirm 

the integrity of the query message and allow the 

master to confirm the integrity of the response. If the 

error check is not correct, the associated query or 

response message is ignored and the transaction is 

retried. 

Modbus Master Device Driver Operation

Modbus “function codes” specify the types of actions 

the Modbus devices must perform. The following 

Modbus function codes are supported by the FDSI 

Modbus Master Driver:

* Data diagnostic code only.

You do not need to specifically configure Modbus 

transactions, which makes driver configuration very 

easy. By defining the necessary device register