Why Does CompactLogix Fault When Ignition Adds a Tag?

The panel shows a controller fault, not just a failed OPC tag: in this 1769-L35E setup, adding a browsed INT tag was followed by a controller fault, lost communications, and repeated Ignition timeouts. The device and OPC-UA status had appeared connected, and the controller tags were visible in the browse tree before the fault. Stop repeating the operation; the reported power-up fault erased controller settings and the loaded program. The driver defect was reproduced and corrected with an update module, so prioritize that correction over database, IP, or operating-system changes.

Read the controller fault before the OPC timeout

Check the controller’s fault indication first. The timeout is downstream evidence: once the controller faults and its connection drops, Ignition cannot complete reads. In the reported sequence, the user selected a controller INT tag in the Designer and clicked OK; the controller then faulted, and the Ignition console began reporting read timeouts.

The report also describes the controller first encountering a Major Recoverable Fault and then displaying the Type 01/Code 60 power-up fault. Preserve the exact wording and sequence from the controller diagnostics rather than collapsing those descriptions into one fault category. The timeouts that follow do not explain why the controller faulted.

Separate controller failure from ordinary network loss

Use the order of events to choose the first diagnostic branch. Here, the IP device at 192.0.0.242 displayed connected, OPC-UA status displayed connected, and browsing reached the controller program and tags. The fault appeared only after the operator selected a tag to add. That progression makes a simple wrong-IP or unreachable-device diagnosis a poor first fit.

A successful browse is not a complete read test. Browsing and reading are different operations: the client must enumerate tag metadata, then form a request for a selected tag and process the response. A connection can therefore look healthy while an operation on particular tag metadata exposes a driver defect.

Check the network first only if the device never reaches connected state, the browse tree cannot be reached, or the fault does not correlate with the tag operation. If the controller faults at the add-tag step, preserve that correlation and investigate the driver path before changing routing, subnet, or firewall settings without evidence of a network failure.

Trace the browse and add sequence through the driver

The reported failure evolved across two driver states. Before the correction, adding the selected tag preceded the controller fault. Ignition then logged read timeouts and connection resets. The trace also contains a Java MissingFormatArgumentException in ABControlLogixBrowseRequest.receiveMessage. That exception identifies a failure in the driver’s browse-response handling or error-reporting path; it is not a controller fault code and does not, on its own, identify the controller-side trigger.

After build 4446 was loaded, the previous fault behavior was no longer the only symptom: browse results omitted a tag with the message Not Including tag named basic_tag in browse results because tag offset is invalid. The user reported the same invalid-offset result while checking multiple data types. This points the investigation toward how the driver handles tag offsets, but it does not reveal the exact protocol field or internal parsing error. Do not infer a specific malformed request from the log alone.

The decisive installation-specific finding is that the issue was reproduced using the CompactLogix program and an update module was provided to fix it. That distinguishes this incident from a generic inability to connect: the known failure path involved driver behavior exposed by CompactLogix tag browsing/reading, and a driver correction resolved the reproduced issue.

Capture the controller and Ignition evidence

Before changing the project or driver, collect evidence that ties the controller event to the Ignition request. The support diagnostic sequence in the report was:

1. In the Ignition Gateway, open Configure, then Console, then Levels.
2. Enter ControlLogixDriver and click Set.
3. Set the level to Trace for xopc.drivers.allenbradley.ControlLogixDriver.
4. Reproduce only if the controller and program can be safely restored; collect all wrapper.log files and the test project for Inductive Automation support.

Record the controller fault text and time, the exact Designer action immediately before it, the device state, and the first timeout or connection-reset message. Preserve logs from before and after the fault. The first event in that sequence matters more than the later repeated timeout lines.

Keep separate copies of the existing project and controller program before a controlled reproduction. In the reported incident, the fault wiped controller settings and the loaded program; a test program was supplied to support for reproduction. If you cannot restore the controller to its known state, do not recreate the failure just to gather another log.

Isolate the tag operation before another test

Remove or disable the affected Ignition device to stop the repeated request cycle; the report says the timeouts continued until the device was removed. Do not add more tags or cycle through data types on the same vulnerable configuration. Repeating the same failing operation adds risk without distinguishing the driver defect from the already observed symptom.

1. Document the current Ignition build or module state, including build 4446 if that is the build under test. The initial build in the report was not specified, so do not assume all installs share the same behavior.
2. Keep the test on a controller/program that can be restored. Avoid production testing when the observed fault can erase the loaded program or settings.
3. Use one known test tag and one controlled browse/add attempt only after the driver correction is in place or support requests a reproduction.
4. If the tag is omitted with an invalid-offset message, save that log and stop. Do not work around the omission by repeatedly selecting other data types.

The MySQL database was already functioning in the reported setup, but the failure occurred while the OPC device tag was being added. Database changes are therefore not the first corrective action. Likewise, switching from Linux/Ubuntu to a Windows/RSLinx arrangement would change multiple variables and is not a substitute for the driver correction that reproduced and fixed this failure.

Apply the driver correction through support

Do not treat build 4446 as the fix: after that build, the device could no longer browse tags, and the log named an invalid tag offset. A later update module was reported to correct the reproduced CompactLogix problem. The exact module version and compatibility range are not stated here, so obtain the correction that matches your installed Ignition release from Inductive Automation support rather than copying an unverified module from another installation.

Give support the project, all relevant wrapper.log files, the controller fault description, the observed tag operation, and the Ignition build/module details. Ask support to confirm which corrected module applies to your install and how to install it. The report demonstrates that a targeted module correction worked for the reproduced program; it does not establish that every Ignition build or CompactLogix configuration uses the same module.

After applying a support-provided module, confirm the gateway is running the intended module before testing. Do not change controller firmware, redesign the tag structure, or alter network settings as a speculative workaround when the reproduced fault was corrected in the driver module.

Verify browse and reads without provoking another fault

Verify in a controlled sequence, stopping at the first recurrence. Check that the controller remains in its normal operating state before and after each operation. The purpose is to confirm both the browse path and tag-read path; a connected indicator alone is insufficient.

1. Confirm the gateway reports the corrected device as connected and the OPC-UA status page remains connected.
2. Browse to the controller program and confirm the intended test tag appears without an invalid-offset omission.
3. Add one test tag, then compare its value with the controller’s online value using the controller monitoring method available at the site.
4. Watch the controller fault indication and Ignition logs during the read. Confirm there is no new controller fault, repeated TIMEOUT, or connection reset.
5. Only after the single-tag check succeeds, proceed with the remaining required tags in a controlled test and confirm the controller program and settings remain intact.

If browse works but a read still faults the controller, stop and provide support with the complete before/after logs and exact tag operation. If the invalid-offset message remains, the browse path is not verified even if the device indicator says connected. Do not call the issue resolved until the controller stays online through both browse and read activity.

Skip fixes that target the wrong subsystem

• Do not chase the database first. The database was already functioning, and the failure began in the device-tag workflow. MySQL operation does not establish that the Allen-Bradley driver can parse or read a controller tag.
• Do not treat a connected status as proof of correct tag handling. The reported device and OPC-UA service showed connected, and tags were browsable before adding the test tag caused the fault.
• Do not treat timeouts as the root cause. They followed the controller fault and loss of communications. Repeated timeout messages can be consequences of the controller becoming unavailable.
• Do not treat the Java formatting exception as the PLC fault code. MissingFormatArgumentException occurred in a driver browse-request stack trace; the controller separately reported its Type 01/Code 60 fault.
• Do not keep trying every data type. The build 4446 test still produced invalid-offset browse messages across data-type checks. More attempts do not repair the driver and can risk another destructive controller event.

FAQ