Back to blog

CompactLogix L35E MS and NS LEDs: A Fault-First Guide

CompactLogix 1769-L35E MS, NS, and LNK indicators separate port, address, connection, and physical-link faults. Use this manual-based workflow to preserve first-fault evidence before resets erase t...

The EtherNet/IP indicators on a CompactLogix 1769-L35E can narrow an outage before a laptop is connected. Their value disappears quickly, however, when someone cycles power, changes an address, or replaces a switch without recording the original pattern.

Module Status (MS), Network Status (NS), and Link Status (LNK) describe different layers. Read them together and include the controller OK indicator, switch-port LEDs, and the time of failure. A single color is a starting condition, not a complete diagnosis.

CompactLogix controller and managed Ethernet switch indicators captured during fault diagnosis

Record MS, NS, LNK, controller status, and switch-port state before any reset changes the evidence.

Identify the indicator set correctly

The 1769-L35E has controller-level indicators and EtherNet/IP port indicators. The controller OK light reflects processor health. EtherNet/IP MS reports the state of the embedded communication port. NS reports its network identity and CIP connection state. LNK reports physical link activity.

Do not apply a generic indicator chart from another controller family. Similar colors can have different meanings. Use the manual for the exact catalog number and firmware generation, then interpret the pattern within the event timeline.

Read Module Status before Network Status

An unlit MS indicates that the communication port has no power. Verify controller power, chassis condition, and processor state before investigating IP addressing. Flashing green means the port is in standby, has no IP address, and is operating in BOOTP mode. Confirm that the intended BOOTP or DHCP process is available and that the address plan is controlled.

Steady green means the port is operating correctly. It does not prove that expected devices are connected; NS and connection diagnostics answer that question.

Steady red can occur while the controller holds the port in reset, while the controller is faulted, during power-up self-test, or after a nonrecoverable condition. Timing separates a normal brief self-test from a persistent failure. Flashing red indicates that port firmware is being updated; interrupting a valid update can create a larger outage.

Use Network Status to classify the network relationship

An unlit NS means the port is not initialized and has no IP address. Start with address assignment and port initialization rather than replacing cabling. Flashing green means the port has an IP address but no CIP connections are established. That can be normal for an idle controller, or it can show that expected I/O, HMI, produced/consumed, or messaging connections are absent.

Steady green means the port has an IP address and at least one Class 1 or Class 3 CIP connection is established. It confirms some network relationship, not that every required connection is healthy.

Flashing red indicates that one or more connections have timed out. The controller may still communicate with programming software while a remote I/O adapter is unavailable. Steady red indicates a duplicate IP address. Correct address ownership before replacing hardware; a new switch will not resolve two devices claiming the same address.

Check LNK and the adjacent switch port

If LNK is off while MS is healthy, inspect the physical path: connector seating, cable damage, switch power, port configuration, and negotiated link. If both ends show link but traffic still fails, move upward to VLAN, duplicate address, CIP connection, and device-state evidence.

A link light only confirms electrical link pulses. It cannot confirm correct subnetting, connection capacity, application ownership, or healthy I/O data. Likewise, a flashing link light proves activity, not that the activity is useful or correctly addressed.

Capture a first-fault record

Photograph the complete indicator panel and the connected switch port. Record time, controller mode, affected equipment, recent downloads, network changes, and whether the fault appeared during startup or steady production. If available, export the controller fault log, I/O tree status, and managed-switch events before clearing anything.

Check whether the outage affects one connection, one switch segment, or every device behind the controller. A single remote adapter timeout points toward that path. Several simultaneous timeouts can indicate an upstream switch, common power supply, network loop, or controller-port event.

Follow a pattern-based workflow

For steady red NS, disconnect or isolate suspected duplicate devices according to the site change procedure. Compare the controller’s configured address with the address-management record, BOOTP server relations, switch tables, and workstation ARP data. Correct the conflict deliberately and document the owner.

For flashing red NS, open the I/O tree and identify each timed-out module. Record connection error codes and requested packet intervals. Verify remote-device power, network path, electronic keying, and configuration. Do not assume the controller Ethernet port is defective when only one downstream connection has failed.

For flashing green NS, determine whether connections should exist. A newly cleared or unconfigured controller can legitimately have none. In a running machine, absence of all expected connections may point to an incorrect project, inhibited modules, remote devices offline, or a path configuration error.

Avoid evidence-destroying recovery habits

A power cycle may restore a transient connection while deleting the best diagnostic state. Replacing multiple cables or switches at once prevents root-cause isolation. If production requires rapid recovery, capture a minimum evidence set first: photograph, timestamp, controller mode, affected devices, switch port, and fault code.

When substitution is necessary, change one element and observe long enough to cover the normal failure interval. Label removed components and preserve their port configuration. A spare that appears to fix the problem may simply have reset a duplicate address or marginal connector.

Build permanent diagnostics around an obsolete platform

The 1769-L35E is a legacy controller, so lifecycle planning should accompany fault repair. Maintain verified backups, firmware records, address assignments, compatible programming software, and tested spare hardware. Map expected CIP connections and retain switch configurations outside the running devices.

PLC hardware and migration candidates are organized under PLC & PAC Systems, while managed switches and communication components can be reviewed in Communication & Networking.

First-fault capture should also exist in logic. Latch the first lost-connection event with a timestamp and affected device. Preserve counters long enough for maintenance to review them. An LED pattern can vanish in seconds; a structured event record turns the next interruption into diagnosable evidence.

Leave a comment

Please note, comments need to be approved before they are published.