TIA-Vergleich meldet Phantom-Unterschiede
Du gehst online, öffnest den Vergleich, und das TIA Portal zeigt Unterschiede an, obwohl seit dem letzten Laden niemand etwas angefasst hat. Manchmal sind es einzelne Bausteine, manchmal scheint fast das ganze Projekt abzuweichen. Fast immer steckt eine von sechs Ursachen dahinter, und keine davon ist eine echte Änderung an der Logik.
Wie das TIA Portal vergleicht
Das TIA Portal vergleicht Bausteine über Prüfsummen, die über definierte Vergleichskriterien gebildet werden: Quelldaten wie Name, Programmcode, Schnittstelle, Kommentare, Eigenschaften, Variablen und Konstanten, und Zieldaten, also Übersetzungs- und Ablaufdaten samt Zeitstempel. Zwei Objekte gelten nur dann als gleich, wenn ihre Prüfsummen identisch sind; bei CPUs der S7-300/400-Reihe entscheidet im Online-Vergleich weiterhin der Zeitstempel. Die Folge: Jedes Kriterium, das sich ändert, kippt das Urteil, auch wenn die Logik identisch ist. Genau daraus entstehen die klassischen Fehlalarme.
Die sechs häufigsten Ursachen
1. Neu übersetzt, aber nicht erneut geladen
Jedes Übersetzen erzeugt neue Zieldaten, also Übersetzungs- und Ablaufdaten, auch wenn der Compiler denselben Code produziert. Wer nach dem Laden noch einmal übersetzt, hat ab diesem Moment abweichende Prüfsummen zwischen offline und online, bei S7-300/400 genügt dafür schon der neue Zeitstempel. Aus der Praxis ist der Extremfall bekannt: einmal alles übersetzt, und der Vergleich meldet das komplette Programm als unterschiedlich.
Abhilfe: In den Vergleichskriterien die Zieldaten abwählen, dann zählen nur die Quelldaten. Oder einmal laden, danach stimmen beide Seiten wieder überein.
2. Vergleichskriterien und Ansichtsfilter verwechselt
Der Vergleichseditor hat zwei verschiedene Stellschrauben. Die Ansichtsoptionen steuern nur, was angezeigt wird, etwa nur unterschiedliche oder alle Objekte. Was tatsächlich ins Urteil eingeht, bestimmen die separaten Vergleichskriterien, also welche Prüfsummen zählen. Stehen sie ungünstig, wirken schlagartig große Teile des Projekts unterschiedlich, in einem Forumsfall waren es gut 90 Prozent, obwohl alles identisch war. Wichtig zu wissen: Beim Offline/Online-Vergleich wirken die Kriterien nur im Vergleichseditor, der Status in der Projektnavigation bleibt davon unberührt.
Abhilfe: Vor dem Bewerten die Vergleichskriterien prüfen und bewusst setzen. Erst dann ist die Unterschiedsliste aussagekräftig.
3. Startwerte gegen Online-Werte im Datenbaustein
Im Detailvergleich eines Datenbausteins stehen die Offline-Startwerte den Werten aus der laufenden CPU gegenüber. Das sieht nach einem Unterschied aus, obwohl am Programm nichts geändert wurde. Echte, bleibende Unterschiede entstehen zusätzlich, wenn Momentaufnahmen in die Startwerte übernommen wurden oder beim Laden Aktualwerte erhalten blieben.
Abhilfe: Beim Bewerten Startwerte und Momentwerte auseinanderhalten. Für die Frage „wurde etwas geändert?" zählen Code und Startwerte, nicht der Momentwert einer Temperatur.
4. Kommentare und Formatierung zählen mit, je nach Version
Bis TIA V17 fließen auch Leerzeichen, Zeilenumbrüche und Kommentare in die Programmcode-Prüfsumme ein: Eine reine Formatierungs- oder Kommentaränderung meldet dann einen Unterschied. Seit V18 gibt es das Kriterium „Programmcode", das genau diese Kosmetik ignoriert, daneben „Programmcode (Legacy)" mit dem alten, strengen Verhalten. Wer auf einer älteren Version arbeitet oder das Legacy-Kriterium gesetzt hat, sieht Kosmetik weiter als Unterschied. Und nach dem Hochrüsten eines Projekts gilt ohnehin: erst übersetzen und laden, bis dahin weichen beide Seiten berechtigt voneinander ab.
Abhilfe: Ab V18 das Kriterium „Programmcode" statt „Programmcode (Legacy)" verwenden, nach einem Versionswechsel einmal übersetzen und laden.
5. Hardware vergleicht nur der Offline/Offline-Vergleich
Beim Offline/Offline-Vergleich zweier Projekte wählst du entweder einen Software- oder einen Hardware-Vergleich. Der Offline/Online-Vergleich gegen die CPU ist dagegen ein reiner Software-Vergleich, Hardware-Unterschiede tauchen dort nie auf. Wer das nicht weiß, wundert sich, warum dieselben Stände je nach Vergleichsart verschiedene Ergebnisse liefern.
Abhilfe: Für die Hardware-Frage die Station aus der CPU laden und offline/offline die Hardware vergleichen.
6. Status „unbekannt" statt gleich oder ungleich
Manchmal zeigt der Vergleich kein Urteil, sondern Fragezeichen. Dafür dokumentiert Siemens zwei Gründe: Es fehlen die Zugriffsrechte auf eine zugriffsgeschützte CPU, oder der Ladevorgang auf die CPU wurde mit einer TIA-Version kleiner V14 durchgeführt, typisch bei übernommenen Altanlagen. Ein Baustein, der nie geladen wurde, bekommt dagegen den eigenen Status „nur offline vorhanden". Know-how-geschützte Bausteine erhalten ein Urteil, nur der Detailvergleich steht für sie nicht zur Verfügung.
Abhilfe: Bei geschützten CPUs zuerst legitimieren. Bei Altanlagen mit einem Laden aus der aktuellen TIA-Version die Basis neu setzen.
Wenn du sehen willst, was sich wirklich geändert hat
Für einzelne Objekte bringt das TIA Portal einen Detailvergleich mit, der beide Versionen nebeneinander öffnet und Unterschiede hervorhebt. Er arbeitet pro Objekt, will manuell geöffnet werden und steht für Know-how-geschützte Bausteine nicht zur Verfügung, und das Urteil darüber bleibt prüfsummenbasiert. AnyAutomation Studio vergleicht deshalb auf Quellcode-Ebene über die ganze Steuerung: offline zwischen Projektständen und online, indem der laufende CPU-Stand geladen und auf Quellcode-Ebene gegen das Projekt verglichen wird. Zeitstempel werden dabei normalisiert, ein neuer Zeitstempel ohne Code-Änderung ist schlicht kein Unterschied. Wie das mit Git-Versionierung zusammenspielt, steht im Leitfaden.
Fazit
Wenn der TIA-Vergleich Unterschiede meldet, die es nicht geben dürfte, ist fast immer eine der sechs Ursachen im Spiel: neu übersetzt ohne zu laden, die Vergleichskriterien, Startwerte gegen Online-Werte, mitgezählte Kosmetik, die Hardware-Abdeckung der Vergleichsart oder ein Stand aus einer alten TIA-Version. Wer sie kennt, spart sich die Fehlersuche im Code, und wer regelmäßig wissen muss, was sich wirklich geändert hat, vergleicht auf Quellcode-Ebene.