C-more Alarms: Local Logic, Not Remote HMI Polling

Patchy communications at 1200 baud make the central C-more display stale or unavailable when it depends on remote PLC data. Put alarm detection and alarm state in master 1B, close to the process; use the wireless bridge and TCP/IP to display those states centrally, while master 1A monitors communication health.

Stop applying the usual quick fixes

Keep alarm ownership in master 1B

Alarm ownership belongs with the controller that directly acquires the process conditions. Master 1B should evaluate limits, discrete fault conditions, and any required latching. It should retain the alarm state even when communication to 1A or the C-more is unavailable.

This separates two conditions that must never be confused:

• Process alarm: The controlled equipment has entered a defined abnormal state.
• Communication alarm: The receiving device can no longer prove that remote data is current.

Communication loss must not force a process alarm to normal. At the receiving end, mark remote values unavailable or stale and raise a separate communication failure indication. When the link returns, accept the current state from 1B; do not manufacture an alarm clear merely because the connection cycled.

Master 1A can still collect a summary for supervisory use. Transfer active alarm bits, required process values, a changing counter, and an indication that 1B is executing. Keep the data set small enough that normal exchanges finish comfortably before the next poll.

Prove each path before changing the logic

The installation contains two different communication paths: the existing 400 MHz radios at 1200 baud and the newly installed wireless bridge intended for TCP/IP. Test them separately. The one-mile separation does not identify the failure mechanism; radio diagnostics and end-to-end data freshness do.

1. Record which PLC owns every source value and which device currently calculates each alarm.
2. Confirm that 1A, 1B, and the C-more are on the intended network and have unique, reachable addresses.
3. Read the wireless bridge diagnostics for link state, signal quality, retransmissions, and disconnects. Use the fields provided by the installed bridge rather than judging the link from a single successful connection.
4. Make 1B publish a continuously changing counter. Observe it at 1A and at the C-more connection target. A connected session with a frozen counter is stale communication, not a healthy link.
5. Measure normal update time and the longest update during process traffic. Set communication supervision from measured behavior, allowing for retries without hiding a persistent failure.
6. Test the 400 MHz path by itself if it will remain as backup. Determine which minimum alarm/status block it can carry reliably at 1200 baud.

Stop here if addresses conflict, the bridge repeatedly disconnects, or diagnostics show an unstable radio path. Alarm-logic changes will not repair a physical or network-layer fault.

Configure the production architecture

1. Move or retain alarm evaluation in master 1B. Keep the source conditions and their alarm logic in the same controller.
2. Create one coherent transfer block containing the active alarm states, necessary alarm context, process values needed at the office, and a changing counter.
3. Configure the C-more to read 1B over TCP/IP when the installed C-more model and selected PLC drivers support simultaneous connections to both masters. Verify that capability in the configuration software for the installed hardware.
4. Continue polling 1B from 1A for communication supervision and any supervisory data that 1A actually needs. Do not duplicate every HMI value merely to relay it through another PLC.
5. If the installed C-more cannot communicate with both controllers in the required configuration, use 1A as a data concentrator. Keep alarm decisions in 1B; relay their resulting states through 1A.
6. If both radio paths remain, designate a primary and backup. Permit only one to supply a given data set at a time, qualify its data as fresh, and expose the selected path plus its health to the operator.

Get production running with the wireless bridge carrying the required alarm block. Then reduce unnecessary polling, document ownership, and tune supervision from recorded communication performance.

Verify alarm behavior under failure

Test the alarm system as a state machine, not just as a successful data read. Record the alarm source at 1B, the displayed state, the changing counter, the selected communication path, and the communication-failure indication.

1. Trigger a controlled alarm condition at 1B. Confirm that 1B detects it and the C-more displays it.
2. Interrupt the wireless bridge while the alarm is active. Confirm that the process alarm does not falsely clear and that the display identifies communication loss or stale quality.
3. Create a new controlled alarm while the bridge is unavailable. Confirm that 1B records or retains the state required by the PLC logic.
4. Restore the bridge. Confirm that the changing counter resumes, current alarm states appear, and no false clear is generated during reconnection.
5. If backup is configured, fail the primary path and verify one clean transfer to the backup. Restore the primary and check that the selector does not oscillate.
6. Break communication between 1A and 1B. Confirm that 1A reports a communication failure independently of the process alarms.

Avoid recurring communication traps

• Do not interpret a zero-filled block, timed-out read, or disconnected device as an all-clear condition.
• Do not poll static configuration and rapidly changing process data at the same rate. Give alarms and health the required priority.
• Do not allow both communication paths to write control data unless arbitration is explicit. A read-only backup for alarm visibility carries less risk.
• Do not declare a link healthy from session state alone. Require changing application data within the configured supervision interval.
• Do not hide the active path. Display whether data arrived through the wireless bridge or the backup path.
• Do not rely on the single C-more as the only means of detecting critical remote conditions when loss of the one-mile link removes operator visibility. Select an independent local or remote annunciation method when the process risk requires it.

FAQ