TIA Im FUP Speicherbaustein bei einer positiven Flanke invertieren

Mcmastur

Level-1
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich arbeite gerade mit TIA Portal V15.1 und versuche gerade ein Bit durch eine Positive Flanke im Wert zu speichernd zu invertieren. Also ist er gerade "0" wird er durch die positive Flanke auf "1" gesetzt und bei erneutem Drücken wieder auf "0". Habe mir ganz einfach gedacht, ich setze den Eingang für Setzen mit einer UND-Verknüpfung von der Flanke und "nicht Speicherbaustein.Q" und den Eingang für Rücksetzvorgang mit einer UND-Verknüpfung von der Flanke und "Speicherbaustein.Q".

Leider musste ich feststellen, dass das nicht klappt. Stehe gerade etwas auf dem Schlauch, kann mir jemand helfen das Problem zu lösen?

LG
Mcmastur
 
Moin Mcmastur,

das ist ein ähnliches Problem, wie das programmieren einer Flanke. Man muss sich den letzten Zustand merken und dazu einen Hilfsmerker spendieren.

Wenn Du schon eine Flanke zum Toggeln des Bits hast, musst Du Dir mit dem Toggeln des Bits merken, auf welchen Wert Du das Bit zuletzt getoggelt hast. Dann jeweils in den anderen Zustand toggeln. Dabei musst Du beachten, dass ENTWEDER auf 1 ODER auf 0 getoggelt wird und der jeweils andere Programmteil nicht bearbeitet wird.

Beispiel AWL (so wird es, denke ich am deutlichsten):

Code:
U #Flanke // Deine Flanke
U #Bit // zu toggelndes Bit (gleichzeitig Prüfung des letzten Durchgangs)
SPB TOG1 // springen, wenn Bit = 1
// wenn Bit = 0
SET  // VKE auf 1 setzen
S #Bit // Bit auf 1 setzen
SPA ENDE // Bearbeitung beenden

TOG1: SET // wenn Bit = 1; VKE auf 1 setzen
R #Bit // Bit auf 0 setzen

ENDE:nop 0

VG

MFreiberger
 
Moin,

bBit := bBit XOR bImpuls

das ist ja wunderbar! Ich sollte mir hinter die Ohren schreiben immer zunächst zu prüfen, ob man nicht eine XOR-Verknüpfung einsetzen kann.
Das er ja schon für die Parity-Ermittlung sehr erhellend!

Allerdings ist man manchmal so festgefahren, weil man es "schon immer" so macht. Also es hilft auch Bewährtes immer mal wieder zu hinterfragen und neu zu durchdenken.

VG

Mario
 
Allerdings ist man manchmal so festgefahren, weil man es "schon immer" so macht. Also es hilft auch Bewährtes immer mal wieder zu hinterfragen und neu zu durchdenken.
Genau! Denn ...

Zwei Aussagen, die man nicht ungeprüft hinnehmen sollte:
- "Das machen wir schon immer so!"
- "Das machen die Anderen auch so!"

Und ggfs auch die dritte:
- "Das haben wir ja noch nie gehabt!"
:D
 
Moin ducati,

naja, nur weil man etwas schon immer so macht und es funktioniert muss man es jetzt nich unbedingt anders machen, nur weil man eine Zeile Code spart ;)

Das stimmt. Aber: es ist auch nicht verkehrt, wenn man sich einfach noch einmal Gedanken zu einer Programmierung macht. Da geht es ja auch nicht unbedingt darum im konkreten Fall die ein oder andere Programmierzeile einzusparen. Wenn ein Problem aber einfacher lösbar ist kann man in Zukunft ja die einfachere Lösung verwenden ;)

VG

Mario
 
naja, nur weil man etwas schon immer so macht und es funktioniert muss man es jetzt nich unbedingt anders machen, nur weil man eine Zeile Code spart ;)
Da bin ich generell ganz auf Deiner Linie, ducati!
Aber die paar Zeilen mehr sollten dann auch so funktionieren, wie in der Aufgabenstellung gefordert.
VKE-abhängiges S(etzen) und R(ücksetzen) sind hier im Forum nicht so gern gesehen, obwohl ich sie nicht prinzipiell für "verwerflich" halte.
Aber unnötige ProgrammVerzweigungen halte sogar ich nicht nur für unnötig, sondern auch für ein unnötiges Zugeständnis an die von der HochsprachenProgrammierung geleiteten Programmierer.
Das hat aber nichts mit einer fehlenden Möglichkeit der Hochsprachen zu tun, sondern damit, das diese Möglichkeit leider ziemlich unbekannt ist bzw. totgeschwiegen wird und man dadurch verleitet wird, unnötige WorkArounds zu erfinden.
Vermutlich werden zu oft als AnwendungsBeispiele für IF-ELSE-THEN-Konstrukte ausgerechnet solche Beispiele herangezogen, die bestens auf IF-ELSE-THEN verzichten könnten.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Je mehr Zeilen man schreibt, desto mehr Fehler kann man machen. Und wenn es sehr umständlich gelöst ist, dann fällt auch kaum auf, daß der Code gar nicht funktioniert. :cool:
z.B. wenn #Flanke = 0 dann wird #Bit IMMER auf 1 gesetzt:
Code:
U #Flanke // Deine Flanke
[COLOR="#FF0000"]          <-- hier fehlt: SPBN ENDE[/COLOR]
U #Bit // zu toggelndes Bit (gleichzeitig Prüfung des letzten Durchgangs)
SPB TOG1 // springen, wenn Bit = 1
// wenn Bit = 0
[COLOR="#FF0000"]SET[/COLOR]  // VKE auf 1 setzen[COLOR="#FF0000"] <-- überflüssig[/COLOR]
S #Bit // Bit auf 1 setzen
SPA ENDE // Bearbeitung beenden

TOG1: [COLOR="#FF0000"]SET[/COLOR] // wenn Bit = 1; VKE auf 1 setzen[COLOR="#FF0000"] <-- überflüssig[/COLOR]
R #Bit // Bit auf 0 setzen

ENDE:nop 0

So kann man viel weniger Fehler und Unnützes machen:
Code:
X #Flanke
X #Bit
= #Bit

FAQ: Stromstoßschalter in KOP/FUP/AWL

Oder wenn es unbedingt ohne XOR in AWL sein soll:
Code:
U #Flanke
SPBN ENDE

UN #Bit
= #Bit

ENDE: SET

Harald
 
Zurück
Oben