Konzept

Das TwinCAT Variantenmanagement unterstützt Sie ab dem Build 4024 bei der Umsetzung und Wartung von Maschinen, für die Sie verschiedene Varianten anbieten. Beispielhaft werden im Folgenden vier Varianten verwendet:

  1. Variante: Basismaschine
  2. Variante: Basismaschine mit der Option A
  3. Variante: Basismaschine mit der Option B
  4. Variante: Basismaschine mit der Option B und C

Alle vier Varianten basieren größtenteils auf derselben Konfigurations- und Codebasis und unterscheiden sich nur geringfügig aufgrund der Optionen. Beispielhaft für diese Optionen können eine variierende Achsauslegung aufgrund von unterschiedlichen Produkteigenschaften und daraus abgeleiteten Dynamiken, aber auch ein zusätzlicher Bearbeitungsschritt mit weiterer Hard- und Software genannt werden.

Eine Aufteilung in vier einzelne TwinCAT Projekte würde aufgrund der großen Überschneidungen zu einem deutlichen Mehraufwand führen, da Änderungen an der gemeinsamen Basis parallel in den unterschiedlichen Projekten gepflegt werden müssten. Das TwinCAT Variantenmanagement ermöglicht an dieser Stelle, die verschiedenen Maschinenvarianten in nur einem einzigen TwinCAT Projekt zu konfigurieren, zu implementieren und zu pflegen und auf diese Weise den dafür notwendigen Aufwand zu minimieren.

Projektvarianten und Gruppen von Varianten

Die Einstellungen, deren Werte sich für die verschiedenen Varianten unterscheiden, können Sie in sogenannten Projektvarianten innerhalb eines TwinCAT Projektes verwalten. Für das zuvor genannte Beispiel würden insgesamt vier Projektvarianten anlegt und die für die Option A notwendigen Konfigurationen würden ausschließlich für die zweite Projektvariante vorgenommen werden.

Wenn Sie Einstellungen für mehrere Varianten gleichzeitig übernehmen wollen, können Sie eine Gruppe von Varianten definieren. Sie stellt eine Sichtweise auf mehrere Projektvarianten parallel dar. Die spezifischen Einstellungen für die Option B, die sowohl in der dritten als auch der vierten Variante enthalten sind, können mithilfe einer solchen Gruppe für beide Projektvarianten simultan übernommen werden. Auf diese Weise wird der notwendige Konfigurationsaufwand minimiert.

Eine spezielle Gruppe, die mit dem Anlegen der ersten Variante automatisch hinzugefügt wird, ist die Gruppe [All]. Sie stellt die Sicht auf alle vorhandenen Projektvarianten dar und kann dementsprechend verwendet werden, um einen spezifischen Wert einer Einstellung für alle verfügbaren Varianten zu übernehmen.

Aktivieren der Konfigurationen

Wenn eine Gruppe ausgewählt ist, ist es nicht möglich, die Konfigurationen zu aktivieren, da unterschiedliche variantenspezifische Werte für eine Einstellung zu einem undefinierten Zustand führen können. Wählen Sie vor dem Aktivieren eine einzelne Projektvariante aus.

Benutzeroberfläche

Mit dem Build 4024 wird für das Variantenmanagement die neue TwinCAT XAE Project Variants Toolbar ausgeliefert. Über diese Toolbar können Sie den Manage Project Variants Dialog für das Erstellen und Verwalten von Projektvarianten öffnen und zudem die gewünschte aktive Variante auswählen. Bei der Auswahl einer Variante wird das TwinCAT Projekt automatisch mit den entsprechenden variantenspezifischen Werten neu geladen.

Ein Objekt, bei dem mindestens eine Einstellung für das Variantenmanagement freigegeben ist, wird mit einem blauen Dreieck in der oberen rechten Ecke des Icons im Projektbaum dargestellt. Bei einer Ausgangsklemme würde das Standardicon Konzept 1: entsprechend erweitert werden: Konzept 2:. Wenn eine Gruppe ausgewählt wird, in deren Varianten unterschiedliche variantenspezifische Werte für eine Einstellung gespeichert worden sind, wird das Icon im Projektbaum mit einem gelb-blauen Dreieck ergänzt. Das Icon der Ausgangsklemme würde in diesem Fall wie folgt aussehen: Konzept 3:.

Integration in das SPS-Projekt

Das TwinCAT Variantenmanagement verfügt über eine durchgehende Integration bis ins SPS-Projekt. Sie können hierfür Compilerdefinitionen variantenspezifisch auf System Manager-Ebene für ein SPS-Projekt festlegen. Diese Definitionen werden automatisch an das SPS-Projekt weitergegeben und können dann innerhalb des SPS-Projektes ausgewertet werden. Dafür müssen zunächst die Compilerdefinitionen für das Variantenmanagement freigegeben werden.

Konzept 4:

Die Compilerdefinitionen auf System Manager-Ebene können im Editor, wie oben dargestellt, verändert werden. Es existieren zwei Möglichkeiten für Compilerdefinitionen:

  • Manual: Sie können eigene Compilerdefinitionen festlegen, die nur für die ausgewählte Variante abgespeichert und an das SPS-Projekt weitergegeben werden.
  • Implicit: Wenn die Funktion „Implicit“ aktiviert ist, werden die Namen der ausgewählten Variante, sowie aller Gruppen zu denen die Variante gehört, automatisch als Compilerdefinitionen gesetzt und an das SPS-Projekt weitergegeben.

Für die Auswertung der Compilerdefinitionen innerhalb des SPS-Projektes können Sie bedingtes Kompilieren und bedingtes Referenzieren von Bibliotheken verwenden.

 

Bedingtes Kompilieren im SPS-Projekt

Bedingtes Kompilieren ist sowohl im Deklarations- als auch im Programmiereditor innerhalb des SPS-Projektes mithilfe von bedingten Pragmas möglich. Auf diese Weise können von Ihnen definierte Abschnitte des Programmcodes automatisch abhängig von der ausgewählten Variante inkludiert oder exkludiert werden.

Beispiel für bedingtes Kompilieren im Deklarationseditor:

                                                                                                                            PROGRAM MAIN
VAR
    {IF defined (Variant1)}
        (* The following variables are only declared, if the compiler define 'Variant1' is set *)
        sVariantUsed                : STRING := 'Variant1';
        bOutput            AT %Q*    : BOOL;
    {ELSE}
        (* The following variables are only declared, if the compiler define 'Variant1' is not set *)
        sVariantUsed                : STRING := 'NotVariant1';
        bInput            AT %I*    : BOOL;
    {END_IF}
END_VAR

Beispiel für bedingtes Kompilieren im Programmiereditor:

                {IF defined (Group1)}
    (* The following code is only executed, if the compiler define 'Group1' is set *)
    nCounter := nCounter + 1;
{ELSIF defined (Group2)}
    (* The following code is only executed, if the compiler define 'Group2' is set *)
    nCounter := nCounter - 1;
{END_IF}

 

Bedingtes Referenzieren von SPS-Bibliotheken

Über die Einstellung Condition der Kategorie Conditional Referencing können Sie im Eigenschaftenfenster der gewünschten Bibliothek Einträge hinzufügen, die mit den für das SPS-Projekt gesetzten Compilerdefinitionen verglichen werden. Unter der Voraussetzung, dass mindestens einer der Einträge mit einer der Definitionen übereinstimmt, wird die Bibliothek aktiv referenziert. Falls keiner der Einträger übereinstimmt, wird die Bibliothek deaktiviert und ausgegraut im Projektbaum dargestellt. In diesem Fall wird auch eine eventuell notwendige Lizenz für die Verwendung der Bibliothek im SPS-Projekt nicht berücksichtigt.

Im Beispiel des nachfolgenden Screenshots eines Eigenschaftenfensters ist die Bibliothek Tc3_CM nur dann aktiv, wenn die Einträge Variant1 oder Variant3 als Compilerdefinition gesetzt sind. Ansonsten ist deaktiviert und die entsprechende Lizenz wird nicht benötigt.

Konzept 5:

Integration in das Stand-alone SPS-Projekt

Das Variantenmanagement unterstützt den Workflow der Stand-alone SPS. Grundsätzlich ist das Stand-alone SPS-Projekt ein eigenständiges Projekt außerhalb des System Manager-Projekts und kann in derselben Projektmappe aber auch in einer separaten Projektmappe verwaltet werden. Im System Manager wird anstelle des gesamten SPS-Projekts ausschließlich die TMC Datei als vorhandenes Element hinzugefügt. Dadurch können das SPS- und das System Manager-Projekt klar voneinander getrennt werden.

Da es sich um zwei eigenständige Projekte handelt, haben beide Projekte ihre eigene Variantenkonfiguration. Wenn Sie eine identische Konfiguration in beiden Projekten planen, können Sie eine bereits existierende Konfiguration in das zweite Projekt importieren.

Die Herausforderung bei der Verwendung eines variantenspezifisch erstellten Stand-alone SPS-Projekts besteht darin, dass beim Update der TMC Datei im System Manager-Projekt das SPS-Projekt zuvor in der richtigen Variante erstellt worden sein muss. Anderfalls passen die Boot-Daten und das Prozessabbild nicht. Deshalb ist es möglich, die Boot-Daten sowie die TMC Datei variantenspezifisch zu erstellen und abzuspeichern. Anstelle der TMC Datei kann dann die Projektdatei .tcpproj des Stand-alone SPS-Projekts im System Manager-Projekt hinzugefügt werden. Auf diese Weise haben Sie im System Manager-Projekt die Möglichkeit, die gewünschte Variante des SPS-Projekts manuell oder automatisch über die dort konfigurierten Varianten auszuwählen. Weitere Informationen finden Sie hier.

Konzept 6:

 

Siehe auch: