Resolving STEP 7 "Compiler Information: Type Conflict" Errors in Siemens S7-300 FC Blocks

1. Problem Description

Engineers uploading an S7-300 (or S7-400) project from a running PLC and then attempting to edit a Function (FC) block in SIMATIC STEP 7 V5.x frequently encounter the compiler message:

Compiler Information: type conflict

The error is triggered when an input parameter IN, IN_OUT, or OUT declared on the FC's interface has a complex data type (POINTER, ANY, DATE_AND_TIME, TIME, S5TIME, STRING, or a UDT) and the calling network supplies a value or address whose format does not match the formal parameter type. A second, more specific error variant appears when the engineer tries to force a POINTER-style address into a non-pointer formal:

The constant format for data type BYTE does not fit the formal type DATE_AND_TIME of the formal parameter IN0

Symptoms observed in the field:

• Save / compile fails immediately after a small edit (e.g. adding an extra memory bit to a network).
• The same FC opens and compiles cleanly on the engineering station that originally wrote the project.
• Re-download to the PLC fails with SF LED on the CPU and Online > Accessible Nodes showing a generic type mismatch.
• The error only references the FC interface header, not the network body.

2. Affected Platforms and Software Versions

The error is platform-agnostic in STEP 7 but occurs most frequently in the following configurations:

The same error class also surfaces in TIA Portal V13 SP1 through V17 when a project originally written in STEP 7 V5.x is migrated and an FC interface is referenced without re-typing the formal parameters. The fix procedure is identical once the interface declaration is corrected.

3. Root Cause Analysis

STEP 7 enforces strict data-type matching between:

1. The formal parameter declaration on the FC interface (the "Variable Table" tab inside the FC properties).
2. The actual operand wired to that parameter in the calling network (the LAD/FBD/STL source).

When a project is uploaded from the PLC to the engineering station, only the compiled block is transferred. The original symbolic information (UDT definitions, DB structure overlays, comments, and IEC timer/coil type metadata) is preserved on the CPU but is not always re-bound correctly to the offline source. The compiler therefore sees the FC interface as a set of untyped IN/OUT/IN_OUT parameters of generic 32-bit width, while the calling network was written with operands of specific elementary types.

The mismatch is exposed as soon as the engineer touches the FC body and triggers a recompile. Typical exposed mismatches:

• IN0 : DATE_AND_TIME in the FC, but the network wires a BYTE constant.
• IN1 : POINTER in the FC, but the network wires P#DB5.DBX0.0 BYTE 8 without the matching ANY/POINTER syntax.
• IN2 : UDT1 in the FC, but the calling DB has been regenerated and the symbolic name (STAT0, STAT2, …) no longer resolves.

In the case described in the field, FC5 was being edited to add a memory-bit logic continuation (M42.0 → M42.1 with timer T2). FC12 was also involved: its formal parameters IN0 and IN1/IN2 had been originally declared as DATE_AND_TIME and TIME respectively. After the upload the type mapping was lost, and the constant P#DB5.DBX0.0 BYTE 8 (a 6-byte pointer constant the engineer was attempting to assign) collided with the 8-byte DATE_AND_TIME formal type.

4. Diagnostic Procedure

Follow this ordered checklist to isolate the failing formal parameter:

1. Open the affected FC in LAD/FBD/STL Editor.
2. Switch to the Interface tab and note the Type column for every IN, OUT, and IN_OUT declared. Screenshot this table for comparison with the calling network.
3. From the Options > Block Check menu, run Consistency Check. Record every warning that references Type conflict or Formal parameter.
4. Open the calling OB or FB that uses the FC (e.g. OB1). Locate each call site and right-click → Go To > Called Block. Cross-reference the actual operand against the formal type.
5. If the project was uploaded from the PLC, open Online > Compare Blocks > Offline/Online. A mismatch in the interface type column between offline and online confirms the upload has flattened the type metadata.
6. For NC applications on SINUMERIK, additionally inspect Tools > NCK Configuration and verify that the user-defined DB referenced (e.g. DB5) still exists in the S7 offline project. If it does not, restore it from the latest backup before proceeding.

Once the offending (formal type, actual operand) pair is known, proceed to Section 5 or Section 6 depending on whether the FC inputs are POINTER/ANY parameters or elementary/UDT parameters.

5. Solution Method A — Pointer Syntax for POINTER / ANY Parameters

When the formal parameter is declared as POINTER or ANY, the only syntactically accepted actual operand is a pointer constant of the form:

P#<area><byte_address>.<bit_address> <data_type> <length>

The area mnemonics are I, Q, M, DB, PI, PQ, and L. For a DB, omit the bit address (always .0) and always include the BYTE length qualifier:

P#DB5.DBX0.0 BYTE 8  ← 8-byte pointer into DB5 starting at byte 0
P#DB5.DBX16.0 BYTE 8 ← 8-byte pointer into DB5 starting at byte 16

The length must equal (or not exceed) the receiving parameter's logical size. For a DATE_AND_TIME receiving area, the length is exactly 8 bytes; for TIME, 4 bytes; for a UDT, the byte length of the UDT (visible in DB Editor > Properties > Length).

Procedure:

1. Open the calling network and click on the FC box input that produces the error.
2. Replace the existing address with the full pointer constant. Example for IN0 of FC12 (declared DATE_AND_TIME):

   CALL  FC12
     IN0 := P#DB5.DBX0.0 BYTE 8
     IN1 := P#DB5.DBX16.0 BYTE 8
     RET_VAL := MW100

3. Save and compile. The "type conflict" should clear.

6. Solution Method B — Symbolic DB Access via UDT

If the FC's formal parameters are elementary types (TIME, DATE_AND_TIME, INT, BOOL, REAL, …) or UDTs, the cleanest fix is to wire symbolic names from a DB whose structure (a UDT) already matches the expected type. This avoids any pointer length arithmetic and is the recommended pattern for SINUMERIK NC projects where DB5 / DB6 / DB10 are typically UDT-typed interface blocks.

Procedure:

1. In SIMATIC Manager, right-click Blocks > Insert New Object > Data Block, name it DB5, and set the Type to your UDT (e.g. UDT1). Confirm the symbolic length shown matches the FC's expected data size.
2. Open DB5 and assign meaningful symbolic names to each field, for example:

   DATA_BLOCK  DB5
   TITLE  = 'NC Interface Block'
   VERSION : 2.0
     STRUCT
       STAT0 : TIME ;       // IN1 to FC12
       STAT1 : TIME ;       // spare
       STAT2 : DATE_AND_TIME; // IN0 to FC12
       STAT3 : WORD ;       // spare
     END_STRUCT;
   END_DATA_BLOCK

3. Now wire the FC call symbolically. Use absolute symbolic names that the compiler can resolve from the DB's STRUCT definition:

   CALL  FC12
     IN0 := DB5.STAT2       // DATE_AND_TIME — 8 bytes
     IN1 := DB5.STAT0       // TIME          — 4 bytes
     IN2 := DB5.STAT3       // WORD          — 2 bytes
     RET_VAL := MW100

4. Compile. The compiler reads the type of each STATn directly from DB5's STRUCT, so any subsequent DB regeneration preserves the type binding.

This is the preferred method when the original project is lost or only available as an upload, because it removes any dependence on the original symbolic information that the upload did not retain.

7. Verification

After applying either Solution A or Solution B, run the following verification sequence before downloading to the live PLC:

1. Compile Offline: Program > Compile All. The status bar must show 0 errors, 0 warnings.
2. Consistency Check: Options > Block Check > Consistency Check. Resolve every warning, especially any Address is not assigned to symbolic name notice.
3. Cross-Reference: Options > Reference Data > Display. Confirm that every FC12 call site has matching formal/actual types.
4. Download to CPU in STOP: Stop the CPU, download the corrected FC and DB blocks, then perform a CPU restart. Watch the SF and BF LEDs — both must remain off.
5. Online Monitoring: Switch the FC to Monitor (On/Off) view and step through the previously failing network. The status indicators must match the offline simulation.

8. Data Type Reference for FC Inputs

Use the following table when sizing pointer operands or assigning UDT fields to FC inputs:

9. SINUMERIK NC Configuration Context

In SINUMERIK 840D sl systems, the PLC portion of the project uses FC5 (and others) for NCK-PLC signal exchange. Memory bits M42.0 and M42.1 are commonly used as handshake / enable flags between the NCK and the PLC. Timer T2 often implements a watch-dog for the NCK-PLC handshake, resetting the NCK ready signal after a configurable interval. Editing FC5 in this environment is sensitive because:

• The same FC is also referenced by the HMI's compile chain (HMI Pro / Run MyHMI / Operate).
• Changes to FC5 affect the machine's safety-relevant PLC logic; an undetected type conflict can leave the axis enable logic in an inconsistent state.
• The PLC program is often compiled together with the NCK configuration, requiring a coordinated download on both sides.

For NC-specific uploads, Siemens recommends always retaining the original project archive (created by the machine builder with Commissioning > Create Series Commissioning Archive) before applying edits. If the original archive is not available, regenerate the UDT-driven DBs from the SINUMERIK toolbox (Tools > NCK Toolbox > Generate PLC Interface).

10. Compiler Error Catalog for FC Interface Mismatches

11. Best Practices for FC Interface Design

1. Use UDTs for structured I/O. Any FC that exchanges more than two related parameters benefits from a UDT wrapper. The compiler then performs block-level type checks instead of per-field checks.
2. Prefer symbolic wiring over pointer constants. Symbolic wiring makes code self-documenting and survives DB regeneration. Use pointer constants only when interfacing to legacy STL blocks that lack UDT support.
3. Document every FC input/output with IEC-style comments. The comment becomes the "header documentation" once the FC is inserted into a library.
4. Set the FC's Know-How-Protection flag only after the interface is finalised. Re-typing a protected FC requires re-entry of the password.
5. Maintain a separate interface header source. For libraries used across multiple projects, store the FC source as plain AWL/STL in a version-controlled repository so changes are auditable.
6. Never modify the FC interface and the calling network in the same offline save without intermediate compile. Splitting the change reduces the diagnostic surface area when a type conflict arises.
7. Always archive the online project before any offline edit. Use PLC > Upload Station to PG + File > Archive.

12. Troubleshooting Matrix

13. Frequently Asked Questions