Applies To: |
|
Summary: |
The SCADA Activity recommends to use the new OFSOPC driver (to be released soon) instead of OPC when talking to the OFS Server. More information about the OFSOPC driver configuration will be available in the driver help file. The VijeoCitect OPC driver is designed to be compatible with a wide range of OPC servers, and therefore includes a good number of ini parameters which can be tuned to improve performance/communications stability. Please find below a list of the recommended ini parameters when you are using the OPC driver with the Schneider Electric OPC server: OFS. Note: All the values described as default are for OPC v2.0.6.1 and v2.0.7.2. These default values may be different for other versions of the driver. |
Solution: |
Compulsory parameters
[OPC]UseOPC2=1 OPC DA v2.0 allows for many more features than OPC v1.0a (e.g. asynchronous communications). Both OFS and VijeoCitect support OPC v2.0. We therefore recommend enabling this parameter.
[OPC]LeaveTagsActive=0 When using OFS, we recommend not leaving unneeded tags activated. By default, every block of OPC items that has not been requested in 5 seconds will automatically be de-activated from OFS. This ensures that the OFS server will only poll needed data, and will therefore minimise the load on the PLC.
[OPC]FillCacheOnStartup=0 (default) Setting FillCacheOnStartup to 1 will result in activating all OPC items on startup for 5 seconds (LeaveTagsActive=0, ItemLifeTime=5000), after which any unneeded items will be de-activated. This is now unnecessary, and this parameter has been deprecated. When activating a new item, the VijeoCitect OPC driver will always wait to have good quality, for up to [OPC]Timeout milliseconds (default is 3 seconds) before responding to the IOserver. There is therefore no risk of having incorrect data displayed on screen or of generating “ghost alarms”. [OPC]FailOnBadData=1 (default) We recommend to always display #COM when an item is received with a BAD quality. The current behaviour of the OPC driver is that as soon as an item in a block has a BAD quality, the entire block will be flagged as BAD. However, this symptom should be greatly minimised by using a small value for the [OPC]Block parameter.
[OPC]FailOnUncertain=1 An OPC item Quality may be flagged as Uncertain during IOserver switch over (in the case of IOserver redundancy). However, we recommend setting the parameter to 1, so that the driver will return #COM instead of a potentially stale value while the IO switch over is in process. You may be returned an Uncertain quality for a few seconds in the case when the Primary IOserver fails, and the standby needs to take over. When the Primary IOServer is going back online, there should be no Uncertain Quality reported.
Recommended parameters
[OPC]Block=5 to 50 Setting a low value for the Block parameter can be beneficial for many projects, as it will significantly reduce the number of OPC items activated by VijeoCitect. As a result, it should minimise the load on the PLC. However, there may be performance-related side-effects, as a small value of the Block parameter will also result in an increase of the number of requests issued by the front-end OPC driver. Any performance decrease would be most apparent when a great number of items need to be activated at the same time (e.g. startup sequence, change of page, trend scan rate, …). This parameter should therefore be tuned via actual testing on your project. Please read the section on [OPC]MaxPending below for more information.
[OPC]MaxPending=255 (default) When a small value of [OPC]Block is used, the items may be continually activating and deactivating, as the front-end OPC driver may not be sending requests quickly enough. Increasing [OPC]MaxPending to 255 will allow the front-end OPC driver to send many more requests in parallel and therefore will increase performance significantly. 255 is now the default value for this parameter (instead of 10 previously).
[OPC]ReadAfterWrite=2 When using the OPC driver with OFS, we recommend using [OPC]ReadAfterWrite=2. This will force a synchronous read of the item from the PLC immediately after the item was written. This should prevent data loss issues when a single OPC item is written to several times in a very short period of time.
[OPC]RefreshBeforeArrayWrite=2 Similarly, writes to OPC arrays require a synchronous read to retrieve the current array contents before writing each element. Previously this was done from the OPC server's cache, however for OPC servers that do not employ a write-through-cache mechanism (such as OFS) this was resulting in data loss.
[OPC]UseAsyncWrites=1 Using asynchronous writes will greatly improve write performance and may be needed in the case of recipes and array writes. Async writes are only supported with the OPC 2 standard, so if using [OPC]UseAsyncWrites=1 you must also set [OPC]UseOPC2=1
Status Tags If you are using redundant IOservers, we recommend using OPC status tags to facilitate redundancy switchover. We suggest using the tag with address %MW1 as the status tag, as this variable should be available in most Schneider devices used with OFS. You may wish to choose another tag if you find it more relevant for your project. |
Keywords: |
OPC, OFS, Block |
Related Links
Attachments