The name of the physical port the driver is using for communication.

The name of the protocol.

The protocol title and version string. Protocol drivers for Citect Versions 3.xx, 4.xx, and 5.xx, are Version 2.0 type drivers.

The first number is the total number of read requests sent to the driver from every client Citect computer, including the local Citect client.

The second number is the read requests per second (that the I/O Server is performing).

The first number is the total number of physical reads made to the I/O Devices. Because the I/O Server can optimize the number of read requests made to the I/O Devices, this number is usually smaller than the number of read requests.

The second number is the number of physical reads per second (that the I/O Server is performing).

The total number of times a request was made for the same I/O Device address while the driver was already reading or about to read that address. The driver blocks the two requests together as an optimization.

The total number of digital points that the I/O Server has read from every I/O Device.

The number of digital reads per second that the I/O Server is processing. This provides a general indication of performance. It is dependent on the protocol.

The first number is the total number of write requests sent to the driver from every client Citect computer, including the local Citect client.

The second number is the write requests per second (that the I/O Server is performing).

The first number is the total number of physical writes made to the I/O Devices. Because the I/O Server can optimize the number of write requests made to the I/O Devices, this number is usually smaller than the number of write requests.

The second number is the number of physical writes per second (that the I/O Server is performing).

The total number of times a request was made for the same I/O Device address while the driver was already writing that address. The driver blocks the two requests together as an optimization.

The total number of register points that the I/O Server has read from every I/O Device.

The number of register reads per second that the I/O Server is processing. This provides a general indication of performance. It is dependent on the protocol.

The number of read requests serviced from the read cache.

The percentage of reads serviced from the cache. If the cache read % is large (for example greater than 40%), the I/O Device cache timeout could be set too high. Try reducing the I/O Device cache time to bring the % cache below 40%.

The % of read cache depends on the configuration of your Citect system and the number of clients connected. If you have many clients looking at the same I/O Device data, the cache % may be very high, however this does not cause a problem. For example, if you have 10 Citect clients viewing the same page, a cache read of 90% would be acceptable.

The total number of errors encountered by the driver.

The number of times the server needed a buffer for the driver but none were available. This can reduce communication performance and result in loss of requests. Increase available memory if this field increments too quickly (that is, more than 10 per minute).

The number of low-level driver errors encountered before retries were performed. This field may continue to increment even if no errors are reported because the driver retries and it may complete the command on the second attempt. If this field increments quickly (i.e. 10 or more per minute) without other errors being reported, you may have a low-level error that affects performance.

The number of times the driver requires a buffer but none were available. The driver needs to discard the data. If this field increments too quickly, increase the number of pending commands the driver can process. This field only increments with client drivers. I/O Device drivers do not require pending buffers.

The number of timeouts encountered by the driver during operations. This field may continue to increment with no visual errors as the driver retries the operation. If this field increments excessively, there may be a communication problem.

The number of retries executed by the driver. If this field is incrementing, there may be a communication problem.

This is the number of requests that are kept in a buffer waiting to be serviced by the protocol. There is a pre defined default value for this for every protocol. If a protocol is capable of handling multiple requests or commands at a time then this number may be high. If the protocol is capable of only handling 1 command at a time then this will probably be 1 or 2.

This is the range that the I/O Driver will use when blocking read or write requests together at runtime. The default value for this is typically set after quite a lot of experimentation. The value is calculated as the optimum range of data that the I/O Device can respond to, to get the fastest response times from your I/O Device.

For example, if the Blocking Size is 100 and you have a graphics page that has Address1 and Address 99 on it, Citect will read both of these addresses in one request. If you have Address 1 and Address 101 on the page Citect will issue 2 separate read requests. The block size may not be the maximum packet size for the protocol, since a particular type of I/O Device may respond faster to smaller requests of data than larger requests.

There is one important consideration when using this method; many I/O Devices need to have their Memory tables created by the user. If the user does not define every memory address in a range, then Citect may try and read a block of memory from the I/O Device that does not exist (giving a hardware alarm). This is because Citect will ask for the whole range of addresses between the starting address and the ending address. So, if in our previous example the I/O Device did not have address 76, it would report back to Citect that it could not read address 76. The I/O Driver does not know that it doesn't need this address and will retry the command, and in some cases will eventually put the I/O Device offline.

Confirm that you always have defined the memory addresses that Citect will need to read.

This is the period of time that the I/O Driver will wait before re-requesting data, if no answer comes from the I/O Device.

The number of times the I/O Driver will attempt to get data from the I/O Device.

Combining this with Timeout gives you the total period before Citect will put an I/O Device offline.

If the Timeout=2000 and Retry=2 then Citect will wait 2 seconds for a response, then retry, wait 2 seconds, retry, wait 2 seconds, Offline. Total time between losing communications and deciding it is offline is now 6 seconds. You can modify these parameters, but if you set them too low you will generate unneeded retries and possibly get I/O Device Offline messages.

This is the time in milliseconds that Citect will check the port for data or write data to the port. If this is 0 then the protocol is operating in Interrupt mode.

This is the time that Citect will hold a packet of data between receiving a response from the last request and sending the new request. This is usually 0, however some protocols can become saturated and start to misbehave. In these cases the default value has been calculated while the protocol was being tested, and modifying this value to something smaller will cause problems. However, making it bigger will only have a very slight impact on the overall response times in your system, but may make the communications more stable.

This is the period of time that Citect will wait after deciding an I/O Device is offline before trying to re-establish communications. This is typically 30 seconds. It can be made smaller but not be made smaller than the period that Timeout and Retry will be - otherwise you will not be able to re-establish communications with an I/O Device.

The time taken by the driver to process read and write requests (i.e. the time taken to process a single read or write operation to the I/O Device). This time depends only on the physical response time of the I/O Device, because no queue waiting time is included. This field reflects any tuning of the communication channel (for example increasing the baud rateThe number of times per second a signal changes in a communication channel. While the baud rate directly affects the speed of data transmission, the term is often erroneously used to describe the data transfer rate. The correct measure for the data rate is bits per second (bps). will reduce the response time).

The average, minimum and maximum times are displayed.

This field displays the percentage of the total capacity of the hardware channel that is currently being used. The I/O Server tries to keep the utilization as high as possible, however if the client Citect computers are requesting data slower than the channel can supply, the total will be below 100%. It is possible for the channel usage to rise above 100% as some I/O Device drivers can process more than one command at the same time (having two or more commands using the channel at the same time).

The number of bytes transferred (each second) by the driver. This number provides a simple performance indication that is useful when tuning the driver.

By enabling verbose mode (press V) or by pressing the down arrow, twenty special variables are displayed. The meaning of these variables is driver-specific.