RSLogix 5000 / Studio 5000 Controller Fault History: How to Read Timestamps and Navigate to the Faulting Rung

Access the Fault History tab first, not the Faults tab. The Faults tab shows only the current active fault — as soon as you clear the fault, that information is gone. The Fault History tab retains up to 16 entries through power cycles and fault clears, preserving the fault type, code, timestamp, and the exact program location (task, program, routine, rung) of each fault. Most technicians who learn Studio 5000 (formerly RSLogix 5000) learn to clear faults immediately and lose the diagnostic context every time. This guide covers RSLogix 5000 / Studio 5000 controller fault history: how to read timestamps and navigate to the faulting rung, interpret the fault location data to identify the root cause, and export the history for long-term tracking.

• Faults Tab vs Fault History Tab: What Each Contains
• Accessing the Fault History in Studio 5000
• Reading a Fault History Entry: All Fields Explained
• Understanding the Timestamp: Controller Clock vs Wallclock
• Navigating Directly to the Faulting Rung
• Exporting the Fault History to a Report
• Technical Validation
• Frequently Asked Questions

Faults Tab vs Fault History Tab: What Each Contains

Studio 5000 provides two fault views in the Controller Properties dialog:

The Fault History tab is the primary diagnostic tool for recurring faults. If a controller faults intermittently (once per shift, once per day), the Fault History preserves the record of previous events that allowed the pattern to be identified. The Faults tab shows only the most recent occurrence.

Accessing the Fault History in Studio 5000

Studio 5000 → Go Online (connect to the controller) →
Controller Organizer (left panel): right-click Controller → Properties →
OR: Controller Properties button in the toolbar →

Controller Properties dialog → 
Fault History tab (at the top of the dialog)

The Fault History tab requires the controller to be online — it cannot be viewed offline from a saved project file because the Fault History is stored in the controller’s non-volatile memory, not in the project file.

If the controller is in FAULT mode: the Controller Properties dialog is still accessible from Studio 5000 when online, even while the controller is in FAULT. This is critical — read the Fault History before clearing the fault, not after.

Reading a Fault History Entry: All Fields Explained

Each Fault History entry contains the following fields:

For the complete Type and Code reference tables, see Allen-Bradley Controllogix Fault Codes Complete List Studio 5000.

Understanding the Timestamp: Controller Clock vs Wallclock

The timestamp in the Fault History is the controller’s internal clock time at the moment the fault occurred. The controller clock is maintained by the controller’s real-time clock (RTC), which is powered by the backup battery when mains power is absent.

Why the timestamp may be inaccurate: 1. Battery discharged: if the controller battery has been discharged, the RTC loses its setting on power loss. After a power restore, the controller clock may show a default date (typically 1/1/2000 or similar) until manually set 2. Clock not synchronized: the controller clock drifts over time (typically ±1 minute per month for Logix5000 controllers) and must be periodically synchronized 3. Time zone not configured: the controller clock does not have a time zone setting — it stores absolute time. If the project was downloaded from a workstation in a different time zone, the clock may be offset

Synchronizing the controller clock:

Studio 5000 → Online →
Controller Properties → Date/Time tab →
"Synchronize with computer time" → OK

This sets the controller RTC to match the workstation time. For production environments, using the controller’s CST (Coordinated System Time) feature with a Logix network time server provides automatic clock synchronization across multiple controllers.

Navigating Directly to the Faulting Rung

Studio 5000 provides direct navigation from the Fault History entry to the specific rung that caused the fault. This eliminates manual searching through the program:

Method 1 — From Fault History while online:

Controller Properties → Fault History tab →
Select the fault entry → 
Click [Go To Rung] button (if available for the fault type) →
Studio 5000 opens the routine and highlights the faulting rung

Method 2 — Manual navigation using Task/Program/Routine/Rung data:

Studio 5000 → Project tree → Controller Organizer →
Tasks → [Task name from fault history] →
Programs → [Program name from fault history] →
Routines → [Routine name from fault history] →
Rung [number from fault history] → examine the instruction at that rung

What to look for at the faulting rung: – For Type 4, Code 42 (watchdog): this is the rung executing when the watchdog expired — the actual scan bottleneck may be earlier in the program, not on this specific rung – For Type 4, Code 20 (illegal instruction): this rung contains the offending instruction — the Sub-code identifies whether it’s a firmware issue (Sub-code 0), operand issue (Sub-code 1), or license issue (Sub-code 3) – For Type 3, Code 16 (I/O fault): this rung is executing an instruction that references the failed I/O module’s tags

For Type 4 Code 20 detailed diagnosis, see Compactlogix Major Fault Type 4 Code 20 Illegal Instruction Fix. For Type 4 Code 42 watchdog fix, see Controllogix Watchdog Timeout Fault Type 4 Code 42 Fix Studio 5000.

Exporting the Fault History to a Report

Studio 5000 does not provide a direct export-to-CSV function for the Fault History tab. However, several approaches allow preserving the fault history data:

Method 1 — Screenshot: capture the Fault History tab content with a screenshot (Print Screen or Snipping Tool) before clearing faults. This is the fastest method for preserving the 16-entry history before maintenance work.

Method 2 — GSV instruction in the program: the Get System Value (GSV) instruction can read the Fault History programmatically. The FaultHistory system attribute stores the fault log entries as a structured array in the controller:

GSV(Controller, ., FaultHistory, FaultHistoryArray)

where FaultHistoryArray is a user-defined array of FAULT data type elements. This data can then be written to a data file or transmitted to a historian.

GSV Fault History Export to CSV — Full Implementation

Studio 5000 does not have a built-in fault log export to CSV. The following ladder logic implementation uses a GSV instruction to read the controller fault code and timestamp, then routes it to a user-defined array that can be exported via FactoryTalk Historian or a .CSV PRINT file through RSLinx.

Rung 1 — Read fault code on fault transition:

XIC FaultDetected    GSV[ControllerFaultCode, MajorFaultCode]    MOV[FaultCode, FaultLog[FaultLogIndex].Code]

Rung 2 — Read system clock timestamp:

XIC FaultDetected    GSV[WallClockTime, LocalDateTime]    MOV[DateTime, FaultLog[FaultLogIndex].Timestamp]

Rung 3 — Increment log index:

XIC FaultDetected    ADD FaultLogIndex, 1, FaultLogIndex    CMP FaultLogIndex >= 100 → MOV 0, FaultLogIndex

Export path to CSV: 1. In Studio 5000, go online → Controller → Export Tags → select FaultLog array → export as CSV. 2. The exported CSV contains: Index, Code (hex), Timestamp (epoch), Description (empty — add via VLOOKUP in Excel against the Studio 5000 fault code table). 3. Alternatively, configure FactoryTalk Diagnostics (if licensed) → Data Logger → point to the FaultLog array → auto-export on array update.

FactoryTalk Diagnostics path: If FactoryTalk Diagnostics is available, it provides native fault logging with timestamps and rung references without the GSV ladder logic. Navigate to FactoryTalk Diagnostics → Controller Fault tab → right-click → Export to CSV. This gives a richer export including the faulting rung reference automatically.

Method 3 — FactoryTalk Alarms: FactoryTalk Alarms and Events (a separate Rockwell product) can be configured to log alarm conditions (including fault events from the controller) to a SQL database with permanent retention and reporting capabilities. This provides a complete audit trail beyond the 16-entry rolling Fault History.

For the comparison between Siemens diagnostic buffer (100–3200 entries) and Allen-Bradley Fault History (16 entries) that highlights this limitation, see Siemens Vs Allen-Bradley Plc Error Code System Comparison Guide.

Technical Validation

Controller Fault History fields and GSV FaultHistory access from Rockwell Publication 1756-PM014. Studio 5000 fault diagnosis workflow from NFM Consulting Allen-Bradley faultfinding diagnostics guide. Industrial PLC diagnostic and maintenance training from Moraine Park Technical College PLC manufacturing boot camps.

Frequently Asked Questions

The Fault History shows 16 entries all of the same Type 3, Code 16 fault, filling the entire history. Is there a way to see faults before these 16 events?

No — the Fault History is a rolling 16-entry buffer. When 16 identical faults fill the buffer, all earlier fault history is overwritten. To recover earlier history, check the controller’s wallclock data: if the timestamps on the 16 identical entries are all within the last 30 minutes, the I/O fault that caused the recent cascade is recent and likely the dominant issue. For persistent I/O fault monitoring with full history, implement GSV(Controller, ., FaultHistory, array) to programmatically copy each new entry to a larger array in a retain data block (or to a historian). For the specific fix for recurring Type 3, Code 16 faults, see the I/O module connection troubleshooting guide.

The Fault History timestamp shows 01/01/2000 for all entries. How do I correct the controller clock so future fault timestamps are accurate?

The 01/01/2000 timestamp indicates the controller RTC lost its time setting (discharged battery or power cycle with no battery). Fix: Studio 5000 → Online → Controller Properties → Date/Time tab → “Synchronize with computer time” → OK. Verify the workstation time is accurate (check against an NTP server) before synchronizing. After synchronization, replace the controller battery to prevent recurrence. Future fault entries will use the corrected time. Historical entries at 01/01/2000 cannot be re-timestamped — they represent real events but without useful time context.

Is the RSLogix 5000 Fault History identical to the Studio 5000 Fault History, or did the product rename introduce any functional changes to fault logging?

The product rename from RSLogix 5000 to Studio 5000 (Logix Designer) at version 21 did not change the underlying Fault History functionality or data format. The Fault History tab is accessible at the same location (Controller Properties → Fault History) and stores the same fields (Type, Code, Sub-code, Task, Program, Routine, Rung, Timestamp). The GSV instruction syntax for reading FaultHistory programmatically is also unchanged. Projects created in RSLogix 5000 open in Studio 5000 without modification. The Fault History data format is identical — a technician familiar with fault reading in RSLogix 5000 V20 can apply the same knowledge to Studio 5000 V35.