modbus next

v1.0

What's Modbus? 

Modbus is a general communication term that includes a lot of things. There are two physical layers to transmit MODBUS: RTU (=RS485) and TCP (on local ethernet network). Each device has its own way to speak MODBUS: it is the specific list of registers. To communicate in MODBUS with one device, the list must be adapted and it requires development. It is not plug and play because it is not standardized. A device can have two positions in a MODBUS communication: it can be master (initiates requests) or it can be slave (only answers to requests).

This technical specification describes the "Studer Next Modbus Protocol". This protocol enables the control of a Studer Next system from a third party device (PLC, SCADA, etc.). Using this protocol, it is possible to read and write properties.

Conventions used and list of acronyms

Numbers starting with a "0x" prefix are hexadecimal numbers. Otherwise they are decimal numbers.

PDU        Protocol Data Unit

RTU        Remote Terminal Unit

MBAB    Modbus Application

TCP        Transmission Control Protocol

IP            Internet Protocol

CRC        Cyclic Redundancy Check

Modbus Implementation

The next gateway device offers a way for installers/integrators/developers to access and control a Studer next system using the Modbus RTU protocol. The Modbus protocol is standard and well known and used in the industry field. For more information regarding Modbus, please see the Modbus official web page: www.modbus.org.

Protocol Overview

The Modbus application protocol defines the Modbus Protocol Data Unit (PDU) which is independent of the communication layer. This PDU has the following format: 

RTU

On RS-485, the standard Modbus PDU is encapsulated, and fields are added in order to make communication possible over a serial line. 

                 

The Slave Address field (8 bits) is used by the Modbus Master to access a slave device on the bus as explained in section 3.1. The CRC field (16 bits – CRC16 Modbus as described into the 6.2.2 chapter of Modbus_over_serial_line_v1_02.pdf document) with the low byte first and high byte second is used to check if the frame transmission is done successfully. 


TCP

By using Ethernet or Wifi as physical layer, a TCP/IP connection is available. A new 7-bytes header called MBAP (Modbus Application Header) is added to the standard Modbus PDU.

                 

 The Transaction Identifier (2-bytes) is set by the client to uniquely identify each request. The Protocol Identifier (2-bytes) is also set by the client and always equal to 0x0000. The Length field allows to know the number of bytes contained in the PDU message. Finally the Unit identifier is equivalent to the slave address used by Modbus RTU. This field is the identifier of the remote slave. 

Configuration

Next gateway has several Modbus configurations according to the server mode. The Modbus configuration page is available under “Monitoring”. By default, both RTU and TCP servers are disabled:

                 

When selecting a mode, several properties will be displayed in this view. Some properties are common to both servers:

                 

Hereafter is the view of the RTU configuration and the specific properties list: 

                 

 

Hereafter is the view of the TCP configuration and the specific properties list:

                 

Frames endianness are defined by the Modbus standard and are big endian, so MSB (Most Significant Byte) is sent first on the medium. For example, a 16 bits value of 0x1234 will be send 0x12 then 0x34 on the medium. 

Hardware connection

The bottom side of the Nx-Interface gives the access to several connections showed below:

Modbus RTU: 

Electrical interface: RS-485i Connector typePhoenix MC 1,5/ 4-G-3,5

Modbus TCP: 

Electrical interface: LAN/ Ethernet Connector type:  RJ-45

Modbus for next system

The Modbus for next system is based on the next “Object Model” datamodel, that is described in the appendix. Note that accessing a next installation using Modbus is dependant on the version of this Object Model. This version can be found in the appendix. 

After a major update of the next system, with a different Object Model version major number (the left number, e.g. going from 6.41 to 7.0), the devices addresses can change, and the properties register addresses can change as well. Therefore, always make sur that the version in this documentation appendix has the same major version as the version shown by your next gateway device. 

Also, as a good practice, always start your Modbus controller program by reading the Object Model version property of your gateway device, and check that the major version number (left number, most significant 16bits of the property) matches the one you used during implementation. 


Addressing Studer devices 

The “Slave Address” field for Modbus RTU, or “Unit ID” field for Modbus TCP is used to identify the “Object Group” instance that needs to be accessed. 

“Object Group” concept is used to describe part of the system in a generic way (same concept as Object Oriented Programming). A list of all Object Groups and their content can be found in the appendix. Note that the first Object Group is at offset 1, to prevent using the slave address 0, which is reserved for broadcast use in Modbus protocol. Broadcast is not supported by next devices. 

For example, the “System” Object Group is at address offset 1, therefore if you set the “Base address” property to 0, you can access the “System” group at device address 1. 


Unicast adresses

Unicast accesses enable the possibility to access a single object group instance in the installation.


Mutlicast adresses

Not currently planned


Response delay

The response delay of the gateway could be up to 1 second. This is a good value for a timeout in the master implementation. 

The response delay depends on the internal Studer bus load (number of devices). It is strongly recommended not to spam the gateway with multiple requests. The correct way to communicate with the gateway is to send a request and to wait for the response before sending the next request. If no response comes from gateway after a delay of 1 second, we can consider that the timeout is over, and another request can be sent. It is also how Modbus is intended to work.

A rate measurement for read operations has been performed with one device connected to the gateway. The results are detailed hereafter for different settings:

  • Modbus TCP: ~150 [requests per second]

  • Modbus RTU (baudrate at 9600baud): ~25 [req/s]

  • Modbus RTU (baudrate at 115200baud): ~55 [req/s]

The rate has been measured by sending 1000 read requests to the gateway and by measuring the total time needed for these operations. These results should be taken with caution and may vary according to the settings or the number of devices.   

Studer next modes function code

Studer Innotec next properties are accessible using Modbus Function code. The following table maps the next system function to the Modbus Function code. 

                 


Modbus uses the same mechanism between the function code to access registers. The request sent by the master contains always the Function Code, the Register Starting Address and the Quantity of Registers to be access. Some more information can be mandatory inside the request depending on the Function Code. Please see Modbus specifications for more information. 

Modbus Request general structure : 

                 

Modbus registers are defined as 16 bits registers. These registers are accessible using a 16 bits register address. For the Studer Innotec implementation, values are mostly encoded in 32 bits float format. So it will be needed to read/write 2 consecutive 16 bits registers to perform the full transaction (read/write parameter or read user info). Modbus register address have been defined for every parameter and user info. 

Please see the “Technical specification – Next Modbus appendix v10.34.pdf” to get the full list of Modbus register. 

Read object properties: read multiple holding registers

All properties accessible from nx interface can also be accessed with the Modbus protocol. The corresponding Modbus function code to read properties is Modbus Read Multiple Holding Registers. The “Quantity of Registers” need to be set to the size of property, otherwise the nx interface will send back an exception.


Write object properties: write multiple holding registers

All properties accessible from nx interface can also be accessed with the Modbus protocol. The corresponding Modbus function code to write properties is Modbus Write Multiple Registers. The “Quantity of Registers” need to be set to size of property, otherwise the nx interface will send back an exception.

Write access limitations

By default, the write operation is performed on the volatile memory (RAM). After a restart of the installation, the properties are reset to the values contained in persistent memory. To avoid reducing the persistent memory lifetime, the possibility to write properties in the persistent memory is limited. If the user wants to write persistently a property, he must firstly write a specific property related to modbus: 

- Group: NextGateway

- Object: Modbus server

- Property: "write persistently with Modbus"

For the correct device and property addresses, please refer to the appendix. In order to prevent a user forgetting to quit the “write persistent” mode, a timeout of 60s will force to quit the “write persistent” mode and come back to default mode with volatile memory write operations. 

Since the “Write persistent” mode is designed to be used only at very low frequency for parameters saving operations, there is an additional security implemented. If the user performs too many write accesses (currently set to 20 per minutes) in “write persistent” mode, the nx interface will send back an exception and won’t execute the Write access.