Lantronix IntelliBox-I/O IntelliBox-I/O - User Guide - Page 173
Examples, Modbus/TCP Master Talking to Modbus/TCP Slave
View all Lantronix IntelliBox-I/O manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 173 highlights
C: Modbus The figure above shows various specific styles of Modbus operations. Traditionally, Modbus/RTU devices fall into two groups: Modbus slave devices: These are generally the workhorse devices. They perform their tasks 24 hours a day, 365 days a year. Flow metering, temperature control, batch loading, and running entire automated assembly lines are examples of such tasks. The slave devices are called slaves because as far as data communications is concerned, they function as passive servers. Modbus slave devices passively sit and wait for a remote Modbus master device to ask them to report existing data values (read) or accept new data values (write). Modbus master devices: These are generally 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 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. The IntelliBox does not support Master devices connected to the serial ports, unless the Masters are being polled like a slave device. Examples Modbus/TCP Master Talking to Modbus/TCP Slave Devices A, B, D, and E are 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 D as a slave, polling data in real time. Yet controller D can also act as a master and poll data from controller E, 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 severe 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 IntelliBox-I/O extends to traditional Modbus/RTU serial devices. Modbus/TCP Master Talking to Modbus/RTU Serial Slave Devices C, F, and G are traditional Modbus/RTU slave devices. Device C uses a point-topoint electrical interface like RS232. This allows only a single Modbus/RTU master to talk to device C. However, the IntelliBox makes device C appear on the Modbus/TCP network as a full Modbus/TCP slave device. All Modbus/TCP enabled devices, A, B, D, and E, can actively share access to slave device C. A limitation in traditional Modbus/RTU implementation expects devices to be dedicated as either master or slave devices, so device C can only act as a Modbus slave. Devices F and G are different from device C. They share a single RS485 multi-drop line that strictly limits them to act as slaves to a single Modbus/RTU master. However, all Modbus/TCP enabled devices A, B, D, and E can actively share access to both slave devices F and G. IntelliBox manages and coordinates the shared access. In fact, the IntelliBox allows up to sixteen concurrent Modbus masters (or thirty-two if an additional TCP Server is also used) to share access to the slaves. IntelliBox-I/O 2100 User Guide 173