1. 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.
1.1 Conventions used and list of acronyms
Numbers starting with a "0x" prefix are hexadecimal numbers. Otherwise they are decimal numbers.
1.2 List of Acronyms
PDU Protocol Data Unit
RTU Remote Terminal Unit
MBAB Modbus Application
TCP Transmission Control Protocol
IP Internet Protocol
CRC Cyclic Redundancy Check
2. 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.
2.1 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:
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.
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 as explained in section 3.1.
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
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.
2.3 Hardware connection
The bottom side of the nx interface gateway gives the access to several connections shown
Electrical interface: RS-485i Connector type: Phoenix MC 1,5/ 4-G-3,5
Electrical interface: LAN/ Ethernet Connector type: RJ-45
3. 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 dependent on the version of this Object Model. This version can be found on the first page 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
3.1 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.
3.2 Unicast adresses
Unicast accesses enable the possibility to access a single object group instance in the
3.3 Mutlicast adresses
Not currently planned
3.4 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.
For both read and write operations, a rate limitation mechanism has been implemented to avoid flooding the device with requests. The limitation has been fixed to 20 [req/s] and must be followed by the master.
If the time between two requests is not followed, a delay has been added before sending the
response to the master.
4. 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 always contains 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
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.
4.1 Read object properties: read multiple holding registers
All properties accessible from a next gateway (e.g., 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 gateway will send back an exception.
4.2 Write object properties: write multiple holding registers
All properties accessible from the gateway 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 gateway will send
back an exception.
4.2.1 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 gateway will send back an exception and won’t execute the Write access.
5. Example code and available library
Studer Innotec provides a free Python library that enables access to next devices through
Modbus (RTU & TCP). This library also contains example code for easier integration.
These resources are available at this address: https://github.com/studer-innotec/next-modbus