Tune the cache 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 might become idle for a
while and so waste its bandwidth. Also if the cache is too large, a
CitectSCADA client might
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 quickly. The client will process the data
(display it on screen) 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 need to balance the cache
time between unnecessary reads and short cycling. The method
described below assumes you know how to use the CitectSCADA debugging Kernel.
Turn off unit caching, use the
CACHE command in the Kernel so you don't have to re-compile your
project.
Run one CitectSCADA client only on the network,
use the Client in the I/O Server for the test.
Display a typical page to
generate normal PLC loading for your system.
In the Kernel use the STATS
command to reset the CitectSCADA statistics.
In the Kernel display the page
'PAGE TABLE STATS'. This page shows the cycle and execution time of
various CitectSCADA 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 screen.
Look at the Avg Cycle time, this is the third column from the left.
Assume that the Avg cycle time is 1200 ms. T his will mean that the
current page is gathering PLC data and displaying its data on the
screen in 1200 ms.
Always set the cache time below
this average cycle time to minimize short cycling. On average set
it to less than half this time, that is 600 ms.
Set the cache time to half the
cycle time (600 ms). You might not see any improvement in
performance with a single client, as caching will only improve
performance with multi clients. You might see improvements if you
are also running trends, alarms or reports which are requesting the
same data.
Add another CitectSCADA client that is displaying
the same data. Reset the STATS and check the Average cycle time.
Each new client will not increase the cycle time, it will drop
slightly. Also look at PAGE GENERAL, to see that each new client
services its reads from the cache; i.e., the % cache reads
increases.
If the average cycle time drops
to less than half the original time then short cycling is occurring
and you need to 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 CitectSCADA will
only read what is needed depending on the current page, trend,
alarm and reports running. Monitor the average cycle time under
lower loading conditions and set the cache as low as necessary to
stop or help prevent short cycling.