Network Speeds

There are two very separate things to consider. 1) How often the data is requested / sent. 2) How long it takes for the data to be transferred. Taking 1) This will depend on if you are the master or the slave. If you are master, you control how often the data is requested (i.e. your poll rate). This will be set by how often you toggle the modbus block send input. If you are slave, you will get data at the period the master is configured to send it (i.e their poll rate). This will be outside of your control. Taking 2) To work out the time taken for the data transfer you must first workout how many bits the data packet consists of (this will be different for RTU and TCP as the protocols are slightly different), the bit rate of the link and the packet turnaround time of the slave device (the time it takes to handle the request and start to return the response). Taking a request for 10 holding registers with you being the master as an example. For RTU:The request packet will be: Slave address (1 byte) + Function code (1 byte) + Offset (2 bytes) + Number of Regs (2 bytes) + CRC (2 bytes) = 8 bytes. The response packet length will be: Slave address (1 byte) + Function code (1 byte) + Byte Count (1 byte) + Data (20 bytes) + CRC (2 bytes) = 25 bytes. The number of bits will depend on the serial setup (e.g. parity, data bits etc.). Assuming 1 start bit, 8 data bits, 1 parity bit and 1 stop bit = 11 bits per byte. So total number of bits = (25 + 8) * 11 = 363 bits. Now the bit time must be calculated = 1 / baud rate. Taking 19200 baud as an example, bit rate = 19200 / 1 = 52 micro seconds (5.2E-5 secs) Giving a total transaction time of 52 micro seconds * 363 = 18.876 milliseconds. For TCP:The request packet will be: Transaction ID (2 bytes) + Protocol ID (2 bytes) + Packet Length (2 bytes) + Unit ID (1 byte) + Function code (1 byte) + Offset (2 bytes) + Number of Regs (2 bytes) = 12 bytes. The response packet length will be: Transaction ID (2 bytes) + Protocol ID (2 bytes) + Packet Length (2 bytes) + Unit ID (1 byte) + Function code (1 byte) + Byte Count (1 byte) + Data (20 bytes) = 29 bytes. For TCP there are 8 data bits per byte. So total number of bits for modbus = (29 + 12) * 8 = 328 bits. However, this is just for the modbus ADU (application data unit). There will be an overhead for the TCP and IP layers which will be approx 54 bytes = 54 * 8 bits = 432 bits. So total number of bits for whole packet will be 2 TCP/IP headers at 432 bits each + request and response modbus packets = (2 * 432) + 328 = 1192 bits. Now the bit time must be calculated = 1 / bit rate. Taking 100BaseT as an example, bit rate = 100Mb / 1 = 10 nano seconds (1.0E-8) Giving a total transaction time of 10 nano seconds * 1192 = 11920 nano seconds = 11.92 micro seconds. So for the transaction time will be 18.876 milliseconds for RTU and 11.92 micro seconds for TCP. The slave turnaround time is expected to be the same for an RTU device and TCP device so this can be effectively cancalled out. So that gives you an idea of the difference in transaction times between RTU and TCP. The most influencial factor to this is the high transmission speeds acheivable on ethernet. The TCP packets are larger, but this is far outweighed by the much higher transmission speed. Hope this explains it a bit for you. Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. So far, the universe is winning...