ein RS Flipflop in SCL Code

A_G

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

kann jemand das angehängte Bild was in FUP programmiert wurde in SCL hinkriegen ? ich brauche das weil ich eine Fehlermeldung erkennung machen will und da ich nur auf ein einzelnes Bit gucke und der Slice zugriff in FUP nicht funktioniert muss ich denn Code in SCL schreiben.

Ich kann ja mal zeigen was ich da geschrieben hab, nur weiß ich nicht ob das richtig ist.
Code:

IF #aiProProzessgroese >= #inUssGrenzeAlarm AND #diUssQuittierungNo = FALSE THEN
#"ouErr/InfFehlerMeldungNo".%X1 := TRUE;
ELSE
IF #diUssQuittierungNo = TRUE THEN
#"ouErr/InfFehlerMeldungNo".%X1 := FALSE;
END_IF;
END_IF;

Vielen Dank schonmal für die Hilfe
 

Anhänge

  • Unbenannt.png
    Unbenannt.png
    31,2 KB · Aufrufe: 67
wenn ich mir dein FUP-Bild so anschaue dann müßte es doch eher so sein :

Code:
IF (#aiProProzessgroese >= #inUssGrenzeAlarm) AND not #diUssQuittierungNo THEN
   #"ouErr/InfFehlerMeldungNo".%X1 := FALSE;  // <--
ELS_IF #diUssQuittierungNo THEN
   #"ouErr/InfFehlerMeldungNo".%X1 := TRUE;  // <--
END_IF;
... und ein paar kleinere Verschönerungen ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn ich mir dein FUP-Bild so anschaue dann müßte es doch eher so sein :

Code:
IF (#aiProProzessgroese >= #inUssGrenzeAlarm) AND not #diUssQuittierungNo THEN
   #"ouErr/InfFehlerMeldungNo".%X1 := FALSE;  // <--
ELS_IF #diUssQuittierungNo THEN
   #"ouErr/InfFehlerMeldungNo".%X1 := TRUE;  // <--
END_IF;
... und ein paar kleinere Verschönerungen ...
:unsure:
Da wäre aber Rücksetzen dominant und nicht Setzen.
 
Der Code des Bildes in SCL
(A) für Wenn..Dann-Denker:
Code:
IF #aiProProzessgroese >= #inUssGrenzeAlarm THEN
    #SIF_Ausschalten := FALSE;
END_IF;
IF #diUssQuittierungNo THEN
    #SIF_Ausschalten := TRUE;
END_IF;

#ouErrAlarmNo := #SIF_Ausschalten;

(B) alternativ für Leute, die logische Verknüpfungen verstehen:
Code:
#ouErrAlarmNo := #SIF_Ausschalten := (#SIF_Ausschalten AND NOT #aiProProzessgroese >= #inUssGrenzeAlarm) OR #diUssQuittierungNo;

Hinweis: Wenn man im SCL-Code unbedingt ELSE oder ELSIF drin haben will, dann müsste man die Verarbeitungsreihenfolge für das RS umdrehen. (Das könnte problematisch bei Multitasking sein.)

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn ich mir dein FUP-Bild so anschaue dann müßte es doch eher so sein :

Code:
IF (#aiProProzessgroese >= #inUssGrenzeAlarm) AND not #diUssQuittierungNo THEN
   #"ouErr/InfFehlerMeldungNo".%X1 := FALSE;  // <--
ELS_IF #diUssQuittierungNo THEN
   #"ouErr/InfFehlerMeldungNo".%X1 := TRUE;  // <--
END_IF;
... und ein paar kleinere Verschönerungen ...
Sauber in die ELS_IF - Falle getreten :)
Wenn die Reihenfolge wichtig ist, dann wird es mit Else If schnell unübersichtlich.
Seit dem man bei TIA IN KOP/FUP-Bausteinen SCL-Netzwerke einfügen kann, schreibe ich eigentlich recht selten reine SCL-Bausteine.
Simple Verknüpfungen sind einfach in KOP/FUP einfach übersichtlicher.
 
Wenn die Reihenfolge wichtig ist, dann wird es mit Else If schnell unübersichtlich.
- Wenn die Reihenfolge wichtig ist, dann erscheint mir die Umsetzung einer Aufgabe mit Else_If sehr angemessen zu sein, denn bei Else_If ist ebenfalls die Reihenfolge immens wichtig.
- Wenn die Reihenfolge irrelevant ist, dann sollte man sich fragen und sehr genau überlegen, warum man trotzdem angedacht hatte, die Aufgabe per Else_If umzusetzen.

Sauber in die ELS_IF - Falle getreten :)
In den Beiträgen hier im Forum sehe ich immer wieder Warnungen vor der Anwendung von Else_If-Konstrukten, weil sie doch ach so fürchterlich unübersichtlich sein sollen.
Das verstehe ich überhaupt nicht. Denn, dass die Reihenfolge der Abfragen von enormer Wichtigkeit ist, das wissen doch eigentlich alle, die vor der Anwendung warnen.
Ist es denn sooo schwer, sich zu merken, dass immer nur ein einziger der Zweige ('If Bedingung Then' oder 'Else_If Bedingung Then' oder 'Else') durchlaufen wird?
Ist es denn immer wieder sooo überraschend, dass dieser einzige durchlaufene Zweig immer der erst-beste ist, bei dem die abgefragte Bedingung zutrifft?
Ich kann das wirklich nicht verstehen, denn für mich ist das Verfahren so was von klar, dass es an Klarheit praktisch nicht zu überbieten ist.
Was macht die Angelegenheit denn so unübersichtlich? Die Länge und die Vielzahl der Vergleiche und sonstiger Kriterien? Oder sind es nur die etwas zu lang geratenen symbolischen Namen?
Tipp:
Ich frage gerne in Else_If-Konstrukten zuerst die Fälle ab, in denen nichts passieren soll.
Nicht mit kompliziert zusammengesetzten Abfragen à la
"wenn Kriterium 1 erfüllt UND Kriterium 2 erfüllt UND Kriterium 3 erfüllt, dann mach dies",
sondern mit vielen einfachen Abfragen à la
"wenn Kriterium 1 nicht erfüllt, dann tue nix"
"wenn Kriterium 2 nicht erfüllt, dann tue nix"
"wenn Kriterium 3 nicht erfüllt, dann tue nix"
"sonst tue dies".

Das mag unkonventionell und für viele sehr ungewohnt sein, aber unübersichtlich? Das ist es wirklich nicht.
Zumal man sich ersparen kann, ein und dasselbe Kriterium immer wieder abzufragen.
Ich habe schon recht absonderliche Beispiele dafür gesehen, wie längst abgefragte und ausgesonderte Fälle "vorsichtshalber" immer wieder in folgenden Else_If-Zweigen abgefragt werden. So etwas kann die Angelegenheit ganz schön (unnötig!) unübersichtlich werden lassen.
Wenn das, was übrig bleibt, zu kompliziert und zu unübersichtlich erscheint, dann könnte es auch daran liegen, dass die zu lösende Aufgabe kompliziert und schwer verständlich ist - oder der Programmierer den Wald vor lauter Bäumen aus dem Blickfeld verloren hat.
Und genau dann ist es besonders angenehm und schön, wenn man die programmtechnische Umsetzung möglichst einfach und übersichtlich halten kann, z.B. durch das frühzeitige Aussortieren der irrelevanten Fälle, schön übersichtlich, einen nach dem anderen, so wie ich es im Tipp angedeutet habe.

Dass bei Else_If-Konstrukten immer der erst-beste Zweig durchlaufen wird, dessen Bedingung erfüllt ist, macht das Lesen des Programms nicht schwieriger, sondern leichter. Man kann sich absolut darauf verlassen, dass man die restlichen Else_If-Zweige und den Else-Zweig getrost ignorieren darf, sobald der erste Zweig mit zutreffender Bedingung gefunden ist.
 
@Heinileini
Es ging hier ganz einfach um die Dominanz bei der Nachbildung eines S/R in SCL.
Wenn 2 Pfade gleichzeitig erfüllt sind, gibt es eben den Unterschied in der Abarbeitung von 2 getrennten ‚if’ oder eben einem ‚if else_if‘. Darüber ist @Larry Laffer eben gestolpert.
Diesen „Fehler“ habe ich auch schon bei Anderen festgestellt. Da werden seitenlange Konstrukte (z.B. Verfahrfreigaben) in SCL / ST gebaut und dann treten unplanmässig 2 Zustände auf und der höherwertige fällt auf Grund eines falschen Else_If unter den Tisch.
Will man das dann bei Else_If gerade ziehen, dann werden die Anweisungen noch viel länger oder man muss Else_If in mehrere getrennte lf auftrennen.
All das ist bei der achso steinzeitlichen Programmierung in KOP oder FUP deutlich entspannter und übersichtlicher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... oder man muss Else_If in mehrere getrennte lf auftrennen.
Zugegeben, Dieter, das ist ein Manko bei Else_If-Konstrukten. Man hat oft Fälle, in denen es sehr schön wäre, wenn man hier und da ein paar Befehle einfügen könnte, so dass Aktionen (bedingt oder unbedingt) ausgeführt werden können, ohne dass danach die Suche nach einer passenden Bedingung abgebrochen wird. Dann müsste man nicht vorab "auf Verdacht" schon Berechnungen ausführen, die anschliessend u.U. gar nicht benötigt werden.
Ich weiss, dass ich das jetzt sehr bescheiden formuliert habe und ich mir ein oder mehrere Beispiele ausdenken müsste, um klar zu machen, was ich damit eigentlich meine (aber dazu bin ich zu faul ;o).
Else_If ist keine SuperAllzweckPatentLösung. Aber Else_If ist auch lange nicht so schlecht wie sein Ruf.
Mit Else_If kann man schlecht lesbare Programme erzeugen ... aber das kann man mit anderen Mitteln, die ProgrammierSprachen bereitstellen, mindestens genauso effektiv.
Else_If ist selbstverständlich nicht für alle Zwecke/AnwendungsFälle sinnvoll. Aber es ist auch nicht generell unbrauchbar und muss nicht einmal unübersichtlich sein.

Ich gebe auch gerne zu, dass ich eher wenig Erfahrungen mit KOP und FUP gesammelt habe.
Unbestritten sind diese "bildlichen" DarstellungsFormen von Programmen in manchen Fällen konkurrenzlos übersichtlich.
Die ProgrammStrukturElemente Iteration und Selektion (zu letzteren gehört If_Else) sind aber in einer KOP- bzw. FUP-Darstellung eher "schwerfällig".
Genaugenommen ist auch die Darstellung einer BefehlsSequenz in KOP bzw. FUP nicht "realistisch".
Das, was in der Hardware alles zeitlich parallel passieren und ablaufen kann, kann in der Software von 1 Prozessor auch nur seriell abgearbeitet alias "simuliert" werden.
Warum komme ich auf Hardware? Nun ja, die DarstellungsFormen KOP und FUP wurden an das angelehnt, was man aus der Darstellung von HardwareSchaltungen kannte und gewohnt war und auf den neumodischen Kram, der sich aus den Belangen und Möglichkeiten der Software ergab, wollte man am liebsten gar nicht eingehen.
Na ja, dass plötzlich nur noch rechteckige Kästchen für alles (in FUP auch für logische Verknüpfungen) benutzt wurden, war man nicht gewohnt. Das hatte man gerade erst eingeführt, weil man Fernschreiber als AusgabeMedium verwenden wollte, statt die Entwicklung von Grafik-fähigen Medien abzuwarten bzw. sie noch schneller voranzutreiben.
Kurzum, bevor KOP und FUP eingeführt wurden, wussten wir schon, dass in puncto Übersichtlichkeit noch menschenfreundlichere Varianten möglich sind. ;)
U.s.w. ... u.s.w. ...

PS:
Dieter, natürlich läd Else_If dazu ein, Fehler zu machen bzw. es unpassend zu verwenden.
Aber tut es das denn mehr, als es bei allen anderen Befehlen durchaus normal ist? Ich finde: nein.
Vielleicht führt sogar das ständige Warnen vor den Tücken von Else_If dazu, dass es niemand mehr verwenden mag und deshalb niemand mehr in die Verlegenheit kommt, auch mal die eine oder andere positive Seite zu entdecken?
 
Das mit dem ELSE_IF funktioniert hier schon, allerdings muss man das hier dominante Setzen nachbilden, es also umgekehrt abfragen, den dominanten Teil zuerst.

Code:
IF #diUssQuittierungNo THEN
    #SIF_Ausschalten := TRUE;
ELSE_IF (#aiProProzessgroese >= #inUssGrenzeAlarm) THEN
     #SIF_Ausschalten := FALSE;
END_IF;
#ouErrAlarmNo := #SIF_Ausschalten;
 
Vielleicht führt sogar das ständige Warnen vor den Tücken von Else_If dazu, dass es niemand mehr verwenden mag und deshalb niemand mehr in die Verlegenheit kommt, auch mal die eine oder andere positive Seite zu entdecken?

Die meisten Entwicklungssysteme für SPS ermöglichen diverse Programmiersprachen.
Nicht nur auf Bausteinebene sondern sehr oft auch innerhalb der Bausteine.
Bei manchen Aufgaben / Problemen bietet eine grafische Darstellung (KOP, FUP. Graph, CFC) Vorteile gegenüber einer rein textbasierten Darstellung.
Das ist auch nicht nur bei SPS so, sondern genauso bei der PC-Programmierung.
Wieviele grafische Tools gibt es im Umfeld von Datenbanken? Ich klick mir eine SQL-Abfrage auch lieber zusammen bevor ich sie mühsam in SQL formuliere.
Genauso kann ich mir eine Benutzeroberfläche auch rein textbasierend erstellen. Soviele Parameter und Ereignisse hat nun z.B. ein Slider auch nicht.
Macht aber heute kaum mehr einer.
Dafür gibt es aber im SPS-Umfeld so einige Programmierer, die KOP, FUP und Graph für ein Relikt aus vergangenen Zeiten halten und alles nur noch in SCL / ST machen wollen. Oft ist ausgerechnet bei diesen meist jungen Kollegen die Arroganz und Ignoranz sich mit anderen Programmierweisen bzw -sprachen zu beschäftigen größer als bei vielen alten Kollegen.
Ich persönlich verwende eigentlich alle Sprachen (ausser mittlerweile AWL) und versuche sie halt passend zur Aufgabenstellung einzusetzen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bin ja mal eher der Meinung, dass der SCL Code im ersten Beitrag eher richtig ist als der FUP Code?

Wenn der Messwert grösser als die Grenze soll doch das Alarmbit true sein?

Es sei denn, Quittierung und Alarmbit wären invertiert, also drahtbruchsicher, was aber hier unüblich wäre. Das "No" im Variablennamen könnte das aber implizieren...

Dann passt aber beides nicht wirklich.

Also wie immer, eher ne Frage, was will der TE oder der Kunde eigentlich machen. Und danach kann man überlegen, wie der Code richtigerweise aussehen müsste...
 
Zuletzt bearbeitet:
Zurück
Oben