S7 Attribute Assignment for PCS7 APL Blocks and WinCC Tags

Engineers commissioning SIMATIC PCS 7 frequently encounter a frustrating limitation: S7 attributes (S7_m_c, S7_m_c_visible, S7_archive, S7_measuring_point, S7_unit, S7_shortcut) configured on the members of a shared (global) data block refuse to propagate to WinCC tag generation, while the same attributes on an instance DB of a function block work as expected. The root cause is a deliberate design choice in the STEP 7 V5.x / PCS 7 toolchain: only structured parameters of an FB (or the I/Os of an APL block, which is an FB) are candidates for the "Operator Control and Monitoring" attribute group that the OS-Project-Editor and WinCC Explorer scan. This article documents the constraints, the correct pattern using FB parameters, and the field-proven copy-block workaround when a shared DB cannot be replaced.

1. Problem Definition

Symptom observed in a typical commissioning session:

1. Engineer creates a shared DB (DB100, for example) containing a UDT-derived STRUCT with members such as PV, SP, OP, LMN.
2. Engineer opens the DB, selects the PV member, and assigns the S7 attribute S7_m_c = true (operator-controllable), S7_m_c_visible = true, and S7_archive = true.
3. STEP 7 accepts the assignment; the attributes are stored in the offline block container.
4. After compiling the OS (PCS 7: "Compile OS" in WinCC Explorer), the structure members do not appear as WinCC tags under the expected hierarchy, or appear without the operator-control properties.
5. Operator faceplates show the value as read-only or invisible; setpoint changes from HMI are rejected at runtime.

The same workflow applied to an instance DB of an FB (e.g., the APL block CTRL_PID / FB1869) produces the expected WinCC structure tag with faceplate wiring intact. This is the behavior the engineer expects, but it only holds because CTRL_PID is itself an FB whose I/Os carry the attributes.

2. Root Cause: Where S7 Attributes Are Read From

The STEP 7 / PCS 7 OS compilation pipeline does not parse every DB in the S7 program for S7 attributes. The relevant filter is:

The mechanism behind this is the S7_m_c family of attributes being tied to the block interface, not the data storage location. The OS Project Editor enumerates the block interface descriptions (BIBs) in the S7 program, looks for parameters marked with S7_m_c, and creates a WinCC tag per interface parameter. A shared DB has no block interface — it is pure data storage — so it is skipped.

3. The Correct Pattern: FB Parameter Attributes

The supported approach is to declare every tag the operator must see or modify as a parameter of an FB. The FB then becomes the "owner" of the data, and the attributes travel with the parameter declaration.

3.1 Declaration Snippet (STEP 7 V5.x STL/FBD editor)

In the FB source (e.g., FB100), declare an STRUCT parameter and apply attributes at the leaf level. The S7 attribute field is entered via the right-click menu "Object Properties > Attributes" or via the block interface dialog:

FUNCTION_BLOCK FB100
TITLE = 'Process Value Container'
VERSION : '1.0'

VAR_INPUT
    // Scalar example — direct attribute
    i_PV : REAL;          // S7_m_c = false, S7_m_c_visible = true, S7_measuring_point = 'PT1001'
    i_SP : REAL;          // S7_m_c = true, S7_shortcut = 'SP', S7_unit = 'bar'
END_VAR

VAR_OUTPUT
    o_LMN : REAL;         // S7_m_c = false, S7_archive = true, S7_quality_code = true
END_VAR

VAR_IN_OUT
    // Structured parameter — attributes propagate to leaves
    io_Loop : STRUCT
        PV   : REAL;      // S7_m_c = false, S7_measuring_point = 'PT1002'
        SP   : REAL;      // S7_m_c = true, S7_shortcut = 'SP', S7_unit = 'bar'
        MV   : REAL;      // S7_m_c = false, S7_archive = true
    END_STRUCT;
END_VAR

BEGIN
END_FUNCTION_BLOCK

When io_Loop is wired to a shared DB variable (e.g., DB200.io_Loop) and FB100 is called from OB35 with that shared DB passed in, the OS compiler will generate a WinCC tag named FB100/io_Loop.PV#Value with the S7_m_c, S7_shortcut, and S7_unit properties attached.

3.2 Attribute Inventory Used in PCS 7 APL

These are documented in the STEP 7 V5.6 online help under "S7-300/400 attribute definitions."

4. Why Shared DBs Reject Attributes

If you open a shared DB in the STEP 7 editor, right-click a member, and select Object Properties > Attributes, the S7 attribute table opens but the Apply button remains disabled or the values are not persisted across a save/compile cycle. Reasons:

• The DB editor stores attributes in the ATTR_DB section of the offline block, but the OS compiler filters on ATTR_FB (block interface attributes) only.
• The WinCC tag generation wizard uses the S7TK interface description exported by STEP 7. Shared DBs do not export a S7TK block interface entry.
• APL blocks generate their WinCC structures via the "APL Faceplate Designer" which reads the FB source statically at compile-OS time. Shared DBs are not in the call tree at that moment.

The Siemens support note "Why are S7 attributes on shared DBs ignored?" (Entry ID 109751091 in the Industry Online Support portal) confirms this behavior. The note states explicitly: S7-m_c attributes are designed for function block interfaces; shared data blocks are data containers only and do not generate OS-relevant tags.

5. UDT Limitations

A common mistake is to declare a UDT with attributes at the field level and instantiate it inside an FB. UDT field attributes are also not honored independently. The reason: the UDT body is a type definition; the OS compiler needs a parameter instance in the FB interface to anchor the WinCC tag.

What does work is:

TYPE UDT_LoopData
VERSION : '1.0'
  STRUCT
      PV   : REAL;
      SP   : REAL;
      MV   : REAL;
  END_STRUCT;
END_TYPE

FUNCTION_BLOCK FB100
VAR_IN_OUT
    io_Loop : UDT_LoopData;   // Attributes here drive OS tag generation
END_VAR

Attributes must be applied on io_Loop.PV, io_Loop.SP, io_Loop.MV as members of the FB parameter after the UDT is dropped into the FB declaration. Editing them inside the UDT body itself has no effect at OS compile time.

6. WinCC Tag Path Notation: PV#Value

When the OS compiles, it produces a tag whose access path follows the FB instance name and the structured parameter path, terminated by the convention #Value for the process value leaf. For example:

FC101/CTRL_PID_1.PV#Value
FC101/CTRL_PID_1.SP#Value
FC101/CTRL_PID_1.MV#Value
FC101/CTRL_PID_1.LMNR#Value

Where:

• FC101 — the WinCC picture or technical hierarchy node.
• CTRL_PID_1 — the instance name of the FB (FB1869 instance DB symbolic name).
• PV, SP, MV, LMNR — APL structured parameter names.
• #Value — leaf qualifier; other qualifiers include #ST (status), #Quality (quality byte), #Limit (limit flags).

7. Workaround Pattern: Copy DB Block

When the existing shared DB cannot be replaced — for example, because it is generated by a vendor package or referenced by FCs that must remain unchanged — the field-proven workaround is to introduce a Copy DB block that mirrors the structured data into a flat or differently-organized DB where attributes can be assigned.

7.1 Topology

The data flow is:

[Source shared DB with STRUCT, no attributes]
        |
        |  (read by)
        v
[FB Copy_Block — reads source, writes to target with attributes applied]
        |
        v
[Target shared DB with elementary tags, S7 attributes assigned]
        |
        v
[OS Compiler reads target, generates WinCC tags with attributes]

7.2 Implementation Skeleton

FUNCTION_BLOCK FB_CopyLoop
TITLE = 'Copy structured loop data to attribute-tagged shared DB'
VERSION : '1.0'

VAR_IN_OUT
    io_Source : STRUCT        // Wired to source shared DB STRUCT
        PV : REAL;
        SP : REAL;
        MV : REAL;
        Q  : BOOL;
    END_STRUCT;
END_VAR

VAR_OUTPUT
    // These outputs land in the target shared DB
    o_PV : REAL;              // S7_archive = true, S7_m_c_visible = true
    o_SP : REAL;              // S7_m_c = true, S7_shortcut = 'SP', S7_unit = 'bar'
    o_MV : REAL;              // S7_archive = true
    o_Q  : BOOL;              // S7_m_c_visible = true, S7_quality_code = true
END_VAR

BEGIN
    o_PV := io_Source.PV;
    o_SP := io_Source.SP;
    o_MV := io_Source.MV;
    o_Q  := io_Source.Q;
END_FUNCTION_BLOCK

Call this FB once per OB35 cycle with:

CALL FB_CopyLoop , DB_CopyLoop_1
   io_Source := "SrcDB".Loop[1]
   o_PV := "TgtDB".PV_1
   o_SP := "TgtDB".SP_1
   o_MV := "TgtDB".MV_1
   o_Q  := "TgtDB".Q_1

The target shared DB now contains elementary tags. Assign the S7 attributes on PV_1, SP_1, MV_1, Q_1 individually. Because the target DB is referenced by the FB interface (the output side), the OS compiler will scan the FB's output declaration and emit WinCC tags FB_CopyLoop/o_PV#Value etc., which can be wired to faceplates.

7.3 Caveats of the Copy Pattern

• Stale data window: A one-cycle delay is introduced between source update and target update. For OB35 at 1 s this is usually acceptable; for sub-second loops, consider an OB that matches the source update rate.
• Quality loss: If the source Q byte carries an S7 quality code, copy it explicitly — do not assume the target BOOL captures all states. Use BYTE for quality.
• Write-back: If operators change setpoints via the faceplate, the writes land in the target DB, not the source. The copy FB must be bidirectional, or an additional "write-back" FB must move o_SP from the target back into io_Source.SP each cycle.
• Maintenance burden: Every new tag added to the source STRUCT requires a corresponding output and copy line in the FB. Document this in the block header to prevent drift.

8. Verification Procedure

After applying the FB-parameter pattern or the copy-block workaround, verify end-to-end:

1. STEP 7 compile: Menu PLC > Compile and Download Objects. Confirm no warnings related to attribute inconsistency.
2. OS compile: In WinCC Explorer, right-click the OS project and select Compile OS. The output log must contain entries such as Generating tag: FB100/Loop_1.PV#Value (archive=Yes, m_c=No) for every parameter that should be visible.
3. Tag inspection: Open the WinCC Explorer tag management, navigate to the relevant structure tag, and confirm properties: Archive, Operator-Control, Unit, Shortcut are populated.
4. Faceplate wiring: Open the faceplate in graphics designer. Right-click a value display, choose Properties > Output/Input > Tag, and verify the tag name matches the PV#Value convention.
5. Runtime test: Activate Runtime, change a setpoint from the faceplate, and confirm the new value appears in the source DB via online monitor in STEP 7 (Ctrl+F7). Quality byte should be 0x80 (good) throughout.
6. Archive check: In the WinCC Runtime archive control, confirm the tag is being logged at the configured archive rate.

9. Troubleshooting Matrix

10. Migration to TIA Portal / Open Architecture

If the project is being migrated to TIA Portal (STEP 7 V17 / WinCC Unified), the attribute concept is replaced by:

• PLC tag database properties (acquisition type, archiving, scaling, limits).
• HMI tag configuration with direct connection to DB members.
• Faceplate model in WinCC Unified using custom web controls — no PV#Value convention.

The Instance-DB-only restriction of PCS 7 V8.x does not apply in TIA Portal; any DB tag can carry HMI attributes through the PLC tag database. However, projects migrated from PCS 7 still benefit from the FB-parameter pattern because it preserves the faceplate wiring conventions that operators are accustomed to.

11. Summary of Rules

1. Assign S7 attributes on FB parameter declarations, never on shared DB members.
2. UDTs inherit attributes only through their instantiation as FB parameters.
3. WinCC tag paths follow <InstanceName>.<StructParam>#Value; the #Value suffix is mandatory for the leaf.
4. Use a copy FB if the shared DB cannot be replaced; be aware of the one-cycle delay and write-back requirement.
5. Verify with the OS compile log: every parameter with S7_m_c = true must produce a corresponding tag with Operator-Control = Yes.
6. Confirm runtime behavior by writing a setpoint from the faceplate and observing the value online in the source DB.