Applies To:
  • CitectSCADA v7.1 and above
  • VijeoCitect v7.1 and above


The article below was written at the time of the first release of the OFSOPC driver, and was tested with OFS v3.34.

It is intended as a substitute to KB Q5582.

The OFSOPC driver is designed to uniquely connect to the OFS server. As a result, it is already optimized to achieve the best possible OPC communication with the OFS server. The driver also takes advantage of a few non-OPC standard features that OFS has to offer.

The current architecture of the OFSOPC driver only supports having VijeoCitect and OFS on the same physical machine.

It is therefore important to note that most communication delays and optimization will be on the link between the OFS Server and the PLCs. We advise that the channel between OFS and the PLC should therefore first be analysed and optimized, before modifying any SCADA parameters.

There are however some useful driver statistics that will be shown in the “driver” page of the SCADA kernel and which will help you analyze the health of the communication channel down to the PLC level.

This KB article is intended to cover some common requirements and considerations as a rough guide to analysing and tuning the communication channel from the SCADA level down to the PLC.

  1. Considerations about the Hardware and the PLC task time

    In the OFS User Manual, Schneider Electric provides some useful data to anticipate the communication performance between OFS and the PLC.

    At the hardware level, it is important to remember that the communication performance will highly depend on :

    • the target communication module
    • the task mast period
    • the communication protocol

    More information is available in the attached pdf guide (extract of the OFS user Manual).


  2. 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


  3. 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.


    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.


OFSOPC, #COM, comms, Group, OPC