TIA TIA V18 Safety: Umwandlung BOOL zu INT

Seb7

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

S7 1516F-3
Programmierung in KOP

Wie kann man im Safety-Teil anhand der Stellung von booleschen Signalen einen Integer festlegen?
Der EN und ENO Move-Befehl dürfen angeblich nicht beschaltet werden.

Konkret geht es darum, dass die Anzahl der laufenden Lüfter gebildet werden soll (Ergebnis => Integer).
Die Laufmeldungen liegen als boolesche Signale vor.

safety_kop.JPG

Mit dem Ergebnis-Integer muss später dann weiter gearbeitet werden (z.B. für >= Abfragen).
Vielleicht hat von euch jemand eine Idee. Komme an der Stelle nicht so recht weiter :rolleyes:

Grüße
Seb
 
Du kannst mit Sprüngen arbeiten, anstatt den EN Eingang zu verwenden.

Unabhängig davon, wäre es an der Stelle aber vielleicht besser (und nachvollziehbarer) mit der ADD Funktion zu arbeiten?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich frage mich als erstes einmal, warum muss man im Safety-Teil die Anzahl der laufenden Ventilatoren berechnen?

Der EN und ENO Move-Befehl dürfen angeblich nicht beschaltet werden.
Nicht nur angeblich.... Ein Blick ins Handbuch kann unter Umständen Aufklärung bringen...


1700045346995.png
 
Ich frage mich als erstes einmal, warum muss man im Safety-Teil die Anzahl der laufenden Ventilatoren berechnen?
Ok, hast du einen anderen Vorschlag, wie man das lösen könnte ohne die Anzahl zu berechnen? Man muss bedenken, dass zur Anschaulichkeit die Anzahl der Lüfter im Posting oben künstlich auf 2 reduziert wurde. Defacto sind aber es deutlich mehr.

Du kannst mit Sprüngen arbeiten, anstatt den EN Eingang zu verwenden.
Sprünge wären eine Idee - ja. Bin ich jedoch kein Fan von und möchte ich so gut es geht vermeiden.

Unabhängig davon, wäre es an der Stelle aber vielleicht besser (und nachvollziehbarer) mit der ADD Funktion zu arbeiten?
Add-Bausteine unterliegen der gleichen Beschränkung mit EN und ENO. add.JPG
 
Ja, kopier die FanX_Running Variablen in einen DB und berechne die Anzahl im nicht sicheren Teil der SPS.
was ist das denn für ein Vorschlag???

Entweder ist die Anzahl sicherheitsrelevant, dann musst Du das auch im Safetyteil programmieren. Falls nicht, dann hat die ganze Anzahlfunktionalität auch nichts im Safetyteil zu suchen.

Grundsätzlich sollte man im Safetyteil nur Programmteile bearbeiten die laut Risikobeurteilung und laut Safetyfunktionsbeschreibung sicherheitsrelevant sind!!!

Aber ob die Anzahl sicherheitsrelevant ist, hatt der TE noch nicht beantwortet, ich denke aber eher ja?

Wieviele Lüfter sind das denn, von denen die Anzahl gebildet werden muss? bei ein par wenigen geht das vielleicht ja mit und/oder etc...

Hintergrund könnte sein: irgendwas (H2-Ventil) kriegt nur ne Freigabe, wenn mindestens 3 Lüfter (von 5) laufen. Z.B. für Ex-Zonen-Reduzierung oder sowas...
 
Zuletzt bearbeitet:
Und vielleicht sollte dass auch jemand umsetzen, der mindestens Grundkenntnisse in der F-Programmierung hat und nicht per Learning by doing und die Fehler finden wir dann im laufenden Betrieb wenn sie auftreten.
Da gibts ja die Aussage, nur "hinreichend qualifizierte Personen" dürfen an Safetyfunktionen arbeiten. Kann ich jetzt beim TE aber nicht einschätzen.
Mir fällt grad auf die Schnelle auch nicht ein, wie ich ordentlich/einfach im F-Teil die Anzahl der laufenden Lüfter rauskriege, ohne Sprünge...
Nebenbeithema, gibts wirklich ne fehlersichere Betriebsmeldung des Lüfters? Eigentlich müsste das sowas wie ne fehlersichere Luftstromüberwachung sein. Evtl. baut man die dann nicht hinter jeden Lüfter sondern in das gemeinsame Rohr. So in der Art: Luftstrom_gesamt_OK... So kenn ich das zumindest...
 
Zuletzt bearbeitet:
Hallo Seb7,


also ich denke mit einem Vorwärts und Rückwärtszähler Sollte es doch eigentlich auch funktionieren, Du musst halt die Eingangsbeschaltung So machen, dass es immer, wenn ein Lüfter dazu kommt bzw. Weg Geht Rauf bzw. Runtergezählt wird. So bist du immer auf der Sicheren Seite. Ich halte auch nicht viel von Sprüngen im Safety oder auch das RLO ist eher umstritten.

1700489696788.png

an dem CV kannst Du dann dein INT drannhängen, das sollte doch so funktionieren.

Gruß Frank
 
Warum sollten Flanken den nicht besser sein? Solange Du die Flanken im Safety Teil machst sollte alles gut sein. Aber so wie es aussieht handelt es sich eh nur um 2 Lüfter warum verknüpft man dann nicht einfach die Bools mit der Funktion. das ist der wenigste Aufwand. Beide Lüfter ok, wenn Beide Laufen und nicht ok, wenn nur einer bzw. keiner Läuft.

Gruß Frank
 
Man muss bedenken, dass zur Anschaulichkeit die Anzahl der Lüfter im Posting oben künstlich auf 2 reduziert wurde. Defacto sind aber es deutlich mehr.
naja, Flanken können jetzt genauso wahrscheinlich/unwahrscheinlich verloren gehen wie Sprünge Quatsch machen... Je nachdem, wo die Betriebsmeldungen herkommen... z.B. 2 von den 10 Lüftern gehn exakt im selben SPS-Zyklus ein... Da machst mit dem Zähler und den Flanken schon ordentliche Klimmzüge... oder halt für jeden Lüfter einen Zähler und am Ende addieren... naja, halt auch nicht wirklich besser find ich...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ducati, das ist mir noch nicht passiert das Flanken verloren gegangen sind. kann ich nicht nachvollziehen und ganz ehrlich ich mach das schon ne weile mit den Safety Sachen. Aber ja ich gebe halt auch zu bedenken das ein Zähler mit einer Flanke leichter zu lesen ist, als Sprungmarken. Denn ein Safety Programm sollte doch leicht zu lesen sein. Sprünge machen das nicht unbedingt. Und solange man die Flanken im Safety Teil Programmiert und das Ergebnis auch noch in einen DB schreibt sollte es damit eher keine Probleme geben.
 
Also ducati, das ist mir noch nicht passiert das Flanken verloren gegangen sind. kann ich nicht nachvollziehen und ganz ehrlich ich mach das schon ne weile mit den Safety Sachen.
standardmäßig gehn die ja auch nicht verloren... Nur Sonderfälle gibts halt auch... Denke da an diese lustigen Timer, die zum Starten ne Flanke brauchen z.B.... aber nie ne Flanke kriegen, wenn das Startsignal schon beim CPU Start ansteht... Was macht denn der F-Flankenbaustein bei CPU-Start, wenn der Eingang bereits ansteht? Vermutlich (hoffentlich) einmal durchschalten?
Ich sag ja nicht, dass die Flankenvariante schlecht ist. Ich persönlich find die nur nicht wirklich besser als die Sprünge ;) Ereignisgesteuerte Sachen find ich für mich persönlich immer zu vermeiden... Aber das ist wie mit Schrittketten vs. Logikverschaltungen vom anderen Thread. Der eine siehts so der andere so...
Hatte letztens son nen ereignisgesteuertes Fernwirkprotokoll IEC 60870-5-104, auch lustig, wenn da Ereignisse manchmal nicht ankommen.

Aber eh ziemlich OT, aber der TE meldet sich ja scheinbar eh nicht mehr...
Aber ja ich gebe halt auch zu bedenken das ein Zähler mit einer Flanke leichter zu lesen ist, als Sprungmarken. Denn ein Safety Programm sollte doch leicht zu lesen sein. Sprünge machen das nicht unbedingt.
Wie gesagt, wenns sicher funktionieren soll, brauchst pro Lüfter 1 Zähler und 2 Flanken. Am Ende die Zähler addieren...
 
Zuletzt bearbeitet:
Hallo dacati, also danke für Dein Feedback, aber ich habe das mal Umgesetzt was ich meine. und es Funktioniert so wie ich mir das Denke. mit einem Zähler für alle ohne Addition und Sonst noch was.

1700549570724.png

1700549589951.png
Ich glaube schon das, dass soweit auch umsetzbar ist. oder was meinst Du?
 
Zurück
Oben