Modbus bridge on CPX4

Configuring a Modbus TCP to serial Modbus bridge Over mesh

Built into many products is the Digi IA Engine, which is a transaction processor/bridge. It allows multiple Modbus Masters (or clients) to share the same set of Modbus Slaves (servers). It works much like a print server, which allows multiple people print at the same time because it understands the notion of "a print job". Likewise, the Digi IA Engine understands the form of a Modbus transaction and gracefully interleaves requests from multiple masters, returning the correct response to the correct master.

Configuration example on Digi ConnectPort X4

The example below will configure the CPX4 for the simple two-slave system in this drawing:

Create the IA table - link masters to slave

After making sure your CPX4 has the latest firmware, click the Applications | Industrial Automation link on the left. You will see this starting page to create the core protocol message routing (or mapping) table. Each table links one or more masters/clients issuing Modbus requests to one or more Modbus slaves/servers returning responses. Most people need only a single table; using multiple tables is a feature for advanced users or unusual applications.

• Click the Applications | Industrial Automation link on the left.
• Enter any name for your table - in this example MyMesh.
• Click the ADD button.

Message sources - who asks the Modbus questions?

After creating the table you will see the basic three-sections of the table.

• The upper section shows basic whole-table settings. For Modbus, this is only the table name. The name is a user convenience, so change as you wish.
• The center section lists the Message Sources. These define which remote Modbus masters/clients connections are permitted. Up to 32 masters/clients can connect at one time, and they can connect using any mix of Modbus/TCP, Modbus/RTU or Modbus/ASCII on TCP, UDP or on direct serial ports. (At present, Modbus serial Masters cannot connect via the mesh/wireless).
• The bottom section lists the Message Destinations. Each Modbus request includes a Unit Id or Slave address field, which the Digi IA Engine uses to locate which of many Modbus slaves/servers to forward the request to.

To add a new Message Source, click the middle button labeled Add.

The Message Source Settings display allows you to define incoming message types, and you can click add repeatedly to add more. In general you should add at least the Modbus/TCP on TCP/IP port 502 - even if you will be moving Modbus/RTU in UDP/IP. This makes it easier to use standard freeware/shareware tools to confirm operation.

The Source Types include:

• Receive messages from network device connecting using the network. This is any remote Master coming in from a device with an IP address. This includes local Ethernet device, remote broadband or cellular devices, or even the localhost (127.0.0.1) to enable Python scripts to talk to the Digi IA Engine.
• Receive messages from serial device connected to a serial port. This is a serial Master connected directly to a serial port on the Digi device. This does not include a serial master connected to a remote terminal or device server - those would be considered network devices. At present it also does not include serial masters on mesh devices.

You can see the various other options - support for any of the common Modbus protocols (Modbus/TCP, RTU, ASCII), plus IP or port settings. If you are talking over high-latency networks like cellular, then you should enable the Hang up when source connection is idle option to speed up recognition of broken client links.

After clicking Add, you'll see a default dialog simplier than the one show below. As you add information, it will expand to what you see below.

1. Since we define the first destination as Modbus slave 2, we click the radio button next to " Send requests within the following list to this destination: "
2. Enter the number 2 - you could also enter a range such 2-10 or a scattered list such as 2,5,23,45.
3. Change the Destination Type to Send messages to XBee device. This causes the dialog size to double as the various destination options are exposed.
4. Enter the Extended Address - the MAC address. Use the format shown and remember the trailing "!"
5. Increase the Character Timeout to be from 500 msec to 5000 msec. The default of 50 msec is too short for the mesh.
6. Click the APPLY button - this saves this destination, but does not allow you to create a destination route.
7. Click the RETURN button, which returns to the table overview.

Now add the second destination for Modbus slave #3 to MAC 00:13:a2:00:40:31:21:c2! Follow these same steps as above, but enter the new address information.

Add Python as a message destination

Technically you are now done. However, to illustrate adding custom Python support to your X4 gateway we'll add one more destination. All Modbus slaves from 100 to 250 shall be defined as destination Modbus/UDP on localhost (IP = 127.0.0.1) on UDP port 8502. We cannot use 502 as that port is already bound to the incoming Masters! Using UDP simplifies your Python and reduces system resources.

If your Python code binds on 127.0.0.1 UDP port 8502, then the IA Engine will pass you Modbus/TCP formatted requests which you Python code can answer.

Below is how our final table looks - notice the Up/Down actions - the IA Engine always scans the list from top to bottom, stopping at the first address match. So if you added a fourth route for Modbus slave 4 on the mesh, then your X4 would function as expected - however, if you added a fourth route for Modbus slave 144 on the mesh, then requests for Modbus slave 144 would still match on route index 3 and be handed to Python.

Troubleshooting

First, some common sense steps:

• Reboot after changing configuration - generally changes can be applied without rebooting. However certain actions pending can block those changes
• Confirm all of our MESH devices show up on the XBee Network display, and that they have the correct baud rates applied.
• Confirm you have the correct protocol enabled - enabling incoming Modbus/TCP but using a client sending Modbus/RTU format in TCP/IP will not work. You can add a new message source for Modbus/RTU in TCP.

Second, pressing the Management > Connections link brings up the display below. The two items listed as Modbus/TCP Listener should ALWAYS be present (you'll only see the one on UDP port 502 if you enabled it as a second incoming master/message source).

In the example below you will also see a third item tagged as Modbus/TCP via TCP with IP address 192.168.196.6, which means we already have one client connected.

Third, you can see a real-time trace, which is explained at this wiki page. That page highlights use of the Digi One IAP product, but the same trace functionality exists on the X4.

Fourth, if you are seeing slave timeouts, the X4 actually times all requests and displays that information in the same event trace, which is explained at this wiki page. You will want to set very long time out (up in the 10 or 15 second range), then watch these response times. You can then safely reduce the time outs to match actual performance.