Modbus networks are ID-based control networks, which means that all messages sent over the network must be tagged with the ID of the target slave. Modbus network IDs can range from 0 to 255, although zero is used as the broadcast message address, and 248 to 255 are reserved for future use. This means that the "legal ID range" is from 1 to 247.

Whereas slaves are identified by an ID, masters on the network do not need an ID. In fact, Modbus uses master-to-slave (or client-to-server) communication, in which case the masters on the network send requests to the slaves. Masters do not communicate with each other, and the same rule applies to slaves.

In the old days, the Modbus protocol required devices to be installed in master and slave pairs.

When multi-dropped RS-485 networks were introduced, we could chain slaves together in a series of up to 31 devices. However, it was still the case that only one master could be connected to the network at the same time. The most logical way to connect the slaves in the to Ethernet masters isto use a one-port gateway, as illustrated below.

The gateway works like a message relay device, in that all requests from the Ethernet are passed through the gatesay's one serial port. The limitation to this setup is that there can only be 31 or fewer slaves connected to the RS-485 serial network. If we want to control more nodes in the system, we need to use a multi-port gateway, as illustrated below.

Multiport Modbus gateways can also be used, but you might wonder how the gateway dispatches requests to the right serial port. In this case, and in reference to the above figure, requests to ID=2 would be sent through port 1 on the Modbus gateway (provided port 1 is port that connects to slave labeled ID=2).

Solution 1:
The first way to accomplish this is by assigning one TCP socket to each serial port. In this case, you would need to modify the program on the TCP master to use different TCP port numbers to distinguish the different connections. For example, you might assign TCP port 502 to serial port 1, TCP port 503 to serial port 2, and so on.

It should be obvious that solution 1 is not ideal, since if the TCP master is an embedded computer, making software modifications could be difficult or not even possible.

Solution 2:
The second solution is for the Modbus gateway to "learn" the locations of slaves during run time. In this case, the gateway broadcasts the message to all serial ports, and if there is a response from one of the serial ports, the gateway will record the result. After the “learning” stage, all requests will be directed to the correct serial port.

An apparent drawback to this solution is what happens if we make changes to the Modbus network. For example, if we attach another slave to one of the gateways serial ports, will it be learned automatically?

As you probably know, manufacturers of some legacy devices designed their products with one, fixed ID. This was a perfectly reasonable design in the early days, since Modbus was developed by Modicon in 1979, and was only designed for serial networks. If it was always the case that one slave connected to one master, why should different slaves have different IDs?

In this day and age, using Modbus devices that each have their own unique ID certainly makes deployment more convenient. In fact, for a 4-port Modbus gateway, the IDs of attached RS-485 devices are set using 4 DIP switches.

The point we'd like to make is that if the gateway just learns slave IDs during runtime, it will not be able to solve the connection problem posed by the architecture shown in the figure below, since each of the IDs is used twice.

The best solution is to build a mapping table for the slaves and also shift the IDs to different segments. We can call the ID for the TCP master a “Virtual ID” and the ID of the slave a “Real ID.” What the gateway does is change the ID information in each request, and then change it back when the response is received. In this way, the TCP masters identify different slaves using different virtual IDs, and the slaves communicate using their original IDs. The gateway just acts as a bridge between the slaves and the master.

With the ID mapping and shift functions, we can integrate different Modbus networks without needing to change the existing devices or software.

MOXA’s MGate MB3000 supports both the ID mapping and shift functions. Detailed information about MOXA's MGate products is available on our website at the following address:
www.moxa.com/product/MGate_MB3180_3280_3480.htm.

» Back to index