Applies To: |
|
Summary: |
If you generate Unit write requests faster
than the I/O Server can physically write to the I/O Device, the I/O
Server will buffer the requests - consuming a lot of memory. If
this occurs for a long period of time, Windows may start paging
memory to disk and degrade the performance of the I/O Server. Also,
as write requests are given higher priority than read requests, any
pending read requests will be processed after the writes, so the
read response time may increase.
This problem could be caused by Cicode that is running in a loop, or called continuously from a report that writes to an I/O Device, for example.
or a report running at a few second period with a large number of writes. PLC_TAG1 = <expression>; You should not write Cicode that does this type of operation as it will degrade the communication performance of Citect. If you must write to a variable at a high rate, use a local Cicode variable, memory I/O Device or disk I/O Device. The local Cicode variable is fastest as the write is done immediately into local memory. If you must share the variable on the local Citect, use a memory I/O Device - it is a little slower than the local Cicode variable, but has no impact on the I/O Server. If you must share the variable between some or all Citects, use a Disk I/O Device as the I/O Server can normally write to a disk I/O Device faster than it can write to a PLC I/O Device. Only write to a I/O Device variable if you need to write to it. For example, only write to the I/O Device if the variable needs to be updated. If you are writing the same value as last time, and nothing else will write to the variable, there is no need to write to the same variable again. Citect cannot optimise the write by not doing it (only you know if it is not required). For example the following code will optimise the write to the slow I/O Device:
You should only need to do this if the above code was called frequently. |
Solution: |
Keywords: |
Related Links
Attachments