Verwenden Sie die Suchfunktion, um das Kepware Repository mit mehr als 500 Wissensdatenbank-Artikeln anzuzeigen. Grenzen Sie die Ergebnisse ein, oder geben Sie Ihre Abfrage im Suchfeld unten ein.

Wenn Sie keine Lösung finden, stehen Ihnen alternativ weitere Ressourcen zur Verfügung: unser PTC eSupport Portal. Wenn Sie aufgefordert werden, sich beim eSupport Portal anzumelden, können Sie die Anmeldeinformationen für „My Kepware“ verwenden. Benötigen Sie ein Konto für „My Kepware“? Hier können Sie ein Konto erstellen.

Lösungsergebnisse durchsuchen nach:
View All Solutions

Kepware Knowledge Base: Solution

Benchmarks for Ethernet-based Drivers

Last Update: 07.11.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