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

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

Thema: Gutes und Böses oder was sollte man nicht machen (TwinCAT/CoDeSyS)

  1. #11
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von suud Beitrag anzeigen
    Wo wäre denn der Vorteil im Vergleich zur 2. Variante?
    ....
    Das verstehe ich jetzt nicht ganz. Um mehr oder weniger Instanzen zu haben muss ich doch auch mehr oder weniger Instanzen im MAIN-PG erstellt haben?!
    Die 3. Variante trennt strickt zwischen I/Os, die nur den FB selbst "was angehen" und solchen, die man regulär auch im Hauptprogramm (MAIN) benutzt.
    Wenn du I/Os im MAIN deklarieren willst (weil du die dort auch benutzt), kannst du die an die FBs anlegen. (über die Input/Outputs). Wenn die I/Os nur im FB stehen, dann sind sie über den normalen FB-Aufruf nicht sichtbar. Erst die "Zwischenlösung" über FB.Variable lässt sie sichtbar werden.
    Im System Manager bei TwinCAT besteht der Unterschied darin, dass du die I/Os entweder unter "MAIN.Ausgang" findest, oder unter "MAIN.fbBaustein.Ausgang", also direkt dem FB zugeordnet.
    Rein technisch besteht kein Unterschied.

    Wenn du in den Baustein-In-/Outputs auch noch physikalische Adressen reinpackst (deine 2. Variante), sieht es deklarationstechnisch so aus, dass du beim Baustein-Aufruf im MAIN einen Aus- oder Eingang siehts, der "offiziell" belegt werden kann, aber ja schon durch eine direkte I/O-Verknüpfung beschrieben wird. Das könnte zu Missverständnissen oder Doppelbelegungen führen. Und das könnte bei großen Programmen schnell zur Unübersichtlichkeit führen.
    Daher trenne ich immer strickt zwischen bausteininternen I/Os und solchen, die auch für's restliche Programm wichtig sind.
    Zitat Zitat von suud Beitrag anzeigen
    Wo ich mir immernoch unsicher bin, ist ob die Steuerung komplett in der SPS laufen sollte oder ob der Logik-Teil besser in die Visu kommt. Hat den Nachteil, dass die Steuerung nur läuft wenn auch die Visu läuft.
    Andererseits frage ich mich, wie man mit etwas so primitivem wie ST eine komplexe Steuerungslogik implementieren soll, ohne dass der Vorteil der SPS durch die hohe Fehleranfälligkeit beim Programmieren wieder verloren geht? Von der Wartbarkeit und Flexibilität was Erweiterungen angeht mal ganz abgesehen.
    Wenn ich dürfte, würde ich dir mal eines unserer Programme schicken. Da is nichts mit "primitiv". Wir erledigen SPS-Logik, NC-Steuerung (Achskopplungen), Visu, Datenbankhandling und Diagnose über TwinCAT PLC und NC-I => Alles mit ST

  2. #12
    suud ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    19.09.2008
    Beiträge
    24
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Vielen Dank für eure ausführlichen Antworten und Tipps.
    Ich denke mit der Zeit kommt dann auch der Durchblick, wie überall, oder fast überall.
    Beschäftige mich aber auch erst seit 2 Wochen aktiv damit, von daher hab ich noch ein bischen was vor mir.

    Wo ich gerade dran denke fällt mir aber noch eine speziellere Frage zu TwinCAT ein.
    Kann dazu aber auch gerne einen neuen Thread aufmachen, falls das besser ist.
    Wie läßt sich denn am besten eine Art Watchdog-Task/Programm implementieren. Ich möchte gerne mit einem Programm in einem anderen Task überwachen, ob mein Haupt-Task noch läuft. Wenn er nicht mehr läuft, sollen bestimmte Geräte in einen sicheren Zustand gebracht werden (z.B. Ventile zufahren).
    Gibt's da eine besonders elegante/sichere Methode, z.B. über die Verwendung von Bus-Controllern statt Bus-Kopplern o.ä?

  3. #13
    Registriert seit
    22.11.2005
    Ort
    kl.Odenwald
    Beiträge
    716
    Danke
    111
    Erhielt 85 Danke für 71 Beiträge

    Standard

    Zunächst mal voraus, ich habe schon länger nichts mehr mit TwinCat gemacht, aber sowohl die Variante 2 und 3 werfen bei mir mehr Fragen auf.
    Soll den der FB seine Daten kapseln, oder ist das gar nicht die Absicht?
    Also ich würde Variante 1. verwenden.
    Den AT- Befehl nehm ich eigentlich nur dann, wenn mal ein Word oder DWord in einzelne Bits aufgedröselt werden soll.
    Ansonsten soll gibt's doch noch die IN-OUT-Schnittstellen.
    Ich sehe in 2. und 3. keine wirklichen Vorteil, ausser dass es komplizierter wird.
    "Das Leben ist viel zu kurz, um schlecht zu essen !"
    (Johann Lafer zur SWR3 Grillparty)

  4. #14
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard

    Zitat Zitat von kiestumpe Beitrag anzeigen
    Also ich würde Variante 1. verwenden.
    ...
    Ansonsten soll gibt's doch noch die IN-OUT-Schnittstellen.
    Ich sehe in 2. und 3. keine wirklichen Vorteil, ausser dass es komplizierter wird.
    Wir haben es in unserer "Programmierrichtlinie" so vereinbart, dass Variablen eines FBs, die dort als Inputs oder Outputs deklariert sind, generell im übergeordneten Programmteil deklariert sein müssen und auch nur dort dem Baustein übergeben werden.
    Das würde bedeuten, dass alle E/A-Verknüpfungen für die FBs z.B. im MAIN zu deklarieren sind. Bei entsprechend vielen FB-Instanzen müssen ebensoviele E/As deklariert werden. Wird eine neue Instanzt hinzugefügt, darf man die E/A-Deklaration nicht vergessen.
    Kapselt man die E/As für den FB, wird die E/A-Variable automatisch durch die FB-Deklaration erstellt (oder umgekehrt auch wieder gelöscht).
    Die IN_OUT-Schnittstelle sind ja quasi "Pointer". Hier muss man sehr acht geben, welcher Programmteil diese Variable beschreibt.
    Je größer und verschachtelter ein Programm wird, umso mehr hilft einem die Datenkapselung... meine Meinung.
    Zitat Zitat von kiestumpe Beitrag anzeigen
    Den AT- Befehl nehm ich eigentlich nur dann, wenn mal ein Word oder DWord in einzelne Bits aufgedröselt werden soll.
    Verwechselst du hier vielleicht CoDeSys und Step7 SCL? Der AT-Befehl kann in CoDeSys nur zur direkten Adressierung von E/As oder Merkern genutzt werden (AT %I..., AT %Q, AT %M...)
    WORDs aufschlüsseln funktioniert mit dem "."-Operator (wWord.1).

  5. #15
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.222
    Danke
    533
    Erhielt 2.698 Danke für 1.950 Beiträge

    Standard

    Was Beckhoff angeht, befinde ich mich auch noch im Anfängerstatus, komme ja aus der Step7-Ecke. Die Variante 2 finde ich sehr interessant, spart offensichtlich durchaus viel Arbeit. Variante 3 würde ich eher ablehnen, FB-eigene Daten (lokale) sollten auch da bleiben, wo sie hingehören und nie von "außen" geschrieben oder auch gelesen werden.

    Frage zu Variante 2: wo genau wird denn dann der wirkliche physikalische Eingang zugewiesen.

    @MarkusP: automatische Verknüpfung der E/A, kannst du das mal ein wenig genauer beschreiben

    Ein kleines Beispiel zur "Übergabe als Struktur" würde auch sehr lehrreich sein, ich kann mir das zwar in etwa vorstellen, aber auch hier, als Beckhoff-Neuling, wie bekommst du die wirklichen physikalischen E/A in die Struktur.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  6. #16
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    ...Variante 3 würde ich eher ablehnen, FB-eigene Daten (lokale) sollten auch da bleiben, wo sie hingehören und nie von "außen" geschrieben oder auch gelesen werden.

    Frage zu Variante 2: wo genau wird denn dann der wirkliche physikalische Eingang zugewiesen.
    Variante 3 kapselt ja genau diese FB-eigenen "lokalen" Variablen.
    Bei Variante 2 gehören die E/As zum FB, können aber im Falle der Inputs sowohl vom übergeordneten Programm, als auch von den physikalischen Inputs beschrieben werden. Zuweisungen sind hier nicht mehr eindeutig. Solche Durchmischungen sollten meiner Meinung nach vermieden werden.

  7. #17
    suud ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    19.09.2008
    Beiträge
    24
    Danke
    3
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Ich habe mich nun auch für Variante 3 zusammen mit dem Tipp, die Ein- und Ausgangsvariablen in Structs zusammenzuführen entscheiden. Wenn ich im FB dann z.B. schreibe
    sp := IN.SetPos;
    OUT.ActPos := ap;
    kann ich direkt am Namen sehen, was Sache ist.
    Und die EAs sind meiner Meinung nach auch eher zu Kapseln, da sie zumindest in diesem Fall nur den FB intern etwas angehen.
    Übrigens steht auch hier
    http://www.ipsta.de/download/automat...p4_CoDeSys.pdf
    als Richtlinie auf Seite 4-10 ganz oben, dass VAR_INPUT und VAR_OUTPUT nicht auf Adressen gelegt werden darf. Vermutlich eben wegen der möglichen Doppel-Beschreibung. Variante 2 ist also eher "böse".

  8. #18
    Registriert seit
    19.11.2006
    Beiträge
    1.346
    Danke
    6
    Erhielt 254 Danke für 231 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Ralle Beitrag anzeigen
    Ein kleines Beispiel zur "Übergabe als Struktur" würde auch sehr lehrreich sein, ich kann mir das zwar in etwa vorstellen, aber auch hier, als Beckhoff-Neuling, wie bekommst du die wirklichen physikalischen E/A in die Struktur.
    Deklaration der Structuren:
    Code:
    TYPE ST_StructIn:
      STRUCT
         bIn1: BOOL;
         bIn2: BOOL;
       END_STRUCT
    END_TYPE
    
    TYPE ST_StructOut:
      STRUCT
         bOut1: BOOL;
         bOut2: BOOL;
       END_STRUCT
    END_TYPE
    Im FB dann:
    Code:
    VAR
    stStructIn AT%I*: ST_StructIn;
    stStructOut AT%Q*: ST_StructOut;
    END_VAR
    oder gleich die Adresszuweisung in der Structur und nicht im Baustein durchführen.

    Nachteil der Strukturlösung:
    - Soll eine Version des FB weniger oder mehr Eingänge haben, hat das Auswirkungen auf alle anderen FBs.
    - Wenn im System Manager die Verknüpfungen durchgeführt sind und nachträglich an der Struktur was geändert wird (hinzufügen oder löschen einer Variable) werden alle Verknüpfungen gelöscht! Bei entsprechend vielen Variablen in den Strukturen ist das sehr ärgerlich

    ... is Geschmacksache.

  9. Folgender Benutzer sagt Danke zu trinitaucher für den nützlichen Beitrag:

    Ralle (02.10.2008)

Ähnliche Themen

  1. Antworten: 1
    Letzter Beitrag: 20.10.2010, 16:24
  2. Siemens Kurs oder gutes Buch zu Step7 V5.4 Graph
    Von DennisBerger im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 05.12.2009, 13:40
  3. MOD macht nicht was es sollte
    Von Andy082 im Forum Programmierstrategien
    Antworten: 9
    Letzter Beitrag: 21.11.2009, 01:50
  4. Antworten: 6
    Letzter Beitrag: 31.08.2008, 14:50
  5. Techniker- machen oder nicht?
    Von elmoklemme im Forum Stammtisch
    Antworten: 23
    Letzter Beitrag: 26.01.2008, 16:41

Lesezeichen

Berechtigungen

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