CLICK PLC SC Bits: Find System Control Definitions

Overview

The CLICK PLC exposes a block of system status bits addressed SC1, SC2, SC3... Each carries a default nickname such as _PLC_Mode on SC11. The nicknames are self-documenting for obvious flags (battery low, scan overrun style names), but they do not tell you the polarity or the exact condition that sets the bit. That matters the moment you decide to publish PLC health data to a ControlLogix controller over EtherNet/IP, because a mis-read polarity on a mode bit turns your "PLC in RUN" indicator into a silent false-positive.

This note covers three things: where the authoritative SC bit definitions live, how to confirm a bit's semantics empirically before you trust it, and how to get those bits into the adapter-mode I/O image that a ControlLogix scanner reads.

Where the SC Bit Definitions Are Documented

The complete list is in the CLICK programming software help file, not in the printed hardware chapters of the user manual. The manual documents a subset in passing; the help file carries the full table.

1. Open the CLICK programming software.
2. Open Help and go to the search (not index) tab.
3. Enter System Control.
4. Open the returned topic and locate the address column entry for the bit you care about — for example SC11.
5. Read the condition that sets the bit, not just the nickname. Record the ON-state meaning in your own project documentation, because that is what your ControlLogix logic will key off.

Do the same lookup for every SC bit you intend to publish. Copy the description text into a comment block in the CLICK program or into the ControlLogix tag description so the meaning travels with the code.

Verify Bit Semantics Before You Trust Them

Documentation lookup is step one; a bench confirmation is step two, and it takes about two minutes. Polarity assumptions (does SC11 = 1 mean RUN, or does it mean STOP?) are the single most common source of inverted status indications in a remote-I/O integration.

1. Connect online to the CLICK with the programming software.
2. Open a Data View / monitoring window and add the SC address under test. Monitoring works independently of whether the ladder is scanning, so the bit state remains observable in both processor modes.
3. Place the PLC in RUN. Record the bit state.
4. Place the PLC in STOP. Record the bit state again.
5. Compare against the help-file description. If the two disagree, the help text is being read out of context — re-read the exact topic before changing your logic.

Packing Status Into the EtherNet/IP Adapter Image

In adapter mode the CLICK presents a fixed block of its memory to the scanner. Which memory types are eligible for that block is defined in the EtherNet/IP setup dialog inside the CLICK programming software — open that dialog and read the selectable ranges before designing the payload. Do not assume system memory is directly exposable.

The portable approach, which works regardless of whether SC addresses are selectable in the adapter dialog:

1. Reserve a status word. Pick a contiguous user bit range (for example a block of C bits) or a single DS integer that you will dedicate to health/status.
2. Copy each SC bit into that block in ladder. A simple contact-on-SCn driving an output coil on the corresponding user bit is sufficient. This keeps the network payload stable even if you later re-order which SC bits you care about.
3. Latch transient flags as described above so short-lived conditions are not lost between RPI samples.
4. Add the status block to the adapter I/O configuration in the EtherNet/IP setup dialog, so it lands in the input assembly the ControlLogix reads.
5. Add a heartbeat. Toggle one bit in the status word from a self-resetting timer in the CLICK. This is the only reliable way for the ControlLogix to distinguish "CLICK stopped scanning" from "CLICK is running but all flags are clear."

Item 5 is not optional for remote-I/O duty. When a CLICK is in STOP, its ladder does not execute, so any status bit you assemble in ladder freezes at its last value. A frozen non-zero status word looks identical to a healthy one. A heartbeat that stops toggling does not.

ControlLogix Side: Consuming the Status Word

On the scanner, the CLICK appears as a generic EtherNet/IP device with input and output assembly instances and sizes matching what you configured in the CLICK. Build the diagnostic logic around three layers:

Set the heartbeat watchdog preset to at least three to five times the CLICK's heartbeat toggle period so normal jitter and RPI phasing do not nuisance-trip it. Alias each decoded bit to a descriptive tag and paste the help-file description into the tag comment — that comment is what the next person troubleshooting at 03:00 will read.

Verification Checklist

1. Every SC bit you publish has its help-file definition recorded in a program comment on the CLICK side and a tag description on the Logix side.
2. Polarity of each mode-type bit confirmed by an actual RUN/STOP transition, observed online.
3. All transient bits latched into user memory with a defined reset path.
4. Heartbeat bit present in the input assembly and toggling at a period well under the Logix watchdog preset.
5. Pull the Ethernet cable: Logix reports connection fault, and downstream logic falls to its safe state.
6. Put the CLICK in STOP with the cable connected: connection stays up, heartbeat watchdog trips, downstream logic falls to its safe state.
7. Input assembly size on the Logix generic module matches the block size configured in the CLICK EtherNet/IP setup, in bytes. A mismatch produces a connection error rather than shifted data — verify the size before blaming addressing.

FAQ