Sharing FB/FC Across S7-1200 PLCs Using TIA Portal V16 Library

Sharing FB/FC Across S7-1200 PLCs Using TIA Portal V16 Library

When a fleet of identical SIMATIC S7-1200 stations runs the same user program on the same hardware, every code change normally forces an engineer to open every project, edit every block, and re-download every controller. The TIA Portal library system breaks that loop, but only when blocks are placed in the correct library container (the Types folder) and managed with the right workflow. This guide walks through the procedure that lets a single FB or FC edit propagate to every PLC without copy/paste, drag-and-drop, or hand-tracking of revisions, using TIA Portal V16 as the reference platform and the SIMATIC S7-1200 programmable controller as the target hardware.

1. Problem Definition: Shared Code Across Multiple S7-1200 Stations

Consider a typical machine-builder scenario: three, ten, or thirty S7-1200 CPUs (CPU 1214C DC/DC/DC, for example) sit on the same PROFINET subnet, each controlling a section of a larger line. All CPUs carry identical hardware configuration and an identical user program. The only differences between stations are the PROFINET device names and IP addresses of the distributed I/O that physically hangs off each CPU. A handful of FB/FC blocks carry every line-wide logic (recipe engine, alarm handling, axis sequencing, HMI handshake).

The expected behavior of any modern library system is "edit once, consume everywhere": change the body of FB100 in the central library, recompile every consumer project, and the change ripples out. TIA Portal V16 supports this pattern but splits it across three containers (Project library, Global library, and Types / Master Copies sub-folders), each with different editability rules. Misplacing a block silently kills the workflow, which is the single most common complaint when first migrating from STEP 7 Classic to TIA Portal.

2. TIA Portal Library Architecture: Project vs Global Library

TIA Portal exposes two top-level library scopes. Understanding the difference is mandatory before choosing where to store shared blocks.

Use a project library when the shared code is genuinely project-specific (e.g., a recipe engine that only this fleet needs). Use a global library when the same code base must be referenced from multiple independent TIA Portal projects (e.g., a corporate FB for motor control that every machine-builder project consumes). The .al16 extension is bound to TIA Portal V16; upgrading to V17 requires a one-time conversion via "Libraries > Upgrade library version".

3. Types Folder vs Master Copies Folder: Editability Rules

Both library scopes contain two sub-folders that are easy to confuse. Their behavior is, however, sharply different.

The behavioral difference is the key to the whole workflow: a Type is a single source of truth that the project references by version, while a Master Copy is a one-shot template that diverges the moment it is dropped into a consumer project. Once a Master Copy is dropped, it owns its own revision history and cannot be auto-updated from the library.

4. Step-by-Step: Adding an FB or FC to the Types Section of a Project Library

The procedure below places an FB into the project library so that changes to its body propagate to every device in the project. TIA Portal V16 is assumed; the same workflow applies to V17 and V18 with only menu-string differences.

1. Open the TIA Portal project that contains the working PLC.
2. In the project tree, expand the target PLC and navigate to Program blocks.
3. Select the FB or FC that must become shared. Right-click and choose Copy.
4. Open the Libraries task card on the right side of the TIA Portal window.
5. Expand the Project library node, then the Types sub-folder.
6. Right-click inside Types and choose Paste. TIA Portal creates a Type version (e.g., V1.0.0) from the pasted block.
7. Drag the Type from the library onto the Program blocks folder of the same PLC (this is the first "use" that registers the type with the project).
8. Repeat the drag operation for every additional PLC that must consume the type.

After step 8, every PLC's Program blocks folder contains a block whose type reference points back to the single project-library Type. Editing the Type later is picked up by every consumer on the next compile. The block icon in the consumer project carries a small overlay badge that marks it as type-managed, making the relationship visible at a glance.

4.1 Promoting a Project Type to the Global Library

Once a Type is stable in the project library, expose it as a corporate standard via the global library:

1. Right-click the Type inside the project library's Types folder.
2. Choose Update types > Library.
3. Select the target global library (.al16 file) and confirm.
4. The Type is now visible inside that global library and can be referenced by any project that opens it.

5. Editing a Type and Propagating the Change to Multiple PLCs

The day-to-day maintenance loop is the part that saves the most time. Follow the sequence below every time the shared FB or FC needs to change.

1. Open the Libraries task card and expand Project library > Types.
2. Double-click the FB or FC to open it. The block opens in the editor as an editable copy (it is no longer greyed-out).
3. Edit the code, save with Ctrl+S. TIA Portal commits the change back to the Type and prompts to increment the version.
4. Open the Program blocks folder of any PLC that uses the Type. TIA Portal shows an "Update required" icon next to the block instance.
5. Right-click the instance and choose Update > Type version. Select the new version and confirm.
6. Repeat step 5 for every PLC that consumes the Type.
7. Compile (Ctrl+B) and download to each station.

6. Advanced Technique: Shared Cyclic OBs (OB1, OB123, OB200, ...)

TIA Portal allows multiple Program cycle OBs to exist in the same S7-1200 project. The default is OB1, but the S7-1200 firmware also executes any OB whose number is >= 123 and that has been configured as a Program cycle OB. This is the cleanest way to ship an entire "library PLC behavior" as a single drag-and-drop unit:

• OB123 (or any free number above 122) is created as a Program cycle OB and contains all of the shared, library-managed logic.
• OB1 stays empty (or contains only project-specific glue code) and is the one OB that every project always owns.
• The shared OB, together with the FBs and DBs it calls, is dropped from the library into the consumer project's Program blocks folder as a single operation.

This pattern avoids the friction of trying to ship a "shared OB1": a real OB1 must always remain project-local because the project tree entry "Program blocks > OB1" cannot be deleted from the consumer project. An extra OB sidesteps that limitation and survives a copy/paste into a sibling station without conflict.

6.1 Concrete OB123+ Snippet (Structured Text)

The block below is a realistic minimal pattern: OB123 calls a type-managed FB that owns all shared line logic. The same OB123, FB and its instance DB are shipped as a single library Type and consumed by every station.

// OB123 - Shared Library Cycle
// Configured as Program cycle, priority 1 (same as OB1)
CALL "FB_LineShared" , "DB_LineShared"
  iStationID    := "Station".iStationID      // WORD, project-local tag
  iHeartbeat    := "Clock_1Hz"                // BOOL from system clock
  bRun          := "HMI".bLineStart           // BOOL from HMI handshake
  bReset        := "HMI".bLineReset
  bAlarmActive  => "HMI".bLineAlarm          // BOOL to HMI
  iAlarmCode    => "HMI".iLineAlarmCode      // WORD to HMI
END_CALL

When the Type is updated, OB123 itself does not need to change - only the FB body does. The interface signature of FB_LineShared is versioned, so adding or removing parameters is handled cleanly by the "Update type" dialog.

7. Dummy Project Workflow for Global Library Master Copies

Master Copies cannot be edited in place. To update a Master Copy that lives in the global library, route the edit through a throwaway project. This is the only supported way to revise Master Copy content without losing the original template structure.

1. Create a new empty TIA Portal project (the "dummy") and add any S7-1200 CPU.
2. Drag the Master Copy from the global library into the dummy's Program blocks folder. The drop unmasks the blocks as editable.
3. Edit the blocks in the dummy. Save and compile.
4. Drag the edited blocks back into the global library's Master Copies folder (overwrite when prompted).
5. Close the dummy without saving the project.

8. Commissioning Workflow for 3 to 30 Identical S7-1200 Stations

For a fleet that has not yet been wired to the engineering station, the practical workflow during commissioning is structured as below. A consistent device-naming convention is critical because every station's PROFINET device name and IP must differ from every other station on the subnet.

For fleets above 10 stations, build a small TIA Portal Openness API script (C# or Python) that automates steps 5 and 6. The script can also drive the S7-1200's Web server or the HMI's "Station selector" tag to verify that the download reached the correct hardware. A 30-station fleet that previously took a full engineer-week to update with copy/paste reduces to a 30-minute unattended run.

8.1 Device-Naming and IP-Allocation Convention

Use a deterministic naming scheme so that an automated script can rename a project for each station without manual edits:

// Naming pattern
PROFINET device name : plc-<line>-st<NN>       (e.g., plc-line01-st07)
CPU IP address       : 192.168.<line>.<11+NN>   (e.g., 192.168.1.18)
HMI station number   : <NN>                       (HMI tag, used in OB1)
Subnet mask          : 255.255.255.0
Gateway              : 192.168.<line>.1
PROFINET device IPs  : 192.168.<line>.<100+NN>   (ET200SP, drives, etc.)

Keep the offset (11) high enough to leave the low range for the engineering station and any handheld commissioning tools. Avoid using .1 and .2 for PLCs - those addresses are typically claimed by routers and the engineering PG.

9. Verification Checklist After Library Updates

Run the following checks before signing off a library-driven code change. Each row maps a symptom to a verification action.

10. Type Versioning, Interface Changes, and Openness Automation

TIA Portal uses a three-segment semantic version for library Types: Major.Minor.Patch. The segments map to specific change classes:

10.1 Openness API Sample (C#)

For fleets above ~10 stations, the manual "Update type" loop becomes the bottleneck. The TIA Portal Openness API exposes the same operation as a single call. The snippet below (compiled against Siemens.Engineering.dll shipped with TIA V16) opens a project, performs the Type update, and saves.

// TIA Portal Openness - bulk type update
using Siemens.Engineering;
using Siemens.Engineering.Library;

public static int UpdateTypeInProject(string ap16Path, string typeName, Version newVersion)
{
    using (var tia = new TiaPortal(TiaPortalMode.WithUserInterface))
    {
        var project = tia.Projects.Open(new FileInfo(ap16Path));
        int updated = 0;

        foreach (var device in project.Devices)
        {
            var software = device.Items.OfType<SoftwareContainer>().FirstOrDefault();
            if (software == null) continue;

            var blocks = software.Software.Blocks;
            foreach (var block in blocks)
            {
                if (block.Type == null) continue;
                if (!string.Equals(block.Type.Name, typeName,
                                   StringComparison.OrdinalIgnoreCase)) continue;

                var latest = block.Type.Versions
                                  .OrderByDescending(v => v.VersionNumber)
                                  .FirstOrDefault(v => v.VersionNumber <= newVersion);
                if (latest != null && latest.VersionNumber != block.Type.Version)
                {
                    block.Type.UpdateType(latest);
                    updated++;
                }
            }
        }

        project.Save();
        project.Close();
        return updated;
    }
}

11. Common Pitfalls and Field-Proven Caveats

The list below captures the failure modes that surface most often in production deployments, ordered by frequency.

• Block placed in Master Copies, edited locally: the change is silently scoped to that one PLC. Fix: move the body to the project library's Types folder and "Update type" on every PLC.
• Read-only .al16 file: global library Types open read-only even when the user has Windows write permission on the folder. Uncheck the file's Read-only attribute on the .al16 file and the containing folder.
• OB1 cannot be "library-ized": every consumer project already owns an OB1. Trying to overwrite it from the library raises a red-circle error. Fix: keep OB1 local, ship a higher-numbered Program cycle OB (OB123+) as the shared entry point.
• UDT changed without versioning: renaming a UDT field propagates as an error on the consumer project. Fix: increment the UDT version inside the Type and run "Update type" on every consumer before downloading.
• Multiple Program blocks folders: dragging a Type onto a "Program blocks" folder that lives inside a group folder does not register it as a project-level type. Drop it onto the CPU's top-level Program blocks node.
• Type with hardware-dependent references: any block that uses a hardware identifier (HW ID) will not compile cleanly if dragged into a PLC whose HW catalog differs. Fix: parameterize HW IDs through PLC tags or an HMI panel selector.
• Forgetting the cyclic OB priority: OB123 must have the same priority (priority class 1, default) as OB1, otherwise scan order becomes non-deterministic. Set the priority in OB Properties > "Cycle time / Priority".
• Library file shared across two engineering stations: two users opening the same .al16 file and saving simultaneously will corrupt the file or silently overwrite each other. Use a single-writer policy (file lock) or move the library to a Git LFS-backed workflow.

12. Frequently Asked Questions