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 is only available on Windows and Linux operating systems (the Help → About window tells you whether the serial library is loaded).

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 it is used by some serial-TCP converters and can also 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 an operating system) that introduces large delays in the middle of messages.

Idle timeout. Period in seconds after which a connection will be closed if idle. A value of 0 will disable the timeout.

A connection to a slave device is considered to be idle if no valid responses have been received from the device within the timeout period.

Setting an idle timeout can be used to avoid holding on to resources that are not currently in use. It can also be useful for recovering from some error conditions.

Responses. When using Modbus RTU or ASCII over a serial interface, a slave should not respond to a broadcast request or 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 all requests, including broadcasts and requests to unknown/unreachable slaves (responding to the latter 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 you want the Modbus TCP behaviour, or deselect it if you want the serial behaviour.

Host. Enter the host name or IP address of the slave (or Modbus bridge/gateway).

Port. Enter the port number that ModMaster should connect to on the slave host (or Modbus bridge/gateway).

Local host. You would normally leave this field empty. However, if you are using a computer that has multiple network interfaces, you can enter the host name or IP address of one of the network interfaces to force that interface to be used for the connection to the slave.

Local port. You would normally leave this field set to 0, which allows dynamic allocation of the local port to be used for the connection. However, some firewalls or NAT (Network Address Translation) systems may require you to set a specific port.

Port. Select or enter the name of the serial port that ModMaster should use to talk to the slave. If (during testing) the connection between the master and slave is between two serial ports that are both on the same machine, then you must obviously use different port names for each. Don't forget to connect the two ports with a cable!

Speed. Select or enter the speed in bits/second. Note that serial interfaces and drivers vary in the speeds that they support.

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: ModMaster 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.