TIA Portal V17 Excluding DB Variables from Snapshot to Start

1. Overview: The Snapshot-to-Start-Value Mechanism in TIA Portal V17

When commissioning a SIMATIC S7-1200 or S7-1500 PLC in TIA Portal V17 (and the V16/V18 family that share the same data block tooling), engineers frequently need to capture the current online values of an instance DB and bake them back into the offline project as the new initial (start) values. The mechanism is exposed in the DB editor toolbar as Copy snapshots to start values and is described in the Siemens SIMATIC programming documentation under the Online and diagnostic functions for data blocks section.

The workflow is straightforward:

1. Open the online connection to the controller.
2. Open the instance or global DB whose values you want to capture.
3. Use Monitor/Modify (the eyeglasses icon) to start online monitoring of the DB.
4. Click the Snapshot button to capture the current monitored values into a hidden online buffer attached to the DB.
5. Click Copy snapshots to start values and choose either All values or Only setpoints.

The result is that the captured values overwrite the Start value column of every tag in the DB (or only the tagged subset). On the next full download of the program, those start values become the initial values the CPU loads into the work memory image and into the remanent image for non-retain tags, giving you a fully pre-loaded machine configuration with no manual re-entry.

The catch: there is no per-tag checkbox in V17 that says "exclude this variable from any future snapshot copy." The feature is a bulk operation against the DB. Engineers who want a tag to keep its compiled start value forever — typically identifiers, machine constants, runtime counters, diagnostic accumulators, or tags tied to physical hardware states — need to use the workarounds described in this article.

2. Why a Per-Variable Disable Switch Does Not Exist

Siemens designed the snapshot/ start-value copy as a bulk DB-level operation, not a per-tag toggle. The official documentation in the Copying the snapshot to the start values help page explicitly lists only two scopes: All values and Only setpoints. There is no third option called Exclude, Skip, or Lock.

Architecturally this makes sense: the snapshot is just a frozen copy of the monitored image. The start-value column of every tag is updated as a single transaction against the offline project. The Setpoints attribute is the only built-in lever that lets you partition tags into two groups, and the toolbar command Only setpoints is the matching filter.

If a tag must be permanently excluded from any future bulk snapshot operation, the supported pattern is therefore:

1. Mark the tags you want to capture as Setpoint in the DB declaration.
2. Leave all other tags un-marked.
3. Always run Copy snapshots to start values > Only setpoints.

That keeps the un-marked tags locked to their compiled start value, regardless of how many times the snapshot is taken.

3. Solution 1: The Setpoints Attribute and the "Only Setpoints" Filter

The Setpoint column in the DB declaration is a per-tag boolean attribute that has been part of the TIA Portal DB editor since V13. It is described in Siemens' data block programming manual as a hint that "this variable is a setpoint parameter that the user changes during commissioning." Tags flagged as setpoint are the only tags copied when you choose Only setpoints.

For a configuration-heavy FB (a recipe block, a valve matrix, a multi-axis parameter table) the recommended tagging pattern is:

Tag category	Setpoint attribute	Snapshot behavior	Examples
Tuning / recipe / setpoint data	Yes	Captured by Only setpoints and by All values	iSetPressure, rFillVolume, sRecipeName
Constants and identifiers	No	Never overwritten	sMachineID, wHWType, iAxisCount
Runtime/diagnostic data	No	Never overwritten; DB-internal state only	iCycleCounter, tLastFault, bInitialized
Physical I/O mirrors	No	Never overwritten; tied to hardware state	bValveOpen (output FB mirror), rActualPos

The Setpoint attribute survives a project save, a recompile, and a download — it is part of the DB's source declaration, not part of the loaded values. Once you set it correctly in the offline project, every future snapshot copy honors it as long as you remember to use the Only setpoints command.

4. Step-by-Step: Marking Tags as Setpoints in TIA Portal V17

The procedure below assumes an S7-1500 CPU with firmware V2.9 or later (TIA Portal V17 baseline) and a project that has already been compiled at least once.

1. In the project tree, expand Program blocks and double-click the instance DB (for an FB) or the global DB you want to edit.
2. In the DB editor, switch to the Declaration view (the default landing view, separate from the Data view).
3. If the Setpoint column is not visible, right-click the column header and choose Show/hide columns > Setpoint.
4. Tick the Setpoint checkbox on every tag whose snapshot value you want to capture during commissioning. Typical candidates: iSetpoint_Pressure_SP, rGain_Kp, tDwellTime, bEnableAutoTune.
5. Leave the checkbox empty on identifiers, runtime counters, diagnostic timestamps, and any tag that mirrors a physical input/output state.
6. Press Ctrl+S to save, then Compile > Software (rebuild all) so the new declaration metadata is baked into the offline DB.
7. Download the rebuilt program to the PLC so the new Setpoint metadata is in the online project as well.
8. After commissioning, open the DB online and click the eyeglasses icon to start Monitor all.
9. Wait for the values to settle, then click Snapshot (the camera icon in the DB toolbar) to freeze the current values into the snapshot buffer.
10. Click Copy snapshots to start values and select Only setpoints.

The start-value column of every setpoint-marked tag is updated. The start-value column of every non-setpoint tag is left exactly as compiled. The next Download to device > Hardware and software (complete) will load the new setpoints, while identifiers, counters, and diagnostic tags continue to come up with the values defined in the offline source.

5. Solution 2: FB Init Input Pattern for Hard-Coded Defaults

Some tags are not configuration data at all — they are state that the FB initializes on first scan. Examples: a bInitialized flag, a tLastErrorTime cleared to T#0s, a iRetryCounter reset to 0. You do not want to capture them into a snapshot because their value is supposed to be the default, and the snapshot may be taken after a fault where the counter is mid-count.

The clean pattern in this case is to expose an bInit (or iCmd = CMD_INIT) input on the FB that, when pulsed, writes the static defaults back into the static section. The snapshot copy operation never sees those tags change because they are written by code, not by online monitoring at the moment you snap. Code fragment (SCL, suitable for an FB static section):

// FB "ValveCtrl" - static section, init handling
IF bInit OR NOT bInitialized THEN
    // reset every state tag to its compiled default
    iRetryCounter       := 0;
    tLastErrorTime      := T#0s;
    tDwellTimer         := T#0s;
    bOutputLatch        := FALSE;
    rIntegralAccumulator := 0.0;
    bInitialized        := TRUE;
END_IF;

// normal control code follows
IF bEnable THEN
    // ...control law...
END_IF;

With this pattern the snapshot copy can safely be run as All values if you wish, because the runtime state will be reset on the next bInit pulse anyway. Typical triggers for bInit:

• First scan of OB100 (warm restart) — call the FB with bInit := TRUE on the first cycle only.
• Operator HMI button "Reset to defaults."
• Recipe change HMI event (optionally combined with the new recipe data download).
• End of a controlled shutdown sequence.

6. Combined Strategy: Setpoints + FB Init for Complex FBs

For a heavily-parameterized FB (recipe block, motion axis block, PID block) the most robust pattern is to layer the two solutions:

1. Setpoint-mark every genuine configuration tag: rSetpoint, rKp, rKi, rKd, tRampTime, iMaxRetries, sRecipeName, bEnableAutoRestart.
2. Do not setpoint-mark the state tags: bInitialized, iCycleCount, tLastFault, rIntegralAccumulator, iCurrentStep.
3. Expose an bInit input that hard-resets every state tag to its compiled default.
4. Always run Copy snapshots to start values > Only setpoints during commissioning, never All values.

This gives you a single, repeatable, audit-friendly workflow. The offline project will always contain exactly the configuration the field engineer dialed in, the runtime state will always start clean, and there is no way for a stray All values click to accidentally bake a fault state into the start values.

7. Verification: Confirming the Filter Behavior

After running the snapshot copy, verify the result before downloading. From the DB editor:

1. Right-click any setpoint-marked tag and choose Go to > Start value in the column header. The value should now match the monitored value you snapshotted.
2. Right-click any non-setpoint tag. Its start value should still match the value shown in the offline source — the snapshot must not have touched it.
3. Cross-check by selecting a non-setpoint tag, pressing Ctrl+F to use the Cross-references tool, and confirming that the only writer is the FB's own initialization code (or, for inputs from HMI, an HMI tag connection in the PLC tag table).
4. Compile the project once more and confirm a clean build with no warnings about "start value overwritten by initialization in OB."
5. Perform a controlled Download to device > Software (only) and watch the online DB: setpoint tags should arrive with the captured values, non-setpoint tags should arrive with the compiled defaults.

A useful spot-check: after the download, set a non-setpoint tag (e.g., iCycleCounter) to a non-default value online. Go offline, open the DB, take a new snapshot, run Copy snapshots to start values > Only setpoints. The start value of iCycleCounter must not have changed, even though the snapshot buffer captured the value 47. If it has changed, the tag is accidentally setpoint-marked or the wrong filter was used.

8. Limitations, Edge Cases, and Multi-Instance DBs

Multi-instance DBs. When the same FB is instantiated multiple times, each instance gets its own IDB. The Setpoint column is per-tag, but the metadata is shared with the FB source. If you change a tag's Setpoint attribute in one IDB, the FB declaration in Program blocks > ValveCtrl [FB1] is updated and all IDBs reflect the change on next compile. Be careful when renaming or refactoring: the attribute is part of the FB's interface signature in the offline source.

Optimized DB access. TIA Portal's default for new S7-1500 DBs is "Optimized block access." The Setpoint attribute, the snapshot feature, and the start-value column all work identically with optimized and non-optimized blocks. No code change is needed when switching.

Retain vs. non-retain tags. The snapshot only affects start values. Remanent tags keep their last value through a warm restart regardless of what the start value is, so the snapshot copy has no observable effect on a retained tag at runtime. It does, however, affect the value the CPU loads on the very first start (cold restart from a cleared PG/PC card), which is exactly when you want configuration data to be present.

Arrays and STRUCT. A Setpoint attribute on a parent ARRAY or STRUCT propagates to its members for the purpose of the snapshot filter. You cannot setpoint-mark only element [3] of an array — it is all-or-nothing for the variable as declared. If you need per-element control, split the array into individually declared scalars or use a STRUCT of scalars.

PLC tag table vs. DB tags. The snapshot copy command is only available on data blocks. The PLC tag table has no snapshot/start-value column and is not affected. Constants you store in the tag table (e.g., "MachineType" = "AKM-V2") are safe by design.

Know-how protection / block privacy. If the FB is know-how protected (with the Block privacy attribute in V17), the Setpoint column is still visible in the generated IDB, but the offline source cannot be opened to change it. To re-tag a know-how-protected FB you must go back to the original library/source and rebuild it. Plan the Setpoint mapping before applying protection.

Library types / typified FBs. The same rule applies, with the added constraint that changing a Setpoint attribute on a typified FB requires editing the master copy in the global library and re-syncing all instances. Use the library's Update instances command after the change.

9. Version Notes: V17 vs V18 / V19 / V20 / V21

The snapshot-to-start-value feature and the Setpoint attribute are present in every TIA Portal version from V13 onward, including V17. The user-facing UI did not change between V17 and V21. The official Siemens help page titled Copying the snapshot to the start values describes the same toolbar command, the same All values / Only setpoints choice, and the same per-tag Setpoint checkbox that exists in V17.

What did evolve across versions is the surrounding tooling:

TIA Portal version	Relevant changes around snapshot / setpoints
V15 / V15.1	Setpoint column standardized across all DB types; optimized block access default for S7-1500/1200.
V16	Snapshot UI gains the explicit All values / Only setpoints split.
V17 (this article's focus)	Unified database, multiuser server-side editing — Setpoint attribute travels with the source.
V18	Trace and cross-references improved; no change to Setpoint semantics.
V19 / V20	No semantic change to Setpoint or snapshot copy.
V21	Online editing improvements; the Siemens help page is currently published for this version, with the procedure unchanged.

Engineers upgrading from V17 to a later version do not need to re-apply any Setpoint work — the metadata is preserved across the upgrade as long as the project is opened, compiled, and saved under the new version.

10. Best Practices for a Reproducible Commissioning Workflow

1. Setpoint-tag aggressively, not sparingly. Mark every genuine configuration tag as Setpoint so the Only setpoints filter captures it. Engineers who under-tag lose values during a All values misclick.
2. Document the Setpoint policy in the FB header comment. Future maintainers (and your future self) need to know why a specific tag is or is not setpoint-marked.
3. Combine with an init input for every FB that has internal state. The combination is the only fully reproducible pattern: Setpoints for the configuration, init input for the state.
4. Always choose Only setpoints in production projects. Reserve All values for the rare case of cloning a running machine 1:1 where every dynamic value must be preserved.
5. Snapshot, do not "Download to device > All" mid-commissioning. The snapshot is a local buffer — it does not change the online PLC. You can experiment, re-snap, and even throw the snapshot away with no consequence.
6. Use a project-level naming convention for setpoint tags. Common style: a trailing _SP on every setpoint parameter, e.g., iPressure_SP, rFlowRate_SP, tDwellTime_SP. It makes the Only setpoints subset visually obvious in the DB editor and in HMI tag pickers.
7. Version-control the offline project immediately after the snapshot copy. The whole point of the workflow is that the offline project is the durable record of the commissioned machine. Commit the project to SVN/Git before any further edits.
8. Cross-check retained vs. non-retained tags in the same DB. Remanent tags will not be re-loaded from the new start value on a warm restart, so the snapshot copy has no observable effect until the next cold restart. Note this in the commissioning checklist.
9. For library/typified FBs, lock the Setpoint policy in the master copy and document it in the library's Type description. Do not let instance sites silently diverge.
10. Test the restore path. After the first download with the new start values, do a controlled MRES / memory reset, download the program again, and verify that the machine comes up in the correct configuration with no operator intervention.

11. Troubleshooting Matrix

Symptom	Likely cause	Fix
"Copy snapshots to start values" button is greyed out	DB is not open in the editor, or no online connection, or the CPU is in STOP with a different program version online	Open the DB, establish an online connection, bring the online/offline program versions to the same state
Tag's start value did not change after Only setpoints	Tag is not setpoint-marked, or its online value matched the existing start value	Tick the Setpoint checkbox and recompile, or change the value online to a different number, re-snap, re-copy
Non-setpoint tag's start value changed unexpectedly	Filter was All values instead of Only setpoints	Re-tag the snapshot from a clean state and re-apply with Only setpoints
Setpoint attribute on a tag is read-only	FB is know-how protected, or comes from a typified library master	Edit the original FB / library master and re-sync
Snapshot value differs from the value shown in Monitor/Modify	Snapshot was taken before the value settled, or the tag is being written by a higher-priority OB (e.g., cyclic interrupt OB30) between snapshot and copy	Freeze the FB with a bHoldSnapshot := TRUE input around the snap, or take the snapshot from a STOP-mode upload
Downloaded start values do not appear online	Tags are remanent, and the PLC is performing a warm restart, not a cold restart	Do a full memory reset (MRES) before the next download, or make the tags non-retained if you want them to track the start value on every restart