Use the search feature to view Kepware's repository of more than 500 Knowledge Base articles. Narrow your results or type your query into the search field below.

Alternatively, if you are unable to find a solution, we have an additional resource - our PTC eSupport Portal . If you are prompted to log into the eSupport Portal, you can use your My Kepware credentials. Need a My Kepware account? Create one here .

Search Solution Results By:
View All Solutions

Kepware Knowledge Base: Solution

Benchmarks for Ethernet-based Drivers

Last Update: 11/7/2018

It is difficult to establish benchmarks for Ethernet-based devices. Unlike serial drivers, bandwidth is not a real concern; in fact, an Ethernet network has 30% of bandwidth available for data transfer (which includes emails, file copies, print jobs, and requests to PLCs). This is about 3.3 MB on a 10 MB network and 33.3 MB on a 100 MB network; yet, communications are not instantaneous.

Common factors that influence the rate at which data can be acquired from an Ethernet device are as follows:

  1. Consumed bandwidth by other applications. On a flat network, file transfers, emails, and print jobs consume the entire bandwidth. It is recommended that dedicated device networks be used if data is time-critical.
  2. Network configuration. Ethernet is fast, but every managed switch or gateway can add time to the data transfer. Similarly, connecting through Ethernet to Radio modems, frame relays, or dedicated modem connections can cause bandwidth bottlenecks that decrease the data transfer rate.
  3. The PLC's CPU processing power. This impacts how fast the PLC can process its ladder and communication requests. Many PLCs enable users to specify how much time is dedicated to processing a ladder program and how much time is used to process communications requests. Large ladders will require more time to process, which leaves less time for communications.
  4. The number of connections being made to the PLC. One application connecting and requesting data will have faster responses than several connecting and requesting data. The PLC has to manage requests from all connections, which means that there is less time dedicated to each.
  5. How the Ethernet connection is made to the PLC. Some PLCs have an Ethernet port on the CPU; others have models that connect to the backplane and then to the CPU. Some CPUs are natively serial, and have Serial to Ethernet converters married to the serial bus. Connections to the CPU across the backplane are usually slower than direct connections.
  6. How data is received from the PLC. Most devices allow users to request blocks of contiguous data; this better utilizes available bandwidth and causes fewer requests to the device, but only works if the data being requested is in contiguous addresses. For example, in Modbus drivers, the default block size for holding registers is 32 words. The driver calculates the blocks from the first registers. That means that when requesting data from addresses 400001 and 400029, the driver could make one request to get both items. If the second address was 400050, the driver would need to make two requests. Some device protocols allow users to request several items in non-contiguous addresses at one time.
  7. Network noise. Noise and collisions in the network can corrupt or lose the data packet. In those cases, the server will timeout the request and then retry it. The timeout and retry rates are set in the server through the Device Properties. The default settings for most drivers are 1000 milliseconds for timeout and 3 retries. This means that the server will wait for a response to a request for 1000 milliseconds and then retry that request 3 times if needed waiting for the timeout. Because the server will retry all requests to a device, it can take a while for it to timeout completely.
Related Products