Lantronix XPort APS: Modbus Protocol User Guide - Page 8

2: Modbus Modbus master devices generally are higher-level computers, devices in which data and software are very important. The most common examples of Modbus master devices are the "Human-Machine-Interface" (HMI) computers, which allow human operators to monitor, adjust, and maintain the operations of the field devices. Modbus master devices are clients that actively go out and "read" from and/or "write" to remote Modbus slave devices to monitor or adjust slave behavior. Modbus/TCP Master Talking to Modbus/TCP Slave Devices A, B, E, and F are all new Modbus/TCP devices, which are improved over Modbus/RTU (see more about Modbus/RTU limitations below). All four devices can function concurrently as both Modbus master and Modbus slave. Both computers A and B can treat controller E as a slave, polling data in real-time. Yet controller E can also act as a master and poll data from controller F, which can in turn also act as a master to write alarm data directly up to computers A and B to alert the operators to the alarm condition. Traditional Modbus/RTU requires slave devices even with life threatening alarm conditions to sit patiently and wait for a remote master to poll the specific data that caused the alarm condition. It is revolutionary for such a simple and flexible protocol as Modbus to offer such functionality. Therefore, Modbus/TCP offers exciting new design options for industrial users, which the Lantronix IAP Device Servers extend to traditional Modbus/RTU serial devices. Modbus/TCP Master Talking to Modbus/RTU Serial Slave Devices D, G, and H are traditional Modbus/RTU slave devices. Device D uses a point-to-point electrical interface like RS232. This allows only a single Modbus/RTU master to talk to device D. However, the IAP Device Server makes device D appear on the Modbus/TCP network as a full Modbus/TCP slave device. All Modbus/TCP enabled devices, A, B, E, and F, can actively share access to slave device D. A limitation in traditional Modbus/RTU implementation expects devices to be dedicated as either master or slave devices, so device D can only act as a Modbus slave. Devices G and H are different from device D. They share a single RS485 "multi-drop" line that strictly limits them to act as slaves to a single Modbus/RTU master. However, a little of the new Modbus/TCP and IAP Device Server magic still appliesall Modbus/TCP enabled devices A, B, E, and F can actively share access to both slave devices G and H. IAP Device Server manages and coordinates the shared access. In fact, the IAP Device Server allows up to eight concurrent Modbus masters to share access to the slaves. Modbus/RTU Serial Master Talking to Modbus/TCP Slave Device C is a traditional Modbus/RTU master device. Yet the IAP Device Server makes device C appear to the TCP/IP network as a Modbus/TCP masterplus all of the Modbus/TCP slaves on the TCP/IP network (A, B, D, E, F, G, and H) appear as traditional Modbus/RTU slave devices. The only limitation is the traditional Modbus/RTU assumption that device C is dedicated as a master only. Therefore Modbus/TCP master devices A, B, E, and F cannot treat device C as a Modbus/TCP slave. Modbus/RTU Serial Master Talking to Modbus/RTU Serial Slave Finally, master device C can poll traditional Modbus/RTU slave devices D, G, and H as if they were directly multi-dropped on an attached RS485 line. The IAP Device Server transparently bridges traditional Modbus/RTU devices across any TCP/IP network. This means users can start implementing for Modbus/TCP long before all of their required products exist with Modbus/TCP and network interfaces. Modbus Protocol User Guide 8