Applies To:
  • CitectSCADA 1.00, 1.01, 1.10, 1.11, 2.00, 2.01
Summary:
This information assumes to know how to use the Citect debugging kernel.

Tuning the Unit cache time will give increased performance for your Citect system. When the Unit cache is tuned correctly you will get reduced PLC communication times, which gives faster page animation, alarm, trend and report processing.

When the Unit cache is tuned correctly, the communication channel to each PLC should be kept busy reading and writing data - there should also be no unnecessary reads.

Unnecessary reads can be generated in the following way. First, assume the cache is disabled. One client requests the I/O Server to read data from the PLC. The I/O Server reads the data from the PLC and passes it back o the first client. Just after the I/O Server has send the data back to the first client, the second client requests the same data. The I/O Server must now do another read (of the PLC) that could have been serviced by the first read. If the I/O Server received the second clients request before the PLC data was returned, it would have automatically optimised the read - by sending the same data back to both clients (Page General Blocked Reads shows this count). The unit cache will fill in the gap of the requests between the two clients. If the cache time is set to 300ms, the second client can make a request to the I/O Server up to 300ms after the I/O Server has sent the data back to the first client, and still get the same data. Note that the two clients don't have to be two different Citects on a network, they may be the alarms and trend clients in the same computer, so this tuning will effect even a single node system.

The cache should be tuned large enough so that unnecessary reads are not generated, and small enough that old data is not returned while keeping the communication channel busy. If the cache is too large, the communication channel may become idle for short periods of time and so waste its bandwidth. Also if the cache is too large, a Citect client may start to short cycle on reads request, which will generate unnecessary network or internal traffic load. Read short cycling occurs when a client requests data from the I/O Server, and the data is returned from the cache, so it is returned very quickly. The client will process the data, eg display it on the screen (also very quickly), then ask for the same data again. If the I/O Server again returns the same data from the cache, the client will process the same data again which is redundant and a waste of CPU and the network (to transmit the request and response). When short cycling starts to occur, the CPU and network loading will rise while the PLC communication traffic will start to fall.

To tune the cache you must balance the cache time between unnecessary reads and short cycling. 

Solution:
Use The following method:
  1. Turn off all unit caching, use the CACHE command in the kernel so you don't have to recompile your project.
  2. Run 1 Citect client only on the network, use the Client in the I/O Server for the test.
  3. Display a typical page to generate normal PLC loading for your system.
  4. In the kernel use the STATS command to reset all the Citect statistics.
  5. In the kernel display the page 'PAGE TABLE STATS'. This page shows the cycle and execution time of various Citect tasks, some of which consume PLC data. The tasks called 'Citect n' where n is a number are the tasks which get data from the PLC and display on the screen. Look at the Avg Cycle time, this is the third column from the left. Assume that the Avg cycle time is 1200 ms. This will mean that the current page is gathering all PLC data and displaying its data on the screen in 1200ms.
  6. The cache time should always be below this average cycle time to prevent short cycling. On average it should be less than half this time, ie 600 ms.
  7. Set the cache time to half the cycle time (600ms). You may not see any improvement in performance with a single client, as caching will only improve performance with multi clients. You may see improvements is you are also running trends, alarms or reports which are requesting the same data.
  8. You should then add another Citect client which is displaying the same data. Reset the STATS and check the Average cycle time. Each new client should not increase the cycle time, it should drop slightly. Also look at PAGE GENERAL, to see that each new client should service its reads from the cache, ie the % cache reads increases.
  9. If the average cycle time drops to less than half the original time then short cycling is occurring and you should decrease the cache time until this stops.

Tuning the cache is a trial and error process - as you change it, the read cycle time will also change. The cache time will also depend on what the current PLC traffic is. The current traffic is dynamic as Citect will only read what is required depending on the current page, trend, alarm and reports running. You should always be on the safe side and set the cache a bit lower to stop short cycling under lower loading conditions. 
Keywords:
 

Attachments