CEMAT Cascaded Interlocks on OS Clients: Resolving Missing C_INTER5 and C_INTERL Faceplates and Server Data Synchronization

In SIMATIC PCS 7 CEMAT, when cascading multiple interlock blocks (C_INTER5 or C_INTERL) to a single technological interface (such as EBVG on C_DRV_1D), all cascaded blocks appear on the OS Server faceplate but OS Clients may display only one block. This issue occurs when OS Clients lack the updated server data package containing the cascaded block tag definitions, or when client-local CEMAT standard pictures (@PG_C_INTER5.PDL / @PG_C_INTERL.PDL) and custom scripts are out of sync with the server. To resolve it, regenerate server data on the OS Server, download the OS Client project, and verify CEMAT client installation files.

CEMAT Interlock Cascading Architecture (C_INTER5 and C_INTERL)

In the SIMATIC PCS 7 CEMAT minerals library, technological drive modules such as C_DRV_1D and C_DRV_2D evaluate operational and protection interlocks through dedicated inputs: EBVG (operational interlock in run direction 1), EVEG (operational interlock in start direction 1), ESVG (protection interlock direction 1), and ESVG2 (direction 2).

Because a standard drive may require more than five interlock conditions, CEMAT provides cascading interlock blocks (C_INTER5 or C_INTERL). Up to three interlock blocks can be cascaded to a single drive interface. In the drive operator faceplate, clicking the interlock interface button opens the corresponding interlock faceplate, which should dynamically display all chained interlock sub-windows.

Root Causes for Missing Interlock Boxes on OS Clients

When interlocks appear correctly on the OS Server runtime but only the first box opens on OS Clients, the cause is typically found in one of three areas:

Stale OS Client Server Data: OS Clients do not communicate directly with the S7-400 controller; they resolve tag variables through the OS Server's server data package (<Project>.pdk). If the CFC charts were compiled and downloaded to the AS and OS Server, but the server data package was not re-loaded or updated on the OS Client, the client fails to resolve tags for the second and third cascaded blocks.
Missing or Desynchronized Client CEMAT PDL Files: CEMAT relies on standard faceplate picture templates (@PG_C_INTER5.PDL, @PG_C_INTERL.PDL, @PG_C_DRV_1D.PDL). If the OS Client has an older or unpatched copy of these PDLs in its local GraCS directory, the dynamic faceplate script fails during multi-window instantiation.
Inconsistent Block Naming Rules: CEMAT faceplate scripts construct subordinate picture names and tag prefixes based on rigid hierarchical naming conventions. If block instances deviate from the expected suffix rules, the script terminates after loading the primary block.

Naming Conventions and Tag Prefix Generation for Cascaded Blocks

To ensure that CEMAT faceplate scripts correctly enumerate cascaded blocks, adhere to the standard naming syntax:

If the drive block is named M01 and connects to interface EBVG:
First interlock block: M01_EBVG1
Second interlock block: M01_EBVG2
Third interlock block: M01_EBVG3

If the second block is named arbitrarily (e.g., M01_EBVG_B or C_INTER5_2), the CEMAT faceplate script cannot iterate the index i = 1 to 3 to instantiate the secondary popups.

Server Data Generation and Multi-Client Synchronization Lifecycle

The multi-client runtime engine queries the server data package to identify whether secondary blocks reside on the active server:

When the OS Client executes @PG_C_DRV_1D.PDL, clicking the interlock button launches a C-script (CematOpenFaceplate or internal DLL function).
The script checks the existence of tags: <DriveTag>_EBVG2.STATUS.
If this tag is missing from the client's internal tag dictionary (because the .pdk has not been loaded), the script silently aborts the creation of the second box to prevent runtime script exceptions.
Consequently, only M01_EBVG1 renders, giving the false impression that OS Clients have an inherent block limitation.

Cascaded Interlock Block Specification & OS Client Rendering Matrix

The following table summarizes cascading rules and synchronization requirements across CEMAT modules:

Block TypeMax Cascaded UnitsInterface Naming StandardScript File DependencyClient Synchronization PrerequisiteC_INTER53 Blocks (15 signals)<Drive>_<Interface>1..3@PG_C_INTER5.PDLUpdated Server Data + Cemat.ini on ClientC_INTERL3 Blocks (15 signals)<Drive>_<Interface>1..3@PG_C_INTERL.PDLUpdated Server Data + Cemat.ini on ClientC_DRV_1DN/A (Master Module)EBVG, EVEG, ESVG@PG_C_DRV_1D.PDLComplete OS Client DownloadC_DRV_2DN/A (Master Module)EBVG1/2, EVEG1/2, ESVG1/2@PG_C_DRV_2D.PDLComplete OS Client DownloadC_DAMPER3 Blocks per limit<Damper>_KBVG1..3@PG_C_DAMPER.PDLUpdated Server Data on Client Station

Diagnostic and Remediation Workflow for OS Client CEMAT Faceplates

Execute the following steps to resolve missing cascaded faceplates on OS Clients:

Audit CFC Naming: Open CFC charts in SIMATIC Manager. Confirm that all cascaded C_INTER5 or C_INTERL blocks strictly follow the <Drive>_<Interface><1..3> naming convention.
Compile OS Server: Right-click the OS Server object and perform a complete compilation with memory generation.
Update Server Data: In WinCC Explorer on the OS Server, right-click Server Data and select Create.
Update OS Client Project: In SIMATIC Manager, right-click the OS Client object and select Compile OS (or right-click Server Data -> Update in WinCC Explorer).
Synchronize CEMAT Client Files: Ensure that the CEMAT client installation files (from the CEMAT DVD CEMAT_CS\WinCC\GraCS and ScriptLib) were copied to the OS Client project directory. Specifically verify @PG_C_INTER5.PDL and Cemat.ini.
Download OS Client: Execute an OS Download to target station. If running, stop WinCC Runtime on the client prior to download.
Restart Runtime: Start WinCC Runtime on the OS Client and verify multi-box display.

Verification

Confirm resolution through these verification checks:

Tag Management Audit on Client: Open WinCC Explorer on the OS Client, expand the loaded server package, and search for <Drive>_EBVG2 and <Drive>_EBVG3. Ensure all tags exist.
Faceplate Click Test: Open the C_DRV_1D faceplate in WinCC Runtime on the OS Client. Click the EBVG button. Verify that all 3 C_INTER5 boxes open cascaded side-by-side or stacked as designed.
Bypass and Force Indication: Force an interlock input on the third cascaded block in CFC test mode. Verify that the bypass/active interlock indicator updates dynamically on the OS Client screen.
WinCC Diagnostics Log: Open C:\Program Files (x86)\Siemens\WinCC\Diagnostics\WinCC_Sys_01.log on the OS Client. Ensure no Picture not found or Tag does not exist errors are thrown upon clicking the faceplate.

Limitations and Operational Precautions

Keep the following operational considerations in mind:

Maximum Cascading Limit: CEMAT faceplates support a hard maximum of 3 cascaded blocks per interface (yielding 15 interlock signals). Attempting to cascade a 4th block (_EBVG4) will not be rendered by standard CEMAT faceplates and requires custom script modification.
Client-Server File Overwrite: During project upgrades or OS migrations, do not overwrite CEMAT standard faceplates with default PCS 7 APL faceplates.
Commercial Accuracy Disclaimer: Software order numbers (MLFBs), package structures, and hardware capacity prerequisites vary across PCS 7 versions and hardware platforms. System integrators must confirm exact software entitlements and licensing requirements against the official Siemens Catalog CA 01 and obtain an authorized Siemens distributor quotation prior to purchasing.

Engineer FAQ

Can I mix C_INTER5 and C_INTERL blocks on the same drive interface?

No. Mixing C_INTER5 and C_INTERL blocks on the same interface causes script parsing errors in the faceplate handler. Standardize on either C_INTER5 (classic CEMAT) or C_INTERL (APL-style interlock) across the entire drive module.

Why do interlock texts appear empty on OS Clients even when boxes open?

Empty text labels indicate that the CEMAT language file (Cemat.ini or text library) was not copied to the client, or the current WinCC Runtime language does not match the language in which interlock descriptions were compiled.

Do cascaded interlocks increase AS RT Process Object count?

Interlock blocks like C_INTER5 typically do not consume additional AS RT Process Object licenses unless they generate autonomous WinCC message instances.