-> Hier kostenlos registrieren
Da wir schon öfter Probleme mit versionierten Typen bzw. deren Bearbeitung in TIA Bibliotheken hatten, möchte ich heute meine letzten Erfahrungen teilen. Baustein-Namen und Versionen dienen nur der Veranschaulichung.
Voraussetzungen:
Globale Bibliothek, beinhaltet folgende Typen:
FB_Sub ist ein allgemeiner Funktionsbaustein, welcher in vielen anderen, in der Bibliothek enthaltenen, Typen wendet wird. Ein Versionssprung zieht hohen Pflegeaufwand nachsich bzw. führt bei Ignorieren des Versionssprungs zu mehreren verwendeten Typ-Versionen des selben Typs in zukünftigen Projekten.
Aufgabenstellung:
Es stehen Änderungen an FB_Base an. Die Funktion FB_Sub soll integriert werden. Der Baustein FB_Base wird in das leere Entwicklungsprojekt gezogen, dort in einer der beiden CPUs instanziiert und bearbeitet. Dabei wird die Funktion FB_Sub als Multiinstanz innerhalb des FB_Base verwendet. Die Schnittstelle des FB_Base wird um das udtSub erweitert. Nach erfolgreichen Funktionstests soll die so entstandene neue Version des FB_Base freigegeben werden.
Erwartetes Verhalten:
Beim Freigeben wird folgendes Verhalten erwartet:
FB_Base wird unter einer neuen Versionsnummer (z.B. V1.0.1) freigegeben.
FB_Base (V1.0.1) verwendet jetzt udtBase (V1.0.0), FB_Sub (V1.0.0) und udtSub (V1.0.0).
Reales Verhalten:
In der Realität hat uns diese Konstellation schon öfter Probleme bereitet und ein anderes Verhalten gefordert. Beim Freigeben des FB_Base möchte das TIA Portal die Typen udtBase (V1.0.0) und udtSub (V1.0.0) ebenfalls zur Bearbeitung öffnen, da angeblich Änderungen an den verwendeten Typen vorgenommen wurden. Wortlaut der Meldung:
Wird dieser Meldung Folge geleistet, (beide udts zur Bearbeitung öffnen), so stellt man zuerst einmal fest, dass FB_Sub ebenfalls in den Zustand "im Test" versetzt wurde. Ignoriert man auch das, so kann die ursprüngliche Änderung an FB_Base freigegeben werden. Allerdings werden dabei auch die beiden udts und FB_Sub unter neuen Versionen freigegeben.
Die so entstandene Version des FB_Base (V1.0.1) verwendet jetzt udtBase (V1.0.1), FB_Sub (V1.0.1) und udtSub (V1.0.1). Akzeptiert man diese Umstände und aktialisiert eine Globale Bibliothek mit den so entstandenen Versionen, so wird in diesem Beispiel der FB_Sub in vielen in der globalen Bibliothek enthaltenen Typen in V1.0.0 verwendet, in der zuletzt bearbeiteten Version des FB_Base allerdings in V1.0.1.
Man hat also zwei Möglichkeiten:
1. Alle vorhandenen Verwendugnen in der globalen Bibliothek aktualisieren (potentiell sehr hoher Aufwand)
2. Man ignoriert diesen Umstand und hat in zukünftigen Projekten mehrere Versionen der Typen instanziiert (unsauber, führt außerdem zu unsauberen Situationen bei der Bearbeitung weiterer Typen).
Wie kann das Verhalten umgangen werden?
Wir haben gestern festgestellt, dass es wohl einen Einfluss hat, welchen CPU-Typ man zur Entwicklung solcher Änderungen verwendet. Bei Verwendung der 1200er CPU konnte die Erzeugung verschiedener Typ-Versionen nicht verhindert werden. Bei Verwendung der 1500er CPU konnte das ideale / erwartete Verhalten erreicht werden.
Außerdem ist uns aufgefallen, dass beim Instanziieren des FB_Base in seiner Ursprungs-Version (V1.0.0) der verwendete Datentyp udtBase ROT (nicht übersetzt / zu aktualisieren) angezeigt wird. Das tritt ausschließlich auf der 1200er CPU auf, die 1500er CPU ist mit der frisch instanziierten Version aus der globalen Bibliothek zufrieden. Das scheint offensichtlich TIA-Portal intern dazu zu führen, dass die 1200er CPU beim Freigeben von Änderungen an FB_Base Änderungen an den verwendeten Typen erkennt (obwohl keine Änderungen vorgenommen wurden) und diese so in einer neuen Version freigeben möchte.
Evtl. hilft dieser Beitrag zukünftig ja jemandem.
Edit:
Hier wurde TIA V16 verwendet. Das Verhalten konnte unter V14 und V15.1 ebenfalls genau so beobachtet werden.
Gruß Christian
Voraussetzungen:
Globale Bibliothek, beinhaltet folgende Typen:
- FB_Base (V1.0.0), verwendet udtBase (V1.0.0) in dessen Schnittstelle
- FB_Sub (V1.0.0), verwendet udtSub (V1.0.0) in dessen Schnittstelle
FB_Sub ist ein allgemeiner Funktionsbaustein, welcher in vielen anderen, in der Bibliothek enthaltenen, Typen wendet wird. Ein Versionssprung zieht hohen Pflegeaufwand nachsich bzw. führt bei Ignorieren des Versionssprungs zu mehreren verwendeten Typ-Versionen des selben Typs in zukünftigen Projekten.
Aufgabenstellung:
Es stehen Änderungen an FB_Base an. Die Funktion FB_Sub soll integriert werden. Der Baustein FB_Base wird in das leere Entwicklungsprojekt gezogen, dort in einer der beiden CPUs instanziiert und bearbeitet. Dabei wird die Funktion FB_Sub als Multiinstanz innerhalb des FB_Base verwendet. Die Schnittstelle des FB_Base wird um das udtSub erweitert. Nach erfolgreichen Funktionstests soll die so entstandene neue Version des FB_Base freigegeben werden.
Erwartetes Verhalten:
Beim Freigeben wird folgendes Verhalten erwartet:
FB_Base wird unter einer neuen Versionsnummer (z.B. V1.0.1) freigegeben.
FB_Base (V1.0.1) verwendet jetzt udtBase (V1.0.0), FB_Sub (V1.0.0) und udtSub (V1.0.0).
Reales Verhalten:
In der Realität hat uns diese Konstellation schon öfter Probleme bereitet und ein anderes Verhalten gefordert. Beim Freigeben des FB_Base möchte das TIA Portal die Typen udtBase (V1.0.0) und udtSub (V1.0.0) ebenfalls zur Bearbeitung öffnen, da angeblich Änderungen an den verwendeten Typen vorgenommen wurden. Wortlaut der Meldung:
Wird dieser Meldung Folge geleistet, (beide udts zur Bearbeitung öffnen), so stellt man zuerst einmal fest, dass FB_Sub ebenfalls in den Zustand "im Test" versetzt wurde. Ignoriert man auch das, so kann die ursprüngliche Änderung an FB_Base freigegeben werden. Allerdings werden dabei auch die beiden udts und FB_Sub unter neuen Versionen freigegeben.
Die so entstandene Version des FB_Base (V1.0.1) verwendet jetzt udtBase (V1.0.1), FB_Sub (V1.0.1) und udtSub (V1.0.1). Akzeptiert man diese Umstände und aktialisiert eine Globale Bibliothek mit den so entstandenen Versionen, so wird in diesem Beispiel der FB_Sub in vielen in der globalen Bibliothek enthaltenen Typen in V1.0.0 verwendet, in der zuletzt bearbeiteten Version des FB_Base allerdings in V1.0.1.
Man hat also zwei Möglichkeiten:
1. Alle vorhandenen Verwendugnen in der globalen Bibliothek aktualisieren (potentiell sehr hoher Aufwand)
2. Man ignoriert diesen Umstand und hat in zukünftigen Projekten mehrere Versionen der Typen instanziiert (unsauber, führt außerdem zu unsauberen Situationen bei der Bearbeitung weiterer Typen).
Wie kann das Verhalten umgangen werden?
Wir haben gestern festgestellt, dass es wohl einen Einfluss hat, welchen CPU-Typ man zur Entwicklung solcher Änderungen verwendet. Bei Verwendung der 1200er CPU konnte die Erzeugung verschiedener Typ-Versionen nicht verhindert werden. Bei Verwendung der 1500er CPU konnte das ideale / erwartete Verhalten erreicht werden.
Außerdem ist uns aufgefallen, dass beim Instanziieren des FB_Base in seiner Ursprungs-Version (V1.0.0) der verwendete Datentyp udtBase ROT (nicht übersetzt / zu aktualisieren) angezeigt wird. Das tritt ausschließlich auf der 1200er CPU auf, die 1500er CPU ist mit der frisch instanziierten Version aus der globalen Bibliothek zufrieden. Das scheint offensichtlich TIA-Portal intern dazu zu führen, dass die 1200er CPU beim Freigeben von Änderungen an FB_Base Änderungen an den verwendeten Typen erkennt (obwohl keine Änderungen vorgenommen wurden) und diese so in einer neuen Version freigeben möchte.
Evtl. hilft dieser Beitrag zukünftig ja jemandem.
Edit:
Hier wurde TIA V16 verwendet. Das Verhalten konnte unter V14 und V15.1 ebenfalls genau so beobachtet werden.
Gruß Christian
Zuletzt bearbeitet:
