3.3.5   API Comport Properties

Applications Programming Interface is abbreviated API.  This option is to use 3rd Party Software as the interface to the field device.  The API software package is installed on the SCADA node.  The hardware manufacturer usually supplies the API software. Many proprietary network cards require the user to install software on the SCADA node PC in order to communicate with the automation devices on their proprietary network.  The Siemens S7 interface is an example; it requires the SIMATIC NET software.  The WebAccess driver communicates with the SIMATIC NET software.   The Omron Host Link driver is another example of an API type interface.

SNMP, DDE, OMRON and Siemens S7 interfaces use the API ComPort type.

Figure 3-7Comport Properties - API

Comport Number

In an API type port, the Port number is dependant on the API Driver. This maybe just a Virtual number or may refer to a specific comport depending on the driver. Please refer to the specific API program's Documentation.


User defined field for reference. This appears only in Project Manager.

Scan Time

This is the frequency of polling request for new data specified in Milliseconds.   The speed is largely determined by the API Software, the field device and the nature of the network (how many other devices there are, how much data, the protocol, and baud rate). Refer to the API Software documentation and the Device Manufacturer's Manual for information on minimum scan times.

1000 Milliseconds means WebAccess will try to update data once a second.  50 Millisecond scan times are not uncommon for connections to a single PLC.  50 Msec means WebAccess will try to update data is 20 times per second.

The freshness of the data is largely determined by the API program, some use a protocols that uses "report by exception" that includes Deadbands that must be exceeded before a value is updated.

A zero (0) sets the scan time to scan as often as possible.


Time waited before re-sending a communications packet that did not have a reply. Specifies how long the software waits for a response to a data request, specifically to wait for a reply from one packet. A recommended value is 7 to 10 ticks, longer if the communication device is slow. This is protocol dependent: some protocols do not allow changes in time out.

Combined with Retry count, also determines time to consider a device or port as BAD.   Timeout is the time to wait since last communication packet sent without a reply. Time is in milliseconds. The slow or poor quality communications require longer timeout.  For slow the communications networks and devices, a longer timeout may be required to prevent false disconnects.  Shorter timeouts notify operators of communications failure more quickly. 

Retry Count

Number of times to retry communications if no reply is received from a device.  Combined with Timeout, also determines time to consider a device or port as BAD.  

In addition, Indicates the number of times after the first attempt has failed that communication should be attempted before indicating a failure. Specifically, how many times to send a single packet after the field device fails to respond to the first packet. After the retry count is exceeded, all the tags in the packet are marked with asterisks and the next packet of requests is sent. A reasonable value is 3 to 5 times. After this number of tries, the tags in this packet are marked as "fail to respond" (i.e. asterisks) and are disabled. In reality, increasing the number of retries hides failures on the part of the field device to respond to a request. Essentially, increasing the retries gives the field device more chances to reply.      

Auto Recover Time

Auto Recover is the Time to wait before attempting to re-establish communications with a BAD device or port.