Applies To:
  • CitectSCADA
Summary:
What is the best way to set up a project using Citect's OPC client driver? 

Solution:
This article may not explain the "best" way but it certainly talks through some of the issues that should be considered when setting up a project which will use Citect's OPC client driver. At the time of writing this article the most recent Citect version is 5.31 and the latest OPC driver is 1.06.03. (Also, for OPC you should have at least V5.21 SpkG as some changes were made to the compiler to support include projects)

OPC is a string address based protocol, which implies all "tags" can have up to 256 character addresses. Citect native networking talks in tag addresses. Obviously, if all addresses were 256 character strings than this would put a massive load on the Citect network traffic. To get around this potential problem, Citect uses the record number instead of the tag address. Thus, with the OPC protocol in Citect, tag order is critical. There will also be a time delay while the OPC Server obtains it data from the field device as it is requesting data from these same 256 character tags.

With the above in mind, three issues need to be discussed.

  1. Minimising delay in obtaining data from OPC Server.

Citect has a parameter, "LeaveTagsActive", that when set, ensures that the OPC Server always have the "latest" data readily available for when the Citect I/O Server requires it. Also, the Citect OPC client driver has a parameter, "UseArrays", which tells the OPC Server to request the data in blocks rather than individual tags. This has the effect of decreasing the load on the OPC Server.

  1. Tag order in Citect to optimise performance.

The Citect I/O Server (and compiler) will set up request blocks to optimise data requests and thus improve performance. Blocking is basically set-up on address and type but with OPC we are not using addresses but record numbers. Therefore, remembering that blocks are created using individual types, tags should be set-up per I/O device, per type in the variable tags database. If you are using arrays than these tags should be in order. This will improve request time. Also, do not configure tags that do not exist in your devices as the entire block will contain "bad" data. Setting the parameter block=1 in the Citect.ini file is not the fix for bad data. The fix is to remove the tags that don't exist or incorrectly defined.

  1. Changing tag order on an I/O Server will certainly affect clients before they are restarted.

A plan has to be worked out for upgrading project databases. If tags are only added to the ends of variable tag databases than it is not a problem. (Unless there are include projects involved.)

Some other general hints.

  • Use status tags to implement redundancy.
  • You may not be able to have LeaveTagsActive() on both redundant servers. You will have to experiment. (Remember - both pairs of Alarm, Trend and Report Servers will talk to the primary I/O Server anyway)
  • RSLinx does not really support the digital type. Digitals are treated as 32 bit words. If you are using digital arrays then use type 3 (long). Still define them as digitals in the variable tags database though.
  • If you are having #com errors in Citect. Check the OPC Server to see whether it is experiencing errors. (Communication events in RSLinx OPC Server)
  • If you are wondering how to address tags in the OPC Server, use an independent 3rd party client, eg. Factorysoft, Matrikon, and find the address structure from the client.
 
Keywords:
 

Attachments