Monitoring S7 Connection Failure and Recovery with the PCS 7 CONEC Driver Block

In SIMATIC PCS 7, the system driver block CONEC (FB94) automatically monitors S7 communication links between automation stations and operator systems, generating standard Alarm_8P messages upon connection loss and connection recovery. While CONEC does not provide a dedicated discrete digital output specifically titled "Recovery", the block continuously reports operational status through its QERR output (which transitions to 0 upon communication recovery) and its internal STATUS word. Engineers requiring a positive logic recovery trigger in CFC can easily construct one by evaluating the falling edge of QERR using an inverted edge detection block (F_TRIG or R_TRIG with inverted input) or querying the connection bitmask.

Role and Automatic Generation of the CONEC Driver Block

In a distributed SIMATIC PCS 7 architecture, reliable process control requires immediate detection if an S7 communication connection between an S7-400 controller and an OS Server, Engineering Station, or peer controller fails.

To achieve this, the CFC compiler's Generate module drivers function automatically places the connection monitoring driver block CONEC (FB94) into the system @ charts (typically @(1) or @(2)).

CONEC cyclically queries the internal communication status of all configured S7 connections using system functions (such as reading the System Status List via RDSYSST / SSL index 16#0232). When an S7 connection drops, CONEC triggers an alarm; when communication is re-established, it reports the clearance of the alarm.

Block Interface and Diagnostic Status Parameters

The CONEC block interface provides detailed diagnostic outputs representing connection health:

Parameter NameData TypeDirectionFunctional DescriptionQERRBOOLOutputSummary error: 1 = At least one monitored S7 connection is faulted; 0 = All connections healthySTATUSDWORDOutputDetailed status word reporting internal SSL query states and diagnostic flagsCON_ESTDWORDOutputBitmask of established S7 connectionsCON_FAILDWORDOutputBitmask of failed S7 connections (each bit corresponds to a connection ID)MSG_EVIDDWORDInputMessage Event ID assigned for Alarm_8P message routing

When an S7 connection is lost, CONEC asserts QERR = 1 and sets the corresponding bit in CON_FAIL. When the physical cable is reconnected or the remote partner recovers, CON_FAIL clears the bit and QERR returns to 0.

Alarm_8P Messaging for Connection Loss and Recovery

In standard industrial alarm management, communication failures generate state transitions:
1. Connection Loss: CONEC calls Alarm_8P with the error bit asserted. WinCC logs an Incoming (+) Alarm indicating 'S7 connection failure to station X'.
2. Connection Recovery: When the link is re-established, CONEC updates the Alarm_8P block with the error bit cleared. WinCC logs an Outgoing (-) Message signifying that the fault condition has resolved.

Because WinCC alarm systems track both incoming (+, active) and outgoing (-, cleared) events, operators can review the exact timestamp of connection restoration in the WinCC Alarm Journal without needing custom logic.

Constructing Connection Recovery Signals in CFC

If plant automation logic requires an explicit positive pulse or latch in CFC when communication recovers (for example, to trigger an automatic recipe re-synchronization or clear a trip bypass):

Evaluate Falling Edge of QERR:
- In CFC, place an edge detection block (F_TRIG from the standard library).
- Interconnect CONEC.QERR to the input CLK of F_TRIG.
- The output Q of F_TRIG generates a single-cycle boolean pulse (1) at the exact instant the connection recovers.
Alternative: R_TRIG with Inverted Signal:
- Connect CONEC.QERR through an inverter (NOT) to the input of an R_TRIG block.
- The rising edge of the healthy state triggers the recovery pulse.
Channel-Specific Recovery via Bitmask:
- If monitoring a specific S7 connection among multiple links, evaluate the corresponding bit in CON_FAIL using bitwise logic blocks (WAND_DW / SHR_DW).

Verification

To verify connection monitoring and recovery signal generation:
1. Open the system @ chart containing CONEC in CFC and switch to online test mode.
2. Verify that under normal operating conditions, QERR = 0 and CON_FAIL = 16#00000000.
3. Disconnect the Plant Bus Ethernet cable from the target OS Server.
4. Verify that within seconds, CONEC.QERR switches to 1, a bit sets in CON_FAIL, and an alarm appears in WinCC.
5. Reconnect the cable; verify that CONEC.QERR transitions back to 0 and that the F_TRIG recovery pulse asserts for one execution cycle.

Limitations and Operational Precautions

Do not manually edit or rename blocks inside the system @ charts. When CFC is compiled with 'Generate module drivers', the compiler regenerates and updates @ charts, overwriting manual additions. If you require interconnections to CONEC.QERR, place your custom logic in a dedicated user chart (e.g., Diagnose_Logic.CFC) and create an interconnection from the user chart to the CONEC block in the @ chart.

Engineer FAQ

Why is there no dedicated 'Recovery' output pin on CONEC?

Because digital automation logic represents recovery through the de-assertion of the fault signal (QERR = 0). A separate recovery pin is redundant in standard state machines.

Can I connect my own logic to blocks in the @ charts?

Yes, you can read outputs from blocks in @ charts. However, do not place custom blocks directly inside @ charts, as future module driver compilations may delete them.

Does CONEC monitor connections to third-party Modbus TCP devices?

CONEC is specifically designed for S7 connections configured in NetPro (between S7 CPUs, CPs, and WinCC applications). Modbus TCP links typically use dedicated application driver blocks (e.g., MB_REDCL).