Modbus next 

Technical specification

v 1.8

1. What's modbus? 1.1 Conventions used 1.2 List of acronyms 2. Modbus implementation 2.1 Protocol overview 2.1.1 RTU 2.1.2 TCP 2.2 Configuration 2.3 Hardware connection 3. Modbus for next system 3.1 Addressing Studer devices  3.2 Unicast adresses 3.3 Mutlicast adresses 3.4 Response delay 3.5 Memory considerations when piloting a next system 4. Studer next mode function code 4.1 Read object properties: read multiple holding registers 4.2 Read object properties from NVM : read input registers 4.3 Write object properties: write multiple holding registers 4.3.1 Write access limitations 5. Example code and available library


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

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

NVM       Non-Volatile Memory

RAM        Random-Acess Memory (volatile)

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: 


2.1.1 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 Modbus for next system. 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. 


2.1.2 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 as explained in section Modbus for next system.

2.2 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. 

2.3 Hardware connection

The bottom side of the nx interface gateway gives the access to several connections shown below: 

Modbus RTU: 

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

Modbus TCP: 

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 implementation. 


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 installation. 

3.3 Mutlicast adresses

Not currently planned

3.4 Response delay

The response delay of the gateway is usually a few milliseconds. However, it depends on the internal Studer bus load (number of devices, datalog transfer time, etc …). 

In extreme cases, this delay can be up to 1 second. This value must be taken into account when choosing a timeout duration in the master implementation. 

It is strongly recommended not to flood 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. It is also how Modbus is intended to work. 

If no response comes from gateway after a timeout delay, we can consider that the timeout is over, and another request can be sent. This timeout delay value must be bigger than the timeout value of the gateway (1s.). For example, a good timeout value in the master implementation could be 2s. 

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 

3.5 Memory considerations when piloting a next system

When an external system pilots a next system by Modbus, the original configuration (factory default or value set by the installer/user) is altered. When the external system “stops” the piloting, it must make sure the system gets back to the original configuration for optimal functioning. 

This original configuration is saved in the device in the Non-Volatile Memory (NVM), that has limited lifetime in term of write cycles. All configuration parameters are also kept in RAM in the device, these RAM values are the ones used for the device functioning. 

When piloting a next installation, the controller can write the new consigns at relatively high frequency to the device, therefore it must write the values in RAM only, and let untouched the original configuration in the NVM. For this reason, the default Modbus write mode writes only in RAM, as explained in section 4.3.1. 

For reading settings values from a next system, the recommended way is to read the value in RAM since this operation is faster and gets the value currently used by the system. See section 4.1 for indications on values reading. It is also possible to read the original values from NVM (section 4.2), but this operation is to be used only in particular cases, like restoration process described hereunder.

3.5.1 Restoration of original configuration

NOTE: The functions described in this section and its subsections are available only for next firmware versions equal to or bigger than v. 1.3.32.0. 

The external system that pilots a next system needs to restore the original configuration when the piloting is stopped (Manual restoration). Also, the next system has an automatic timeout mechanism that restores the original configuration when it detects that the piloting has stopped.

 3.5.1.1 Automatic restoration (timeout mechanism)

When the function is enabled, the next system measures the time after each write (in RAM)
access from the piloting system. When this timer reaches a certain timeout value (userconfigurable) without subsequent write access, the next system considers that the external 
controlling device lost connection or stopped unexpectedly.

In this case, the next system launches the restoration function. This function will reset all 
properties modified by previous write (in RAM) accesses to their original (NVM) values.
It is also possible for the external controller to manually launch the restoration function, by 
writing to property 20.1.28.4 described below.


Properties used for configuring the automatic restoration can be found in the SystemView 
object (20.1.28) of the NextGateway group. Here are these 3 properties :

  • Property 20.1.28.2 : “Enable timeout for ext. control”
    • When set to “true”, the automatic mechanism is enabled.
  • Property 20.1.28.3 : “Ext. control timeout duration”
    • Contains the value in seconds used for the timeout (default is 15 minutes, so 900 s.)
  • Property 20.1.28.4 : “Reset external modifications”
    • This property is of Signal type, when it is written it will trigger the restoration process and reset all properties to NVM value

For the correct device and property addresses to be used for Modbus access to these 
properties, please refer to the appendix. If these properties are configured by Modbus access, 
it is advised to write them permanently in NVM so that the settings will be kept after a system 
reboot (e.g. after an update).

3.5.1.2 Manual restoration

In order to manually trigger the restoration process, the controller can perform a write operation 
on property 20.1.28.4 “Reset external modifications” described above.

Alternatively, if the controller needs to restore the original values only for some specific settings, 
the controller can read the original value from NVM for a property using the “Read Input 
Registers” function code. Then it can write this value to the setting using the “Write Multiple 
Holding Registers” function code.

4. Studer next mode 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 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" to get the full list of Modbus register. 

 Pdf v.10.127               

html v.10.127              


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 Read object properties from NVM : read input registers

NOTE: This function is available only for next firmware versions equal to or bigger than v. 1.3.32.0. 

Same operation as described in section 4.1, but this alternative is a slower read operation that retrieves the property value from the device’s Non-Volatile Memory (NVM). For this function code, the Quantity of Registers needs to be set to the size of the property as well. 

For reading a property, the Modbus user should always use the “Read Multiple Holding Registers” function code. The “Read Input Registers” function code should be used only in specific cases, like restoration of original value described in section 3.5.1.

4.3 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.3.1 Write access limitations

As explained in section 3.5, by default the write operation is performed on the volatile memory (RAM). After a restart of the installation, the properties are reset to the original values contained in persistent memory (Non-Volatile Memory or NVM). 

To avoid reducing the non-volatile memory lifetime, the possibility to write properties persistently 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 by Modbus” 
  • Value to be written: true (boolean property) 

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 (value of the property will be back to “false”). 

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