Resolving Greyed-Out Know-How Protection in TIA Portal V14

Resolving Greyed-Out Know-How Protection in TIA Portal V14

Engineers inheriting legacy S7-1200, S7-1500, ET 200, or S7-300/400 projects frequently encounter a TIA Portal V14 workspace where the Protection tab in a block's Properties dialog is completely greyed out. The symptom prevents the engineer from entering, modifying, or removing a know-how protection password, which in turn blocks any attempt to download the protected block to a CPU that needs it to execute runtime logic. The same conditions that grey out the protection controls frequently disable ladder/FBD rung monitoring as well, compounding the field-engineering problem.

This reference explains the underlying causes, the diagnostic checks, the resolution paths, and the verification steps required to recover editable protection and live monitoring on know-how-protected blocks. The focus is TIA Portal V14 (released 2017) including Update 1 through Update 9, but most of the diagnosis applies to V15, V15.1, and V16 as well.

1. Problem Description

Engineers opening a TIA Portal V14 project report the following symptoms on one or more blocks (FB, FC, DB, or instance DB):

• Right-click the block in the project tree, choose Properties, open the Protection tab. The dropdown list, the password field, and the Configure button are all dimmed and non-interactive.
• The block icon in the project tree shows no padlock symbol, but the block content cannot be opened in the editor, displaying "Block is know-how protected" or "Block protected: cannot display" messages.
• When attempting to download the block to the CPU, TIA Portal refuses with a consistency error referencing the protection level.
• Rung monitoring (Status) is unavailable in both online and offline views; the monitoring LED in the ladder/FBD editor toolbar is greyed out, and the keyboard shortcut Ctrl+F7 is inactive.

The condition is reproducible across multiple blocks in the same project (commonly FC, FB, DB, and system data blocks) and is independent of the project password. The phenomenon appears most often after a project is migrated from a global library, after an upgrade from TIA Portal V13 SP1, or after the project is opened on a workstation that has only TIA Portal V14 Basic installed where the original project was created in TIA Portal V14 Professional.

2. Root Cause Analysis

The greyed-out state of the Protection tab is a deliberate behavior of the TIA Portal editor: the controls are only enabled when the block is in a state where the user is allowed to change its protection. There are four primary root causes, listed in order of frequency observed in the field.

2.1 Block originates from a global library type

If the block was added to the project by dropping a type from a global library (Master Copies + Types pane) rather than a plain copy, the block is stored as a type instance. Type instances reference the master copy in the global library; their internal structure and protection settings are inherited. The editor disables the Protection tab because the protection can only be changed on the type in the library, not on the instance in the project.

2.2 Block is a system block or a system-generated block

System function blocks, system function calls, and certain system data blocks (SDB) generated by the CPU firmware or by HW Config cannot be protected by the user. Examples commonly seen in inherited projects:

• FB41 (legacy CONT_C PID controller from classic STEP 7; appears in TIA Portal only as a copied instance and is non-editable).
• System data blocks for PROFINET, PROFIBUS, or web server configuration.
• System-generated instance DBs automatically created by the compiler for FBs (e.g., the multi-instance DB chained to FB125).
• Motion technology objects (TO) and their associated DBs.

2.3 Project is opened in a read-only state

If the project file (.ap14) or the project folder is flagged read-only at the file-system level, or if the project is stored in a TIA Portal Multiuser Server checkout that has been locked by another editor, TIA Portal opens the project in read-only mode. The Protection tab is dimmed because the change cannot be written back to disk.

2.4 Online session is active and CPU lock is held

When the workstation is online with the target CPU and the block is in RUN-mode test, the editor locks the protection controls to prevent a runtime inconsistency. Disconnecting the online session restores write access.

3. Prerequisites for Diagnosis

Before applying any of the resolution steps, verify the following prerequisites. Skipping any of them can make the protection tab remain greyed out even after a correct procedure.

Confirm the project compiles cleanly. Open Project tree > PLC_x > Program blocks, right-click the folder and select Compile > Software (rebuild all blocks). Any compilation error referencing a protected block must be resolved first; otherwise the editor will continue to mask the Protection tab.

4. Step-by-Step Resolution: Library-Referenced Blocks

This is the most common cause. Use the procedure below to convert a type-instance block into a project-local block on which you can edit protection.

1. Open the global library that contains the master type: Libraries > Open global library and select the original .al14 file.
2. In the project tree, expand PLC_x > Program blocks. Right-click the protected block (for example FC1812 or FB125) and select Properties.
3. In the General tab of the Properties dialog, look at the Name and Path fields. A type instance shows the path of its master in the format <Library name>\<Type name>. Confirm the entry.
4. Close the Properties dialog. Right-click the block again and choose Update > Type instance > Update type instance to verify that the latest version is in use. If the dialog reports that the type has been changed in the library, accept the update.
5. To make the block editable, right-click it and select Library > Detach from library. TIA Portal will copy the type into the project and remove the reference.
6. Compile the program. Open the block's Properties > Protection tab. The controls are now active.
7. To modify the protection, click Configure in the Protection tab. Enter the existing password (you must know the current password to change or remove it). To remove the protection entirely, clear the Know-how protection checkbox, leave the password field empty, and confirm with OK.
8. Re-compile the program. Verify the block compiles without error.

5. Step-by-Step Resolution: System Blocks and System-Generated Blocks

System blocks cannot be made editable through the user interface. The correct resolution depends on the nature of the block.

5.1 Legacy FB41 (CONT_C)

FB41 is part of the standard PID control library that ships with classic STEP 7. In TIA Portal, it is a read-only type. If your project relies on FB41 logic, the recommended remediation is to migrate to a TIA-native PID_Compact (FB1130 in S7-1500) or PID_3Step (FB1131) technology object. The migration replaces the legacy block and removes the system-block protection problem at its source.

5.2 System data blocks (SDB)

SDBs for PROFINET, PROFIBUS, web server, and OPC UA are generated by the CPU firmware and HW Config. They cannot be password-protected, and the Protection tab is intentionally greyed out. The only action available is to verify that the SDB is up to date by running Compile > Hardware (rebuild all) after any hardware change.

5.3 System-generated instance DBs

When you create an FB such as FB125 with Multi-instance capable enabled in its Properties, every call to FB125 inside FB125's parent context causes the compiler to generate an instance DB automatically. These instance DBs are children of the parent block; the Protection tab on the instance DB reflects the protection of the parent FB. To change the protection, edit the parent FB's Protection tab (after detaching from library if applicable) and recompile.

6. Online/Offline State Considerations

TIA Portal can hide the Protection tab when an online connection to the CPU is established. This guards against corrupting the runtime program by changing source properties while the block is in active scan.

1. Close the online session: Online > Disconnect, or click the Disconnect icon in the toolbar.
2. If a write protection is held by the CPU, perform a stop-run reset of the CPU: Online > Online & diagnostics > Operating mode > STOP. Some firmware revisions additionally require Memory reset.
3. Open the block Properties > Protection tab. The controls should now be active.
4. After the change, recompile and download the block. Re-establish the online session for verification.

If the controls remain greyed out after disconnecting, check Project > Card Reader / USB memory > Read user-defined access protection (only present in V14 and later) and remove any leftover write protection from a previous transfer.

7. Re-enabling Rung Monitoring

Rung monitoring (Status) depends on three independent conditions. All three must be true for the status to be displayed.

Once all three conditions hold, click the Monitoring on/off button in the ladder/FBD editor toolbar, or press Ctrl+F7. The status values populate the contacts and coils within one OB1 cycle.

If the button remains greyed out, the cause is almost always that the block is a library type instance (see Section 4) or a system block (see Section 5). Detaching the library link or migrating the legacy block restores both the Protection tab and the monitoring controls simultaneously.

8. TIA Portal V14 Version-Specific Behavior

Several known behaviors of TIA Portal V14 affect this issue. Most were corrected in V14 SP1 and later updates.

If you must remain on V14.0, the workaround for the library-detach bug is to copy the block from the project to a master-copy library, delete the type instance from the project, and re-paste the master copy into the project tree. The pasted copy is a regular project block with full protection edit rights.

9. Verification Procedures

After applying any of the resolution paths, run the following verification sequence before returning the project to production service.

1. Compile clean: Right-click Program blocks > Compile > Software (rebuild all blocks). No errors or warnings should remain in the Inspector window.
2. Protection change test: Open the previously protected block (FC1812, FB125, DB125) and verify in Properties > Protection that the new password or no-protection state is shown. Save the project.
3. Download test: Go online with the target CPU. Drag the block to the online tree and confirm a successful download. The download dialog must show the protection level you expect.
4. Rung monitoring test: With the CPU in RUN, open the block in the editor and press Ctrl+F7. Confirm that bit, byte, word, and integer tags show live values within one OB1 scan.
5. Consistency test: Compare the offline and online program using Online > Compare offline/online. The only differences should be the timestamp and the active protection level; structural content should match exactly.
6. Restart test: Power-cycle the CPU or perform STOP-RUN. The block should load and start executing within the configured startup time. Watch the diagnostic buffer for OB100/OB101 startup OBs and for any error entries referencing the changed block.

10. Troubleshooting Matrix

11. Prevention and Project Hygiene

To avoid recurrence, apply the following practices when creating or maintaining TIA Portal V14 projects.

• Always add blocks as master copies from the library, not as types, unless you specifically need a type-instance update relationship. Type instances are appropriate for vendor-supplied, versioned function blocks; they are inappropriate for blocks that need their protection changed per project.
• Document the know-how protection password in the project archive (password vault) on a per-block basis. Use a project conventions document that lists block, current password, and date of last change.
• Avoid legacy system blocks such as FB41. Migrate to TIA-native technology objects (PID_Compact, PID_3Step, TO_SpeedAxis, etc.) when targeting a CPU that supports them.
• Maintain the project on a write-enabled network share or local SSD. TIA Portal silently opens projects in read-only mode when the underlying storage cannot accept writes, and the read-only state greys out the Protection tab without an obvious warning.
• Apply the same TIA Portal version and Update level to every workstation that opens the project. Mixing V14 Update 3 with V14 Update 7 can mask the Protection tab due to internal block-format version checks.

12. Frequently Asked Questions