TIA compare shows phantom differences
You go online, open the compare, and TIA Portal shows differences although nobody has touched the project since the last download. Sometimes it is a few blocks, sometimes almost the whole project seems to deviate. Almost always one of six causes is behind it, and none of them is a real change to the logic.
How TIA Portal compares
TIA Portal compares blocks via checksums built over defined comparison criteria: source data such as name, program code, interface, comments, properties, tags and constants, and target data, meaning compilation and runtime data including the time stamp. Two objects only count as equal when their checksums are identical; for CPUs of the S7-300/400 series the online compare still runs on the time stamp. The consequence: any criterion that changes flips the verdict, even when the logic is identical. This is exactly where the classic false alarms come from.
The six most common causes
1. Recompiled, but not downloaded again
Every compile produces new target data, meaning compilation and runtime data, even when the compiler emits the same code. If you compile once more after the download, the checksums of offline and online diverge from that moment on; on S7-300/400 the new time stamp alone is enough. The extreme case is well known in the field: compile everything once, and the compare reports the whole program as different.
Fix: Deselect the target data in the comparison criteria so that only source data counts. Or download once, and both sides match again.
2. Comparison criteria confused with view filters
The compare editor has two different knobs. The view options only control what is shown, for example only different or all objects. What actually enters the verdict is decided by the separate comparison criteria, meaning which checksums count. Set unfavourably, large parts of the project suddenly appear different, in one forum case a good 90 percent, although everything was identical. Worth knowing: in an offline/online compare the criteria only take effect inside the compare editor, the status in the project tree is not affected by them.
Fix: Check and consciously set the comparison criteria before judging the result. Only then is the difference list meaningful.
3. Start values against online values in a data block
In the detailed comparison of a data block, the offline start values face the values from the running CPU. That looks like a difference although nothing in the program changed. Real, lasting differences additionally appear when snapshots were copied into the start values or when current values were retained during a download.
Fix: Separate start values from live readings when judging. For the question "did anyone change anything?", the code and the start values are what count, not a temperature's live reading.
4. Comments and formatting count, depending on the version
Up to TIA V17, spaces, line breaks and comments enter the program-code checksum: a pure formatting or comment change then reports a difference. Since V18 there is the "Program code" criterion, which ignores exactly this cosmetics, next to "Program code (Legacy)" with the old, strict behaviour. If you work on an older version or have the legacy criterion set, cosmetics keep showing up as differences. And after upgrading a project, the rule is simple anyway: compile and download first, until then both sides legitimately deviate.
Fix: From V18 on, use the "Program code" criterion instead of "Program code (Legacy)", and compile and download once after a version upgrade.
5. Only the offline/offline compare covers hardware
In an offline/offline compare of two projects you choose either a software or a hardware comparison. The offline/online compare against the CPU is a pure software comparison, hardware differences never show up there. If you do not know that, you wonder why the same project versions produce different results depending on the compare type.
Fix: For the hardware question, upload the station from the CPU and compare the hardware offline/offline.
6. Status "unknown" instead of equal or different
Sometimes the compare shows no verdict, just question marks. Siemens documents two reasons for it: the access rights to a protected CPU are missing, or the download to the CPU was carried out with a TIA Portal version lower than V14, typical for machines taken over from the past. A block that was never downloaded gets its own status, "object only exists offline", instead. Know-how-protected blocks do get a verdict, only the detailed comparison is unavailable for them.
Fix: Legitimize first on protected CPUs. On legacy machines, reset the baseline with one download from the current TIA version.
If you want to see what really changed
For individual objects, TIA Portal ships a detailed comparison that opens both versions side by side and highlights the differences. It works per object, wants to be opened manually, is unavailable for know-how-protected blocks, and the verdict above it stays checksum-based. AnyAutomation Studio therefore compares at source level across the whole PLC: offline between project versions, and online by uploading the running CPU state and comparing it against the project at source level. Time stamps are normalized along the way, so a new time stamp without a code change is simply not a difference. How this fits with Git versioning is covered in the guide.
Conclusion
When the TIA compare reports differences that should not exist, one of six causes is almost always at work: a compile without a download, the comparison criteria, start values against online values, cosmetics entering the checksum, the hardware coverage of the compare type, or a state downloaded from an old TIA version. Knowing them saves you a bug hunt in the code, and if you regularly need to know what really changed, compare at source level.