TC3: Mehrere minimal unterschiedliche Projekte in einem GIT Repository pflegen

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
Tante Google hat zwar Ergebnisse geliefert, aber die treffen, meine ich zumindest, nicht so ganz zu.
Ich habe ein GIT-Repository für ein TC3 Projekt, was soweit auch funktioniert. Nun sollen in diesem Repository Varianten dieses Projektes abgelegt werden die sich minimal unterscheiden. Zum Beispiel ist die Hardware und das Mapping anders und ein paar Objekte (GVL und das Eine oder Andere Programm) unterscheiden sich.
Ich denke mal der gemeinsame Teil müsste in einem zentralen Branch gepflegt werden und der Rest jeweils in einem individuellen.
Die Frage wäre jetzt, geht sowas und wenn ja, wie?

 

[zuse]

Bei git kann immer nur ein Branch aktiv sein. Das willst du ja nicht.
Aber das Variantenmanagement hört sich nach genau deinem Problem an. Hab das nur mal bei einer Präsentation aufgeschnappt. Hab damit noch nie gearbeitet:

Beckhoff Information System - German

Components for Automation and Control: TwinCAT NT-Realtime-System, Bus terminal, Industrial PC, BECKHOFF-Lightbus

infosys.beckhoff.com

 

[Brro87]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es git im TC3 seit einiger Zeit das Varianten Management, das genau für solche Zwecke die Lösung ist.
https://download.beckhoff.com/download/document/automation/twincat3/Variant_Management_DE.pdf
Tipp: Bei Schnittstellen in der Konfiguration (unter EA/) wie Profibus/Modubus im Zusammenhang mit GIT und Varaianten Management immer auch das Property Flag "Save in Own File" setzen. So lassen sich Änderungen besser im GIT nachvollziehen.

So kannst du alles unter dem gleichen Main/Brach im GIT comitten/pushen und wechselt beim Laden im TC3 jeweils zwischen den Variants.

 

[Neals]

Schau dir mal Git Worktree's an: https://git-scm.com/docs/git-worktree
Damit kannst du ein Git Repository nutzen, deine Varianten als Git Branches verwalten, parallel verschiedenen Varianten gleichzeitig in Git Worktree's öffnen und daran arbeiten.

 

[Brro87]

Wenn innerhalb der Klemmen auch verschiedene Verknüfungen gewollt/angededacht sind unbedingt folgendes Flag 'Mapping' setzen.
-> Dann lassen sich auch einzelen Verknüpfungen den Variants entsprechend anpassen.


Musste dies gerade heute für einen meiner Kunden machen, daher dachte ich ich schreibe es hier noch in den passenden Thread.

 

[seehma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,
Also normalerweise kann man in Twincat die Programmunterschiede entweder per Defines pflegen (seit 4024.x auch sehr elegant mit if), über Konfigurationen im Code selbst oder über Bibliotheken.
Die unterschiedlichen Hardwarekonfigurationen kannst du mit der Unterscheidung "TwinCAT PLC Project" und "TwinCAT XAE Project" realisieren. Das sollte mittlerweile auch sehr gut funktionieren.
Im ersteren hast du dein Programm und die jeweiligen Unterschiede im Programmcode, im Twincat XAE Project hast du dann die Hardware/Runtime-konfiguration und das Mapping.
Das Varianten Management haben wir derzeit noch gemieden, da es sich noch sehr stark ändert von Version zu Version.
Sg
M.

 

[seehma]

Was mir hier noch eingefallen ist, man kann dann bei der erwähnten Variante mit den Defines natürlich auch maschinenspezifisch Codeteile ein und ausblenden. Das ist so ziemlich elegant, einfach und mit Twincat Bordmitteln. Ist dann fast ein wenig so wie bei Twincat 2 wo System-Manager und PLC getrennt waren.
Weißt du was ich meine @oliver.tonn ?
Falls du hier nochwas brauchst einfach melden.
Sg
M.

 

[oliver.tonn]

Erstmal vielen Dank für die vielen Antworten. Was jetzt noch interessant wäre, wie das mit Safety aussieht. Es gibt Anlagen die haben Safety in Form von externer Hardware und andere, die nutzen Beckhoff Klemmen. Bei letzteren können sich die Safety Programme unterscheiden. Wie macht man das mit dem Variantenmanagement?

 

[seehma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wenn die Safety Steuerung eine externe (zb Pilz) ist dann ist die Schnittstelle ja sowieso meist eine oder mehrere Gateway Klemme/n oder das Gateway Modul über Ethercat/Modbus von Pilz oder? Da hast du kein Problem wenn du es so in Solution und PLC aufteilst.

Meiner Meinung nach müsste bei Verwendung von der Beckhoff Safety das Programm immer zur Maschine also zu dem Teil mit dem IO dazu gehören, da Safety ja immer auf der Maschine direkt abgenommen werden muss und somit immer spezifisch ist. (Das wird ja glaub ich sogar dezidiert auf die Klemme gebunden oder? Zumindest kenn ich das von anderen Safety Komponenten, beim Tausch der CPU oder Klemme muss auch das Safety Programm neu aktiviert werden)

Bei Beckhoff ist das glaub ich auch so aufgebaut, das Programm, also die reine PLC kann für mehrere Anlagen verwendet und mit Defines oder Configs abgeändert werden, der Hardwareteil wird dann in der Solution mit dem System und IO Teil abgebildet.

 

[oliver.tonn]

Bei Beckhoff ist das glaub ich auch so aufgebaut, das Programm, also die reine PLC kann für mehrere Anlagen verwendet und mit Defines oder Configs abgeändert werden, der Hardwareteil wird dann in der Solution mit dem System und IO Teil abgebildet.

Der Hardwareteil kann über das Variantenmanagement auch angepasst werden, auch das Mapping.
Bei der Gelegenheit, ist es auch möglich je Variante den Namen einer Klemme zu ändern oder müsste ich da zweimal die Selbe einfügen und je Variante die jeweils andere deaktivieren?

 

[seehma]

Also wenn du PLC und Hardwareteil trennst so wie oben beschrieben dann hast du ja sowieso pro Anlage eine eigene (Hardware-)Solution und dann ist das ja wie eine Variante. In dieser Solution kannst du dich austoben wie du willst, die gibts ja dann pro Anlage einmal.
Weißt du wie ich das meine mit der Trennung?

Ich hab gerade nachgsehen und dachte es gibt da ein Webinar zu aber das scheint es nicht zu geben.
Wenn du willst können wir auch mal über Teams schreiben...
Sg M.

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das mit dem Trennen kenne ich, aber dann müsste ich in GIT wieder mehrere Repositorys haben und dann können sich wieder Fehler einschleichen.
Ich habe mal bei einem vorhandenen Projekt das Varianten Management aktiviert und etwas rumgespielt, das werde ich morgen mal vorstellen und das mit der Safety werden wir auch noch geregelt bekommen.
Sollte auf der Basis eine endgültige Lösung entstehen werde ich hier berichten.

 

[seehma]

Sorry dass ich hier nochmal dazu schreib, du kannst das natürlich alles auch in eine Solution packen -> ein git repo dafür verwenden
Dann wäre das erste Projekt ein Twincat PLC Project und alle Maschinenspezialisierungen laden dessen TMC und sind dann Twincat XAE Projects.