The WattNode® WNC series of Modbus® meters has a TCP-RTU communications option that emulates the Modbus TCP protocol over RS-485, allowing the use of low-cost serial-Ethernet gateways. The Modbus TCP/IP protocol facilitates communication with Modbus TCP/IP gateways over an Ethernet LAN and the Internet. Note that Modbus TCP/IP is not the only way to do this. Many Modbus master applications have another option (called Remote Telnet Server, Serial Device Server etc.) that allows sending unmodified Modbus RTU Serial messages through a TCP/IP socket to any Serial Device Server (SDS) or Serial Device Adapter (SDA), not just Modbus TCP/IP gateways. There are a few differences to be aware of between the Modbus TCP/IP protocol and the “Modbus RTU Serial via raw TCP/IP socket” approach. The most significant difference is that Modbus TCP/IP supports multiple client connections at the same time whereas the latter approach only supports a single client connection at any given time. If your application doesn’t require multiple concurrent client connections but it only supports the Modbus TCP/IP protocol then please read further to see how you can use a lower cost SDA or SDS instead of a Modbus gateway to reduce cost. Modbus TCP-RTU protocol is essentially the Modbus RTU serial protocol layered on top of (or encapsulated by) the TCP/IP protocol. Since the TCP/IP packets that encapsulate the RTU messages have a CRC-32 (Cyclic Redundancy Check), the 8-bit Modbus message checksum was omitted in the Modbus.org standard. However, if the Modbus master includes a Modbus message checksum, the WattNode Modbus will verify it in received messages and include one with the replies. This allows a low-cost Ethernet/RS485 SDA (Serial Device Adapter) to be used as an alternative to a Modbus Gateway while still ensuring message integrity for the RS485 bus transfers to/from the SDA and the WattNode. Simplifying assumptions that the WattNode applies to the Modbus TCP/IP standard are listed below:
- The Modbus.org specification allows for very long slave response delays exceeding one minute, which can occur with packets that must travel across the Internet. Our implementation assumes that the master and slave devices are connected by a properly functioning LAN segment such as a corporate intranet where packet delivery and response latencies are kept well under a few seconds. This eliminates any need for buffering multiple pending commands from the host (master) to the WattNode Modbus RS-485 slave device. This also alleviates the need for a frame count as discussed in the next bullet item.
- The Modbus.org specification says that several Modbus transactions (commands) can be active on the same TCP connection at the same time. The WattNode meter does not support this since it can only process one command at time and it is usually the only end-point device. However, it is possible to connect multiple WattNode meters via RS-485 to the same Ethernet Transaction Network Services (TNS) as long as the master software waits for the reply from a given WattNode meter before issuing a command to another WattNode. The Modbus.org specification reserves the first two bytes of the 6-byte TCP/IP header for a “transaction identifier”, or frame count, which is no longer needed when only one command message can be outstanding at a time. In fact, the WattNode will ignore two outstanding frames sent in rapid succession, since that is indistinguishable from a message collision or bus contention scenario.
- Because a Modbus checksum is normally not included with the encapsulated Modbus message, we recommend enabling the even parity with the ParityMode (1654) register in conjunction with the TCP/IP Modbus protocol option for additional reliability. You may also have to configure your SDS for even parity. It is also advisable to keep the RS-485 bus wires short and ensure that they are well-shielded and kept as far away as possible from sources of EMI (electromagnetic interference) to minimize possible noise on the RS-485 bus.
- The WattNode doesn’t allow for fragmented TCP/IP packets. This is normally not a problem and simply requires that the PC software pass the entire command packet to the OS TCP/IP socket in one call to the OS. Since that amount of data will easily fit within a single TCP/IP and Ethernet packet, this requirement is easily met when the PC and the WattNode are communicating over a local Ethernet LAN segment.