Here’s what more than 2,500 business decision-makers around the world say.Download the report
...with the Facility Hero app in hand! Discover how you can optimize your maintenance efforts today.Learn more
Access tailored services, 24/7 self-service and expert help. Anywhere, anytime, any project.Discover now
Everything you need to know about our IoT technology backbone.Learn more
Schneider Electric Global Website×
Explore our global offerings or select your country from one of our five regions.Global
Découvrez nos offres globales ou sélectionnez votre pays dans l’une de nos cinq régions.
The limiting factor is serial side communications and the configured baud rate. From Ethernet, the CEV passes the Modbus header and function code request data to the serial slave. The slave then responds with the Modbus header, function code and register data. For example, the minimum Modbus header is:
2 bytes Transaction identifier
2 bytes Protocol ID
2 bytes Number of bytes to follow
1 byte Unit or Slave index
1 byte Function code (Read, write, etc)
Beyond that we have the function code dependent data such as starting register and number of registers. For a function code 3, Read Multiple 4x registers, there would be 4 additional bytes for starting register and number of registers.
Therefore, the original read request for 10 registers in this example would be 12 bytes sent as the request, and 22 bytes returned as the response (12 byte header plus 10 word response = 22 bytes)
22 bytes transmitted at 9,600 baud = (22 * 8) / 9600 = 18.3ms not including the slave response time.
The same example with a 100 register read is (222 * 8) / 9600 = 185ms.
Note that signaling overhead and intermessage gaps for RTU communications will increase that time.
Therefore, you can see that the number of devices and the size of the request plays a role in overall response time.