ControlLogix 5580 and 1756-EN4TR Syslog: Reading Events to Trace Lost Connections and Unexpected Stops

Besides major/minor fault codes and I/O fault codes, ControlLogix 5580 controllers and the 1756-EN4TR EtherNet/IP module also write a syslog: an event log that records when the device lost power, who reset it, who changed the network configuration, firmware updates, and whether CIP Security sessions could start. When connections drop now and then, or the controller stops and nobody can explain why, this is often the remaining place to cross-check.

What the 5580 and 1756-EN4TR syslog is

Rockwell calls this list "Syslog Fault Codes" (Knowledgebase QA66691, public), but an entry is not a hex number like 16#0204. Each entry has three parts:

• Type — the event group: Backup, CIP Security, Configuration, Discovery, System, Log.
• ID — a text event name, for example sys_powerloss or config_network_change. This is the "code" to look up.
• Message — a sentence with fields filled in when the event happens: %username% (who did it), %src% (source), %dst% (destination), %time%, %subsystem%, %count% and so on. When an action fails, the message ends with Error=%err% — the specific error number is there.

Two points QA66691 makes clear:

• The list applies to ControlLogix 5580 controllers and the 1756-EN4TR.
• The major/minor fault codes (see QA45576) and the I/O fault codes do not apply to the 1756-EN4TR. So when looking up events of the EN4TR itself, use this syslog list, not the major/minor or I/O code tables.

Where to see the syslog

QA66691 only lists the events; it does not describe the menu path to open or configure the syslog, so this article does not give those steps. What the event list itself shows:

• The device keeps its own log storage: there is an event for log storage near capacity (log_storage_almost_full) and one that records who read a log (log_user_read).
• The device can send its log to an external log service at address %dst%, over a TCP, TLS or DTLS connection (the log_tcp_client_session_*, log_tls_client_session_* and log_dtls_client_session_* events).

Rockwell covers configuring and reading the log in the Syslog Technology Reference Manual (SYSLOG-RM001), which is listed on the "Introduction" tab of 1756-RD001.

The most useful events for troubleshooting

On a CIP Security network, if a module's Connection tab shows a code in the 16#09xx group — for example 16#0909 "(D)TLS Alert 45: Certificate Expired" on the "IO" tab of 1756-RD001 — also look for cipsec_* events at the same time in the syslog. For the other I/O codes see ControlLogix I/O and connection fault codes.

Using the syslog for intermittent connection loss

1. Pin down the time. Note the code on the Connection tab (I/O fault) or the Type/Code on the "Major Faults" tab (1756-PM014O, chapters 1 and 3), and when it happened from the HMI alarm or the operations log.
2. Check the clock. Look for sys_clock_sync_lost or sys_clock_time_change around that time; if the clocks are off, comparing devices will mislead you.
3. Read the syslog at both ends: the 5580 controller and each 1756-EN4TR on the connection path. Look for sys_powerloss, sys_reset, config_network_change, firmware updates and cipsec_*_failed before and after the fault.
4. Check the log is complete. log_messages_overrun or log_storage_almost_full means the log may be missing exactly the part you need.
5. Look up guidance by ID. QA66691 refers to 1756-RD001 for the "Guidance" column, but the September 2025 edition of 1756-RD001 removed the syslog sheet ("Summary of Changes" tab); its "Introduction" tab points to Syslog Messages Reference Data (SYSLOG-RD001) instead.

When the controller stops unexpectedly

Compare the Type/Code on the "Major Faults" tab with the syslog at the same time. For example, with Type 01 Code 01 (power lost and restored in Run mode, per 1756-RD001), sys_powerloss followed by sys_powerup tells you when the power went; if instead you only find sys_reset or sys_powerdown with a user name, it was a deliberate action, not a power problem. For reading Type/Code see Logix major fault codes.

Reading the syslog changes nothing on the device. Do not reset or power-cycle just to "try again" while people are working on the machine: when the connection or the controller comes back, the machine can move at once. Every action must follow the site's lockout and permit-to-work rules.

Before calling for help

Save the syslog lines around the fault time (ID, message and time) from the controller and each EN4TR involved, the code from the Connection or Major Faults tab, firmware versions, and the network layout between controller and module. If CIP Security is enabled, include the cipsec_* events.

Need an engineer on site: request support.