Logging Allen-Bradley PLC data to Canary Historian: OPC UA, OPC DA or the Ignition module

Canary's collector list has no collector that talks to a ControlLogix or CompactLogix controller directly. Tags from an Allen-Bradley PLC reach the Canary Historian through software that already reads the PLC: an OPC UA server, an OPC DA server, or an Ignition gateway running Canary's module. This article compares the three paths using Canary's and Inductive Automation's documentation, with the settings that matter on each. How the Canary System is built (collectors, store and forward, Views, Axiom) is covered in Canary Historian architecture.

Path 1: an OPC UA server and Canary's OPC UA collector

The OPC UA collector follows the OPC Foundation standard and connects to any OPC UA server that reads the PLC. Canary lists these settings on it: deadbands, data transformation, the update rate (sample interval), custom metadata and timestamp precision. Values go to the store and forward service and then to the Historian; when the collector runs on another machine than the Historian, Canary describes a single gRPC endpoint on port 55291 between them.

Two points from Canary's documentation affect the plan. The OPC UA collector rejects values with historical or duplicate timestamps, so it is for live data, not for loading old records. And for redundancy, Canary supports two OPC collectors each logging from its own OPC server ("hot-hot"), keeping the first value that arrives for each timestamp; hot/cold OPC servers with separate collectors are not supported.

For a new system this is the path we would normally look at first, because OPC UA does not depend on Windows DCOM.

Path 2: an OPC DA server and Canary's OPC DA collector

Many plants already run an OPC DA server for their SCADA. Canary's OPC DA collector supports local and remote sessions, deadbands, update rates, predefined metadata, transformations, and logging triggered by the value of another tag. The same timestamp rule applies as for OPC UA.

The weak point is the transport: a remote OPC DA session runs over Windows COM/DCOM, which recent Windows hardening has made harder to keep working between machines (see OPC DA and DCOM errors after Windows updates). Canary's own recommendation to install collectors on or near the data source helps here: an OPC DA collector on the same machine as the OPC DA server uses a local session and avoids remote DCOM.

Path 3: an Ignition gateway and the Canary module

Where the plant runs Ignition, the PLC is already read by Ignition's Allen-Bradley drivers. In Ignition 8.3 the Logix driver covers ControlLogix and CompactLogix with firmware v20.19 and later; older firmware uses the legacy drivers. Canary's module for Ignition, which Canary says is approved by Inductive Automation, then logs Ignition tags to Canary. Canary's configuration article for version 25 gives these points:

• The module is built on Ignition's Tag History module, so the history settings on each tag (deadband, minimum and maximum sample time) still apply.
• The Canary services are installed on the gateway machine (Admin Service, Identity, Store & Forward and Admin Client); store and forward is recommended local to the gateway for buffering.
• A collector is created in the gateway as a tag storage provider; in the Designer it is then chosen as the history provider of each tag to log.
• The module connects to the Canary service on port 55293 (version 24 and later); one or more Historians can be named.
• Each collector logs to a DataSet; Canary advises keeping a DataSet under 25,000 tags unless dynamic DataSets are enabled. An API token is needed if tag security is enabled in Canary Identity.
• On redundant gateways the configuration is duplicated on the backup; Canary warns that buffered data can be at risk if a failover lasts long, because of a 2 GB file limit.

Canary's latest tested Ignition version listed in that article is 8.1.52. Check the module release notes against the Ignition version on site before planning.

Which path fits

In all three cases the PLC program does not need to change for logging, provided the tags to log already exist; what changes is the load on the PLC from the extra read requests, which is set by the update rates chosen in the OPC server or in Ignition.

What to agree before configuring

• The list of PLC tags to log, with engineering units and the deadband for each type of signal.
• Which software reads the PLCs today, and whether it has spare capacity for the extra tags.
• Where the collector and store and forward run, and the disk space for buffering.
• Firewall openings: port 55291 between store and forward services, and port 55293 if the Ignition module is used.
• DataSet structure and tag names, settled before data accumulates.

How TDL approaches it

TDL Industrial Automation is a Canary Certified Partner, listed on Canary's partner page for Vietnam, and an Ignition Certified Integrator of Inductive Automation. Most of the plants we work in run Allen-Bradley controllers, so the work usually starts by reading the existing PLC programs and SCADA tag databases to build the tag list, then choosing the path above that uses software the plant already has.