Configuring 1756-EN2TR Port Status for PLC Alarms Guide

After the fix, each port indication holds its last sampled state while its MSG is busy, and a successful read updates the link and negotiation bits. For a 1756-EN2TR, treat the proposed port instances as candidates to validate: the reported MSG mapping was extrapolated from other modules, not confirmed on this card.

Does the screen show a real link loss or a brief MSG gap?

When an HMI link indicator drops as soon as a read starts, check the controller result before diagnosing a cable. A Logix MSG clears its .DN status when a new execution begins and sets it again when the operation completes. Logic that directly drives the HMI indication from the current MSG result can therefore show a false brief loss even when the physical link stayed up.

Trace the indication from screen to controller: identify the HMI tag, find the rung or routine that writes it, and check whether that rung uses the current MSG .DN state as the link state. A port-status read reports a sampled value; it is not itself a continuously updated screen signal. Keep read health and sampled port state distinct so a busy or failed read does not masquerade as a physical link change.

Does the MSG target and service match the intended module?

Read the MSG configuration first. The described transaction is CIP Generic, service Get Attribute Single, class , attribute 2, with the path set to the module in the I/O tree and a DINT destination such as LinkStatusRaw. A service or route mismatch prevents a valid status sample; it does not establish that the port is down.

For controller on-board ports, the reported path was THIS and the MSG did not need the module EntryStatus condition. That is a separate routing case; do not substitute it for the module path when reading a chassis module.

Which port instance answers the question?

The proposed port selection is the main validation point for the EN2TR. The described arrangement uses instance 1 for one port and instance 2 for the other with the same service, class, and attribute. The original mapping was known from an EN2T and a dual-port L306 and extrapolated to the EN2TR. Commission the two candidate reads independently and confirm their response against each physical port before connecting either result to an alarm.

1. Configure one MSG for instance 1 and a second for instance 2, each with its own DINT destination.
2. Condition each module MSG on the module being connected, using the controller's existing EntryStatus logic.
3. With the network operating normally, record both returned values and identify which candidate responds to each port by observing a controlled link change on one port at a time.
4. If a read fails or its mapping does not follow the corresponding port change, check the module's supported status mechanism and MSG response before using that instance in alarm logic.

Changing one connection at a time isolates the meaning of each instance. If both bits change together or neither follows the physical port, stop and resolve the mapping or read problem rather than interpreting an unverified bit as port status.

What do the returned bits tell the operator?

If the only required indication is whether a link is active, the direct raw-result check is LinkStatusRaw.0. For additional status, the described logic extracts three bits beginning at raw bit 2 into bit 0 of an INT using BTD, then applies AND with 7 to clear unrelated bits. The resulting field is the negotiation value, not the active-link bit.

The reported bit labels for link activity and duplex refer to a raw status structure, while the negotiation field is explicitly shifted from raw bit 2. Keep those interpretations separate in the tag names and HMI text; do not label negotiation values as link state.

Does the alarm logic preserve the last valid sample?

Directly tying each indication to a one-shot MSG result can clear the indication during the transaction. A delay alarm may hide a short drop, but it leaves the presentation dependent on MSG timing. The proposed correction is state-retentive logic: while the MSG is enabled, use a true status bit to latch the corresponding indication and a false status bit to unlatch it. This lets the displayed state ride through the busy interval instead of turning off just because .DN cleared.

1. On a completed, valid read, evaluate each decoded status bit.
2. For each indication, use the true condition to execute OTL and the false condition to execute OTU on the same destination bit.
3. Keep read completion or validity separate from the retained link indication; do not unlatch all port states merely because a new MSG has started.
4. Define what the HMI should show if reads stop completing. A retained last sample is not proof that the current port remains healthy.

The OTL/OTU pattern addresses the brief MSG-enabled gap; it does not make stale data current. Use the MSG completion/health indication separately so operators can distinguish “last sample showed link active” from “a recent read confirms link active.”

How do you verify the alarm without mistaking a tag fault?

Compare four layers during commissioning: physical port change, MSG result, decoded controller tag, and HMI indication. A wrong or stale raw value points first to the read, route, or instance; a correct controller value with a wrong screen points to tag binding or display logic.

1. Monitor each MSG's completion and destination DINT while both links are in their normal state.
2. Change one port's connection state at a time under an approved commissioning condition; verify the corresponding raw status bit changes and the other port's result does not incorrectly substitute for it.
3. Confirm decoded active, duplex, and hardware-fault indications match the returned value and the selected port instance.
4. Check that the HMI uses the intended controller tags and that an MSG busy interval does not clear a latched indication.
5. Verify the HMI separately shows stale or failed reads, then repeat the port transition and confirm the alarm changes only on the validated port sample.

What happens if the MSG is busy?