FUP, KOP, in AWL

redscorpion

Level-1
Beiträge
90
Reaktionspunkte
0
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Kop/fup

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é
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Zurück
Oben