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

Ergebnis 1 bis 7 von 7

Thema: FUP, KOP, in AWL

  1. #1
    Registriert seit
    30.08.2010
    Beiträge
    90
    Danke
    88
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Leute

    Hab da mal ne Frage, und zwar geht es um Folgendes wenn man in FUP, oder in KOP Programmiert und es in AWL übersetzt stehen die Anweisungen
    z.B.

    = L4.0
    BLD 103

    dann die normalen eingaben

    dann wider

    =L4.1
    BLD 104

    dann kommt ein Bausteinaufruf

    Wenn ich diese Anweisungen entferne hab ich dan einen anderen Programmablauf oder verändert sich durch dieses was.
    Wäre nett wenn mir das jemand erklären könnte.

    Danke
    Zitieren Zitieren FUP, KOP, in AWL  

  2. #2
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.620
    Danke
    777
    Erhielt 647 Danke für 493 Beiträge

    Standard

    Zitat Zitat von redscorpion Beitrag anzeigen
    Wenn ich diese Anweisungen entferne hab ich dan einen anderen Programmablauf oder verändert sich durch dieses was.
    Wäre nett wenn mir das jemand erklären könnte.
    Wenn du die Zuweisung auf die Lokaldaten entfernst "=Lx.x" dann verändert sich der Programmablauf, denn diese werden sicher wieder irgendwo abgefragt.

    Den Bildbefehl braucht es nur um die Darstellung für FUP zu rekonstruieren. Hat keinen einfluss auf den Programmablauf.

  3. Folgender Benutzer sagt Danke zu vollmi für den nützlichen Beitrag:

    redscorpion (29.07.2011)

  4. #3
    Registriert seit
    17.03.2011
    Beiträge
    14
    Danke
    3
    Erhielt 1 Danke für 1 Beitrag

    Standard

    Hallo,

    nein das stimmt so nicht.

    Wenn man diese Zeile entfernt ohne den CALL an sich zu verändern
    geht gar nichts mehr, da im CALL die Lx.y übergeben werden.

    Wenn man diese Zeilen entfernt, muss man auch den CALL (die Aktualparameter) anpassen.

    Hintergrund:
    Diese Zeilen werden angelegt, wenn man in FUP oder KOP einen CALL programmiert. Und zwar nur bei Eingangsparameter des Typs BOOL.
    Es soll damit verhindert werden, dass ein Eingangsparameter innerhalb des aufgerufenen Bausteins verändert wird.

    Wenn man also versehentlich innerhalb des FCs einen BOOL Eingangsparameter beschreibt hat das bei der FUP/KOP Programmierung keinen Einfluß da ja auf den Lokalstack geschrieben wird.

    Ändert man nun die Zeilen ab, dann ist diese Absicherung nicht mehr wirksam und das Schreiben auf BOOL Eingangsparameter wirkt sich plötzlich auf das Programm aus.

    Also damit muss man sehr vorsichtig sein.

  5. Folgender Benutzer sagt Danke zu matt für den nützlichen Beitrag:

    redscorpion (29.07.2011)

  6. #4
    Registriert seit
    30.08.2003
    Beiträge
    2.196
    Danke
    30
    Erhielt 258 Danke für 229 Beiträge

    Standard

    Zitat Zitat von matt Beitrag anzeigen
    Hintergrund:
    Diese Zeilen werden angelegt, wenn man in FUP oder KOP einen CALL programmiert. Und zwar nur bei Eingangsparameter des Typs BOOL.
    Es soll damit verhindert werden, dass ein Eingangsparameter innerhalb des aufgerufenen Bausteins verändert wird.

    Wenn man also versehentlich innerhalb des FCs einen BOOL Eingangsparameter beschreibt hat das bei der FUP/KOP Programmierung keinen Einfluß da ja auf den Lokalstack geschrieben wird.
    Hallo,

    das dürfte nicht der Grund sein.. Wenn ich IN deklariere, dann ist es IN - es ist ja keine S5. Ausserdem wieso sollte dieser Schutz nur für BOOL gelten? Das mit dem Lokaldaten ist dafür dass man vor den BOOL-Eingängen Vorverknüpfungen machen kann, also zB 2 Kontakte in Reihe.

    Für die Umwandlung von AWL-Aufrufen zu KOP/FUP gibt es ein Tool.

    André
    www.raeppel.de
    mit innovativen SPS-Tools schneller ans Ziel ....
    Zitieren Zitieren Kop/fup  

  7. #5
    Registriert seit
    30.10.2009
    Ort
    10 km vom Herzen der Natur
    Beiträge
    1.626
    Danke
    120
    Erhielt 340 Danke für 255 Beiträge

    Standard

    Zitat Zitat von sps-concept Beitrag anzeigen
    Wenn ich IN deklariere, dann ist es IN - es ist ja keine S5.
    Schonmal ausprobiert?
    Wenn ich einen IN in einem FC verändere, verändere ich auch den angehängten Eingangsparameter, insofern wäre die Begründung von matt nachvollziehbar.

    Dennoch tendiere ich eher zu Deiner Begründung.

    Wenn Siemens in dem Beschreiben von Eingangsparameter durch den aufgerufen Baustein ein Problem sehen würden, hätten sie es sicherlich von vornherein unterbunden und nicht durch ein seltsames Workaround.
    Gruß
    Michael

  8. #6
    Registriert seit
    29.03.2004
    Beiträge
    5.741
    Danke
    143
    Erhielt 1.687 Danke für 1.226 Beiträge

    Standard

    Zitat Zitat von sps-concept Beitrag anzeigen
    das dürfte nicht der Grund sein.. Wenn ich IN deklariere, dann ist es IN - es ist ja keine S5. Ausserdem wieso sollte dieser Schutz nur für BOOL gelten? Das mit dem Lokaldaten ist dafür dass man vor den BOOL-Eingängen Vorverknüpfungen machen kann, also zB 2 Kontakte in Reihe.
    Bei FCs werden alle Parameter ob IN, IN_OUT oder OUT per Zeiger übergeben. Darum kann man in einem FC auch auf einen IN schreibend zugreifen. In KOP/FUP meckert dann zwar die Typüberprüfung (wenn sie denn noch eingeschaltet ist), in AWL funktioniert das aber problemlos.

    Ich glaube aber auch nicht dass das Kopieren auf Lokaldaten wegen dem "Schreibschutz" gemacht wird, der wirklich auch nur bei Bool-Parametern greifen würde.

  9. #7
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von redscorpion Beitrag anzeigen
    ... wenn man in FUP, oder in KOP Programmiert und es in AWL übersetzt ...
    ich hoffe doch sehr, dass sich diese Frage recht bald durch SCL (Standard-Funktionsumfang TIA-Portal) erübrigen wird

Lesezeichen

Berechtigungen

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