ModSnmp Manual - Modbus Interfaces
The Modbus Interface panels allow you to define one or more interfaces for communicating with Modbus slaves.
The Add Modbus Interface panel (Figure 2, “Add Modbus Interface panel”) enables you to define Modbus interfaces. To add a Modbus interface, enter the following data and then click Apply.
Name. Enter a unique name for the interface. This name will be used in Modbus OID entries to identify the interface to be used.
Interface Type. Select Serial for a RS232/485 serial interface. Select TCP Socket for a TCP/IP network interface. Select UDP Socket for a UDP/IP interface (use of UDP for Modbus is non-standard). Note that the Serial option will only be available if you have the Java Communications API package installed (the → window tells you whether it is installed).
Packet Type. You would normally select RTU if you are using a serial interface, and TCP if you are using a socket interface. You may have to use ASCII for some legacy serial interfaces or devices. It is possible to use RTU or ASCII packets over a socket interface - this is non-standard, but can be useful for software testing. It is also possible to use TCP packets over a serial interface, but there is no good reason to do so (and there would be no error-checking of the packets).
EOM Timeout. Enter the maximum delay (in milliseconds) expected within a message. The default value works fine in most situations, but you may need to increase the value if you are using a serial interface or operating system that introduces large delays in the middle of messages.
The Interface Type and Packet Type together determine the variant of the Modbus protocol that will be used. The table below lists the possible combinations:
| Interface type | Packet type | Protocol variant |
|---|---|---|
| Serial | RTU | Modbus RTU |
| Serial | ASCII | Modbus ASCII |
| Serial | TCP | Not recommended since no error checking (non-standard) |
| TCP Socket | RTU | Modbus RTU encapsulated in TCP (non-standard) |
| TCP Socket | ASCII | Modbus ASCII encapsulated in TCP (non-standard) |
| TCP Socket | TCP | Modbus TCP |
| UDP Socket | RTU | Modbus RTU encapsulated in UDP (non-standard) |
| UDP Socket | ASCII | Modbus ASCII encapsulated in UDP (non-standard) |
| UDP Socket | TCP | Modbus UDP (also known as Modbus TCP encapsulated in UDP) (non-standard) |
Responses. When using Modbus RTU or ASCII over a serial interface, a slave should not respond to a request for a different slave ID (this is necessary for RS485 multi-drop to work). When using Modbus TCP over a TCP socket interface, the slave/bridge should respond to requests to unknown/unreachable slaves with an exception 10 or 11 response. When using non-standard protocol variants (such as RTU encapsulated in TCP), the behaviour in these situations is not defined. You should select Always responds if the slave behaves in the Modbus TCP manner, or deselect it if it behaves in the serial manner.
Number of Retries. This field specifies how many times ModSnmp should retry a request that it has not received a response to.
Response Timeout. This field specifies how long (in milliseconds) ModSnmp should wait for a response before re-trying the request or reporting a failure.
The official Modbus protocol (in both the original Modbus specification and the current Modbus specification) only allows 1-bit and 16-bit integer values to be transferred. Many manufacturers have extended the protocol to allow 32-bit and 64-bit values, and also to allow floating-point values. Fortunately, everyone seems to have used the IEEE format for floating-point numbers, but that is where the agreement ends. The group of settings enables you to configure ModSnmp to handle all implementations of 32/64-bit values that we know of.
Little Endian. Modbus is a "big-endian" protocol: that is, the more significant byte of a 16-bit value is sent before the less significant byte. It seems obvious that 32-bit and 64-bit values should also be transferred using big-endian order. However, some manufacturers have chosen to treat 32-bit and 64-bit values as being composed of 16-bit words, and to transfer the words in little-endian order. For example, the 32-bit value 0x12345678 would be transferred as 0x56 0x78 0x12 0x34. You should select the Little Endian checkbox to use this mixed ordering.
-
Word Registers. Each register in the Modbus protocol holds a single (16-bit) value. The simplest way to extend the protocol to handle 32-bit and 64-bit values is to allow registers that contain these larger values. However, some manufacturers have chosen to keep to the 16-bit register size, and use 2 registers to hold a 32-bit value, and 4 registers to hold a 64-bit value. For example, if a 32-bit value is stored at address 100, then register 100 would hold one half of the value and register 101 would hold the other half of the value. Some devices will actually allow you to access the halves of the value independently; others will only allow accesses that transfer the complete value (thus making address 101 in the example an invalid address).
You should select the Word Registers checkbox to use multiple registers to store large values, and leave the checkbox unselected to use a single register to hold each value. Note that when you use the Word Registers option, ModSnmp will only allow access to complete values.
-
Word Count. Some Modbus requests (e.g function 3 Read Holding Registers, and function 16 Write Multiple Registers) include a count of how many registers/values are to be transferred. There are three possible interpretations for this count:
The number of values to be transferred.
The number of 16-bit words to be transferred.
The number of registers to be transferred.
In the official Modbus protocol, these three interpretations are equivalent, since all values and all registers are 16-bit. When 32-bit and 64-bit values and/or registers are allowed, the three interpretations become distinct. However, the third interpretation will be equivalent to one or other of the first two, depending on the Word Registers setting, so ModSnmp only deals directly with the first two interpretations. You should select the Word Count checkbox if the count is to be interpreted as the number of 16-bit words to be transferred. You should leave the Word Count checkbox unselected if the count is to be interpreted as the number of values to be transferred.
These three options (Little-endian, Word-registers, and Word-count) allow 8 possible variations of 32/64-bit value handling. At least 5 of these variations have actually been used in devices, so you may need to carefully read documentation, or to experiment, to determine which variation a particular device uses. The default settings (all options deselected) should work with Enron/Daniel devices. For Modicon/Schneider devices you will probably need to select all the options.
The following items must be configured for a socket (TCP or UDP) interface:
The same host and port may be used in more than one interface. If this is done, ModSnmp will open a separate socket connection for each interface. This can be useful if you have more than one slave on the same host and port, and want to access the slaves concurrently.
The following items must be configured for a serial interface (Figure 4, “Modbus Interface serial settings”):
Port. Name of the serial port that ModSnmp should use to talk to the slave(s). The same serial port cannot be used in more than one interface.
Parity. It's usual to use no parity, since the CRC in RTU packets is a good error check on its own, but some devices may require it. The serial specification requires even parity to be the default.
Data Bits. Must be 8 for RTU. Some ASCII devices may require 7 (the serial specification actually specifies 7 for ASCII).
Stop Bits. Usually 1, but some devices may require 2. The serial specification actually specifies 2 stop bits if parity is not being used, but this requirement is normally ignored.
-
RTS Control. The default setting of High will be OK for most purposes.
Selecting Flow Control will enable hardware flow control ("handshaking") using RTS and CTS. Since Modbus messages are short, flow control is not normally necessary.
Selecting RS485 will use RTS to control a RS232 to RS485 converter: ModSnmp will raise RTS when it is transmitting data, and lower RTS to receive data. Note that the lowering of RTS may be delayed by the operating system, and this may cause loss of data. For this reason, we recommend the use of RS232-RS485 converters that do not require RTS control.
Details of all the Modbus interfaces that you have added are displayed in the Modbus Interfaces panel (Figure 1, “Main window”).
See the section Defining Modbus Interfaces for explanations of the values displayed in each column.
Modbus interfaces can be deleted using the Modbus Interfaces panel:
To delete a Modbus interface, select the Modbus interface and then click the Delete button.
To delete several Modbus interfaces, select them by clicking on them while holding down the control key, and then click the Delete button.
To delete all Modbus interfaces, click the Delete All button.
A Modbus interface cannot be deleted if it is in use by a Modbus OID entry.
A Modbus Interface definition can be edited using the Edit Modbus Interface panel (Figure 3, “Edit Modbus Interface panel”).
Use the Select Interface drop-down list to select the Modbus interface to be edited, change the values as required, and click Apply to save the changes.