TwinCAT 3.1 Schnittstellen projektübergreifend nutzen

[moon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend zusammen,

gibt es eine Möglichkeit, in TC3.1 projektübergreifend Schnittstellen (Interfaces) zu benutzen?
Ich möchte quasi ein Projekt anlegen, welches nur Schnittstellendefinitionen enthält und diese Schnittstellen in anderen Projekten in der gleichen Projektmappe nutzen. Sinn dahinter soll sein, dass ich mehrere Projekte habe, die sich an die gleichen Schnittstellendefinitionen halten sollen, anstatt für jedes Projekt die gleichen Schnittstellen immer wieder einzeln schreiben zu müssen. So würden sich auch Änderungen in den Schnittstellen einheitlich und gleichzeitig auf alle Projekte gemeinsam auswirken.
Geht sowas?

Vielen Dank
moon

 

[Neals]

Warum erstellst du nicht einfach eine Library aus dem Schnittstellen Projekt?

 

[mac203]

Zuviel Werbung?
-> Hier kostenlos registrieren

Würde ich auch so sehen.
Je nach Geschmack eine PLC oder C++ Library!

 

[moon]

Das klingt interessant, daran habe ich noch nicht gedacht / es noch nie gemacht.
Werd ich mal ausprobieren.
Vielen Dank euch!

 

[moon]

Ich habe noch eine Frage zu dem Thema:
Wenn ich das richtig sehe, kann man nur voll implementierte Bausteine in einer Bibliothek vorgeben oder alternativ Schnittstellen mit Methoden.
Gibt es eine Möglichkeit, Schablonen von FBs mit Input und Output-Vatiablen vorzugeben? Wäre schön, wenn jedes meiner Programme z.B. einen Safety-FB implementieren müsste, der bei allen die gleichen Ausgänge (zB "Notaus", "Fehlersituation", "betriesbereit",...)hat. So hätten die Programme zumindest alle die gleiche Struktur, könnten ihre Routinen aber selber individuell implementieren...?

Schönes WE!

 

[Neals]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo moon,

bei Funktionsblöckend welche als Objekte verwendet werden ist es nicht vorgesehen, dass diese direkte Input/Output Variablen verwenden. Stattdessen werden nur Methoden und Properties verwendet. Stell doch einfach eine "Execute"-Methode bereit, welche alle diese Variablen entgegen nimmt und zyklisch aufgerufen werden muss. Eine andere Möglichkeit wäre ein Basis-FB den du über EXTENDS dann einfach erweiterst. Alle vom Basis-FB abgeleiteten Bausteine sollten dann auch die im Basis-FB definierten Input/Outputs bereitstellen. Darin kannst du die Routine dann individuell implementieren, bzw. erweitern.

Gruß, Neals

 

[moon]

Ich habe nun schon ordentlich an meinem Design rumexperimentiert, wo ich gerade hängenbleibe:
I_Base: definiert 2 Properties, 1 Methode
FB_Base: implementiert I_Base
FB_Child: EXTENDS FB_Base
--> Beim Child werden nun blöderweise die Properties des Interfaces neu im Projektbaum eingetragen, sodass deren Implementierung aus der Elternklasse überschrieben wird und ich die neu angelegten Properties erst wieder per Hand entfernen muss.
Wie kann ich das verhindern? (Sonst könnte man ja denken, mann MUSS die Properties neu implementieren, könnte aber tatsächlich die Implementierung des Parents nutzen...)

 

[mac203]

Den Zustand kenne ich auch und weiß nicht so recht, ob es gewollt oder nicht gewollt ist.
Ich werde mal versuchen, das heraus zu finden.

Es sei denn, Neals hat das schon gemacht?!

 

[moon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Könntet Ihr mir freundlicherweise nocheinmal kurz erklären, warum / wann man Properties und Methoden sinnvoll einsetzt?
Ich habe diese zwar jetzt auch schon in meinem Projekt entsprechend Euren Empfehlungen eingesetzt, allerdings finde ich irgendwie, dass die Funktionalität von Beiden auch irgendwie mit den bisherigen normalen FB's realisiert werden kann.
Danke schonmal.

 

[mac203]

...mit den bisherigen normalen FB's realisiert werden kann

Du hast vollkommen Recht. Du benötigst nichts von alledem und kannst alles wie bisher lösen.
Die Objektorientierung ist ja eine Erweiterung in der PLC.

Wenn man aber nun nach den gängigen Stilmitteln der Programmierung objektorientiert programmieren möchte, so macht es eben nur Sinn, anstelle von VAR_INPUT /VAR_OUTPUT mit PROPs (Set/Get) zu arbeiten, usw.

Letztlich ist es ein Frage des Stils und der Vorgabe, wie man programmiert (bzw. programmieren muss).

 

[moon]

Hm..Ok...
Ich denke ich habe mir mittlerweile ein halbwegs vernünftiges Konzept mit Methoden und Properties ausgedacht (würde ich am Ende hier auch kurz für andere OOP-Neulinge vorstellen). Woran ich noch hänge:
Eine Methode soll ja eine möglichst gekapselte Einheit sein. Wenn ich nun z.B. einen Aktor schalte, würde ich die Variable (globale Variable, auf HW gemappt) direkt in der Methode setzen. Nun möchte ich den FB mit der Methode aber auch in anderen Projekten nutzen und mache eine Bibliothek draus. Dann funktioniert aber ja der Verweis auf meine GlobaleVariable in der Methode nicht mehr. Das heißt, die aufrufende Instanz muss sich um Hardware-Kram kümmern, von dem sie eigentlich nichts wissen sollte.
Wie löse ich diesen Konflikt auf?

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Indem Du die Variable lokal im FB anlegst: Aktor AT %Q*:BOOL;

Und noch eine Anmerkung zu Properties und Methoden: So wirklich gelungen finde ich die nicht. Ihre lokalen Daten und Rückgabewerte stehen temporär auf dem Stack und lassen sich deshalb bei laufendem Programm nicht beobachten. Klar kann man das Resultat einer Property Set in der Regel an einer lokalen Variablen des aufgerufenen FB's sehen, und das Ergebnis einer Property Get kann man einer statischen Variable der aufrufenden POU zuweisen. Trotzdem klafft beim Einsatz von Properties und Methoden zwischen aufrufender und aufgerufener POU ein schwarzes Loch, das mir gar nicht gefällt. Um Methoden kommt man kaum herum, aber von Properties habe ich mich mittlerweile wieder verabschiedet. Die statischen VAR_INPUT/VAR_OUTPUT halte ich für Automationsaufgaben einfach besser geeignet.

 

[moon]

Indem Du die Variable lokal im FB anlegst: Aktor AT %Q*:BOOL;

Das hatte ich befürchtet. Dann geht mir damit aber ja auch die Übersicht über alle I/Os verloren und ich kann die Variable nur in diesem einen FB benutzen. Wenn ich also eine Sicherheitsroutine im Hintergrund laufen lassen möchte, die selbstständig alle Aktoren z.B. aus macht, kann ich das nicht ohne den gemappten FB...?

 

[StructuredTrash]

Für meinen Geschmack gehören bei OOP-Ansatz I/O's in die FB's. Eine zentrale Abschaltung würde ich dann mit einem FB-Eingang "GlobalActorEnable" machen.

 

[moon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wie realisiserst Du dann Abhängigkeiten der Aktoren untereinander?
z.B.: Aktor 1 darf nur schalten, wenn Aktor 2 an ist und Sensorwerte 1,2 und 3 auch passen (Unter der Annahme, das Aktor 1und2 jeweils von einem eigenen FB verwaltet werden)
Dafür bräuchte ich ja dann jede Menge In- und Output Variablen an jedem Baustein, die quer durch das ganze Programm gereicht werden...
Oder habe ich da was Essentielles nicht verstanden?

 

[drfunfrock]

Und wie realisiserst Du dann Abhängigkeiten der Aktoren untereinander?
z.B.: Aktor 1 darf nur schalten, wenn Aktor 2 an ist und Sensorwerte 1,2 und 3 auch passen (Unter der Annahme, das Aktor 1und2 jeweils von einem eigenen FB verwaltet werden)
Dafür bräuchte ich ja dann jede Menge In- und Output Variablen an jedem Baustein, die quer durch das ganze Programm gereicht werden...
Oder habe ich da was Essentielles nicht verstanden?

Tip:

Aktoren kann man mit Strukturen verwalten. Eine Struktur, die die statischen Parameter enthält und eine die die Stellwerte bekommt. Evt. fasst man beides zusammen. Dann braucht es pro Aktor nur einen Eingang/Ausgang. Wenn man dann diese Strukturen noch in ein Array legt, gehts noch einfacher

 

[StructuredTrash]

Und wie realisiserst Du dann Abhängigkeiten der Aktoren untereinander?
z.B.: Aktor 1 darf nur schalten, wenn Aktor 2 an ist und Sensorwerte 1,2 und 3 auch passen (Unter der Annahme, das Aktor 1und2 jeweils von einem eigenen FB verwaltet werden)
Dafür bräuchte ich ja dann jede Menge In- und Output Variablen an jedem Baustein, die quer durch das ganze Programm gereicht werden...
Oder habe ich da was Essentielles nicht verstanden?

Ohne Kenntnis der Aufgabenstellung kann man nicht viel dazu sagen. Aber wenn so viele Querabhängigkeiten zwischen 2 FB's bestehen, ist vielleicht die Zusammenfassung zu einem FB sinnvoll.

 

[drfunfrock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe ein ähnlichess Problem mit N von einander abhängigen fast identischen Einheiten. Ich habe für jede

- Eine Struktur, um den Zustand zu speichern (Zustand der Statemachine, Master-Slave, Nächster Betriebszustand, Sollwerte etc) [Ctrl]
- Eine Struktur, um die Maschine zu beschreiben [Parameter]
- Eine Struktur, um die Sensorwerte zu speichern [Prozess-Eingang]
- Eine Struktur für den Output der Aktoren [Prozess-Ausgang]

Der FB bekommt jeweils auch die Ctrl-Struktur eines evtl. Masters als Eingang.

Damit lassen sich so ziemlich alle Maschinen beschreiben und das schöne ist, man kann alles in einer Schleife abarbeiten, wenn die Strukturen in einem Array liegen.

 

[moon]

Damit ich Euch richtig verstehe:
Ihr schlagt das Vorgehen vor, wie analog in diesem Thread diskutiert: http://www.sps-forum.de/beckhoff-codesys-iec61131/26094-einausgaenge-structur-initialisieren.html (Seite 1, trinitaucher)?
Nur dass die Structs in unserem Fall als IN/OUT-Variablen an die FBs übergeben werden und in der aufrufenden Instanz (bei mir wäre es z.B. MAIN) deklariert sind.
--> Damit wäre es möglich, von MAIN oder anderen PRGs aus auf diese Structs zuzugreifen und z.B. vom Rest unabhängig mit einem Sicherheits-PRG alle Output-Structs an die HW im Falle zu überschreiben.
--> Da die FBs nicht direkt globale Variablen ansprechen, können diese weiterhin besser erweitert / vererbt werden.
--> Durch Übergabe jeweils einer anderen Struct-Instanz, ließe sich das Hardware-mapping leicht austauschen, ohne dass die FBs davon etwas mitkriegen.
Liege ich damit richtig?
Wenn ja, wäre ich einen großen Schritt weiter =)

 

[StructuredTrash]

Wenn ja, wäre ich einen großen Schritt weiter

Vielleicht, aber sicher nicht in Richtung OOP. Die OOP ist ja nicht einfach nur eine Sammlung zusätzlicher Programmierwerkzeuge, sondern in erster Linie die Philosophie der Kapselung von Daten und Code in Objekten. Die Objekte sollen von aussen nur Befehle bekommen, ihre Aufgaben aber weitgehend selbständig erledigen. In Deinem Fall sollte dann z. B. das Sicherheits-PRG die Ausgänge nicht mehr direkt schalten, sondern einen Befehl dazu an die FB's geben, in denen die Ausgänge stehen.