Tuning OFS to achieve better communication performance
with the PLC
It is very important to consider the following parameters when
tuning the communication between OFS and the PLC.
Please also note that changing any of these values may result in
OFS being more loaded, and not being able to keep up with the
communication rate (and number of items) requested by the OPC
client. Careful consideration and testing should therefore be given
every time the following settings are modified.
Group min update rate: The default
value is 200ms. A rule of thumb is that the update rate that will
be set by the client for a given group should be a multiple of the
Group min update rate value in ms.
If optimised communications are required, we recommend setting
the Group min update rate to half the desired OPC subscription
rate. If it is required to have an OPC subscription rate faster
than 400ms, then we recommend decreasing the value of this
parameter. However, caution is advised as decreasing the value will
result in increasing the load on the entire system.
Sampling rate on reception: Defines
the period for checking data reception in milliseconds. Default
value is 50ms. If fast update rates are required, a value of 10ms
or 20 ms ensures good performances for heavy communication
load.
Max Channels: to achieve best
communication performance, this Alias attribute must be set to the
Number of requests per scan of the target communication module
(refer to the pdf document above)
Max Pendings: this Alias attribute
gives the max number of sent requests waiting for an answer. On an
Ethernet link, a good value is at min the Max Channels set above,
better performances can be reached with Max Pendings = 2* Max
Channels or Max Pendings = 3* Max Channels.
Note: For NOE Quantum,, it is recommended to set Max
Pending= Max Channels
Tuning on the SCADA side
The OPC client’s number of items and the requested update rate
have a direct impact on the OFS runtime.
It is useful to read the statistics shown in the kernel, and
documented in the OFSOPC driver help to get a feeling of the health
of the communications.
Below are a few common scenarios that may result in a tuning of
the ini parameters of the OFSOPC driver. It is highly recommended
that these parameters be changed by advanced users only.
[CODE]WriteLocal
parameter:
The [CODE]WriteLocal parameter controls whether the SCADA local
memory image is immediately updated when a tag is being written to
(from a page, or from cicode), or if it only gets updated on the
subsequent read. This parameter is a machine-wide setting.
Depending on the network speed and its reliability, customers
may choose to update values on the page as soon as the tag is being
written to ([CODE]WriteLocal=1), or only when it was verified that
the data was actually written to the I/O device
([CODE]WriteLocal=0).
If Fast update rates
are required (200ms and below - eg for trending):
- you will need to decrease the group minimum update rate in the
OFS configuration tool.
- In VijeoCitect/CitectSCADA, you will need to set
[OFSOPC]Group1UpdateRate to the required subscription rate.
- Finally, please decrease the IOdevice cache time. More
information is available in KB Q4950.
Intermittent
communication failures:
Comms failures may have various reasons.
If the failure is only intermittent (Unit goes online and
offline repeatedly), the first thing to check is whether OFS/the
PLC is able to keep up with the amount of data requested by the OPC
client (number of items, and update rate). As a first test, we
suggest that you increase the following ini parameter from 250 to
750.
[OFSOPC]Group1UpdateRate
This will result in decreasing the frequency of polling by OFS
to a large number of tags from PLC, and thus reducing the load on
the PLC. This may result in a stabilization of the overall
communication channel.
Secondly, if intermittent communication failures are still
experienced after increasing the Update Rate, you may try to
increase the DeviceTimeout and FrameTimeout
parameters in OFS. This will allow more time for the PLC to respond
to the requests sent by OFS. Please refer to the OFS User Manual
for further information.
More details:
The OFSOPC Driver evaluates the Communication status between
itself and OFS by reading the Quality of the tags “#PLCQualStatus”
and “%S0”. When the quality of these two Items goes to ‘Bad’
(mainly caused by an unstable communication channel between OFS and
the PLC), then the SCADA Unit is placed Offline and
reinitialisation process starts. It could therefore be inferred
that, due to the instability of communication between the Servers
and OFS, the SCADA redundancy feature may not work as expected and
there would appear communication gaps during swithover and
switchback.
