The response time from a PLC is highly dependent on the type of PLC and the protocol being used. To check the response time from the PLC, use the debug kernel on the I/O Server.

The 'Page Driver' display shows general stats on each of the drivers. Check the 'Response Times' for the times to complete a single read or write to the I/O Device. You should verify that they are what you expect from your PLC. These times will be totally dependent on the type of PLC, the protocol, the baud rate and other factors, and can range from 0 ms to a few seconds. (You should have an approximate idea of what to expect from your PLC.) The maximum should not be more that 3 to 4 times the minimum. (Note that as these times are only accurate to 55ms, low minimums will skew the real numbers low.) If the maximum is much larger than the minimum, you may be getting Timeouts and retries. Check the error count, retires and Timeouts fields on this page for any errors.

Also check the Physical Reads and Physical Writes per second, (the number next to the Physical reads and Physical writes). The reads could be in the range 1 to 50 per second (you should have an estimate how many reads you think the system should be doing). You should also check that you are not doing too many writes to the PLC (greater than 5 per second). If you have poorly designed Cicode you can generate a large amount of writes, and slow the PLC response time.

The 'Page General' display shows the overall response times and total read and write requests to all drivers on the I/O Server. The response time will show the total time it took for the I/O Server to service the request. (This is the time from when the request arrived at the I/O Server to when the I/O Server sent it back to the client.) Th response time will include all time waiting in queues for other requests and the time for the requests to be processed by the protocol driver. (This gives the best indication of the total system response.) You should also check that the cache is correctly tuned for your system. Also check that the CPU loading it not too high, it should average less than 40%.

You may display all the requests going to a particular driver to verify that Citect is reading what you expect. This shows exactly what Citect is reading and writing to the PLC, and is useful to find out if you have configured an incorrect PLC address (eg you typed in V2000 instead of V200). From the debug kernel shell, type 'debug <port> to' where <port> is the name of the port you want to check. If you don't know the port just type 'debug' and a list will display. This will display all read and write requests going to the port in their correct PLC address syntax. You should verify that what is being read is what you expect. To turn off the trace type 'debug <port> off'.

The display 'Probe' will display similar data to 'debug <port> to'. Probe displays the request from the Citect to the I/O Server, whereas 'debug <port> to' displays the requests going to the port. The requests going to the port will be optimised from all requests and from all the Clients, so you cannot tell where the request came from. Probe only shows the request from this Citect to the I/O Server. You can therefore display the 'Probe' display on any Citect on the Network whereas 'debug <port> to' only works on the I/O Server. (Note that as 'Probe' is displayed on the Citect client side, it does not know about PLC protocols. Therefore it cannot display the PLC address syntax, and displays the address in the generic Citect binary syntax. However you should be able to figure it out in most cases.)