Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 20 von 20

Thema: TwinCAT 3.1 Schnittstellen projektübergreifend nutzen

  1. #11
    moon ist offline Benutzer
    Themenstarter
    Registriert seit
    07.09.2012
    Beiträge
    35
    Danke
    8
    Erhielt 1 Danke für 1 Beitrag

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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?

  2. #12
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    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.

  3. #13
    moon ist offline Benutzer
    Themenstarter
    Registriert seit
    07.09.2012
    Beiträge
    35
    Danke
    8
    Erhielt 1 Danke für 1 Beitrag

    Standard

    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...?

  4. #14
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    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.

  5. #15
    moon ist offline Benutzer
    Themenstarter
    Registriert seit
    07.09.2012
    Beiträge
    35
    Danke
    8
    Erhielt 1 Danke für 1 Beitrag

    Standard

    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?
    Geändert von moon (13.06.2014 um 14:34 Uhr)

  6. #16
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    Zitat Zitat von moon Beitrag anzeigen
    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

  7. #17
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard

    Zitat Zitat von moon Beitrag anzeigen
    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.

  8. #18
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    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.

  9. #19
    moon ist offline Benutzer
    Themenstarter
    Registriert seit
    07.09.2012
    Beiträge
    35
    Danke
    8
    Erhielt 1 Danke für 1 Beitrag

    Standard

    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 =)

  10. #20
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    745
    Danke
    27
    Erhielt 164 Danke für 142 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von moon Beitrag anzeigen
    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.

Ähnliche Themen

  1. Schnittstellen programmieren
    Von gischad im Forum Hochsprachen - OPC
    Antworten: 3
    Letzter Beitrag: 05.01.2012, 10:10
  2. Schnittstellen
    Von hene1985 im Forum HMI
    Antworten: 9
    Letzter Beitrag: 14.07.2010, 20:33
  3. libnodave - Schnittstellen !
    Von moojoe im Forum Hochsprachen - OPC
    Antworten: 2
    Letzter Beitrag: 19.06.2007, 11:02
  4. iPod Schnittstellen
    Von Lazarus™ im Forum Elektronik
    Antworten: 5
    Letzter Beitrag: 09.10.2006, 20:36
  5. OP 7 Schnittstellen Kabel
    Von Bernd_B im Forum HMI
    Antworten: 2
    Letzter Beitrag: 26.06.2006, 14:03

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •