Citect opc server
An appropriate joining scheme was then applied and used to create required associations, and at the same time, maintain the Citect Tag Name reference for the HMI aspect. Additionally, the IA Script Module has the functionality to browse, create, and edit tags programmatically.Īn analysis was performed on the data relationships of the available export formats resulting in a scheme where the Citect and TOP Server data could be placed in SQL tables.
TOP Server also has an export feature available for its tag structure consisting of approximately the same attributes as Citect.Ignition has the ability to import tags. The file is available to be copied and used externally from Citect. This would allow validation that the correct equipment type was referenced from the calling object and appropriate tag attributes were set in the tag.Ĭitect is extremely limited in its ability to reliably export system internals, but does have a tag file available known as ‘variable.dbf.’ This file contains the Citect tag name, engineering unit data, documentation, and a path reference to TOP Server. A second problem surfaced in regard to the functional test validation process a method was required to expose the Ignition tags inside the new Ignition HMI screens. Additionally, the Citect original tag name had to be maintained somewhere for reference to reverse-engineer the HMI port. Due to the volume of tags, coupled with the tag organization requirement, using the Ignition tag-by-tag/drag-and-drop method from the TOP Server was not feasible. The Citect tag system consists of approximately 25,000 tags referencing the TOP Server OPC server. It became clear at the outset that the ability to normalize the Ignition tag tree into hierarchical groupings of Equipment Type and Component type was required to drive and validate the port.
CITECT OPC SERVER WINDOWS
Due to this, for functional validation to be effective, the ‘new’ Ignition windows had to contain graphics objects with a look, window placement, and behavior equivalent to the Citect system. As there was no overall documentation for the legacy system, the port consisted of reverse-engineering the entire Citect system. The goal of the port was to move the entire legacy system to Ignition, and, as part of the process, normalize the tag tree and naming conventions with uniform HMI navigation behavior. Each party had their own methodology, naming conventions, and standards for graphic objects. The Citect system is a legacy system with various iterations enhanced over time by various parties. The project involved porting a Citect SCADA platform project based on TOP Server as the OPC server. The client is Continental Cement, a continuous-process cement plant located in Hannibal, Missouri. Ignition Exchange Community-made Ignition resources.Ignition Maker Edition Made for hobbyist and educational use.Ignition Edge Made for field and OEM devices at the edge.To determine which OPC DA interfaces are supported by the Citect SCADA OPC DA Server, see the topic Supported OPC DA Server Interfaces in the reference section of this chapter.
For example, if retrieving tags with 'bit' in the name, you need to define "bit.*" instead of "bit*". The OPC DA server uses regular expressions.
This mode of operation has not been validated. Connecting a Citect SCADA OPC DA client to an Citect SCADA OPC DA server is not recommended, as the client was not designed to be used in this way.The OPC DA Server does not fully support WriteVQT functionality, as a Citect SCADA I/O server does not allow quality and timestamp changes that are generated from an external source.
This behavior is different to releases 7.20 and earlier where no configuration step was required. In order to allow OPC DA Server to be accessed by the OPC DA Clients, the OPC DA Server process must be configured in the SCADA project. This allows Citect SCADA to provide real-time data to any compliant OPC DA clients, including applications such as AMPLA, OSI-PI and Historian. To this end, Citect SCADA supports a runtime OPC DA server that implements the mandatory OPC DA v2.05 and OPC DA v3 interface specifications. The OPC Data Access solution (OPC DA) provides specifications for client and server applications that are focused on the continuous communication of real-time data. OPC provides a common platform for applications to share data from typically disparate sources, such as PLCs and databases, without the need to comprehend native protocols. OPC (OLE for Process Control) is a set of communication standards maintained by the OPC Foundation for the industrial automation industry. Extensibility > Using an OPC DA Server | Extensibility Using an OPC DA Server