Rückführkreise Hydraulik - Verhindern des Einschaltens

M

marscho

Level-2
Beiträge
130
Reaktionspunkte
111
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich bin bei meinem neuen Arbeitgeber dafür zuständig, die Maschinensicherheit allgemein zu durchleuchten.
Zu diesem Zweck analysiere ich aktuell auch einige Sicherheitsprogramme (alles TIA-Portal).
Hier werden hydraulische Hochdruck-Systeme (300bar oder mehr) eingesetzt.
PL-Anforderungen sind tlw. auch bei d, ab nächstem Frühjahr dann auch e (C-Norm).
Für Funktionen mit PLd sind entsprechend zweikanalige Ausgangsstrukturen mit Rückführkreisen vorgesehen (auch diese Rückführungen sind auf sichere Eingänge geführt).

Mein Problem stellt sich nun bei der programmtechnischen Implementierung dieser Rückführungen dar:
Anstatt die FDBACK-Bausteine von Siemens zu benutzen, wird die Logik hier ausprogrammiert. Jedenfalls wird mit den Rückführungen aus Sicherheitssicht nur das Einschalten des Ventils verhindert. Dh, die entsprechenden Ventilausgänge können nur VKE1 annehmen, wenn sich das Ventil in Grundstellung befindet.
Bei Rückführkreisen mit Schützen sieht das anders aus, hier werden FDBACK-Bausteine verwendet.

Ich kenne aus der Vergangenheit auch nur die Nutzung dieses Bausteins, der ja "in beide Richtungen" prüft. Ein Fehler in der Rückführung (weil etwa zum Signalwechsel statt 500ms Grenzwert 2 Sekunden notwendig sind) wird in der Ausgangslogik nicht direkt erfasst - indirekt aber schon, da ja die Rückführung in Grundstellung vor der nächsten Anforderung sein muss.

Reicht das denn aus normativer Sicht?

Gruß

EDITH meint: Aus meiner Sicht verhält sich die Anwendung dabei (zum großen Teil) wie ein FDBACK mit automatischer Fehlerquittierung und Prüfung nur bei Einschaltvorgang des Ventils.
 
Zuletzt bearbeitet:
Hallo,

Du musst, wenn Du keinen bereits validierten Baustein verwendest, diesen selbst
bewerten. Siehe V-Modell in EN ISO 13849-1.
Ob der Test "in nur eine Richtung" ausreichend ist, kann ich von hier aus nicht
bewerten.
Kannst Du den Test "in beiden Richtungen" nicht selbst programmieren oder den FDBACK
(den ich nicht kenne), für Deine Ventile passend konfigurieren?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Marscho,

grundsätzlich liegst Du schon richtig. Es gibt beide Möglichkeiten.
Bei uns im im Pressenbau wurden früher auch beide Möglichkeiten verwendet.

Variante 1 / nur Abfrage der Grundstellungen

Die Grundstellungen beider Sicherheitsventile wurden in Scharfschaltekreis des Sicherheitsschaltgerätes integriert,
das heißt eine Scharfschaltung von Lichtgitter oder Schutztürkreis war nur möglich wenn beide Ventilüberwachungen
ein HIGH-Signal (=GS bzw. Ventile sicher geschlossen ) lieferten.
Das funktionierte soweit, war jedoch keine permanente Abfrage. Somit wurde der Fehlerfall erst beim erneuten Quittierversuch nach einer Ventilabschaltung erkannt.
Dies müsste eine Funktionalität ähnlich FDBACK ergeben ?

Variante 2 / "Pressensicherheitsschaltung"

Hier erfolgte mittels diverser zwangsgeführter Schütze und eines Zeitrelais ("Klappertechnik") eine permanente Abfrage der Ventilansteuerung und des Überwachungssignales.
Das bedeutet beide Signale werden auf Gegenläufigkeit überwacht (XOR), gleiche Signalpegel von Ansteuerung und Rückführung lösen nach einer kurzen
Verzögerungszeit (Kompensation der Ventilschaltzeit) sofort einen Fehler aus.

Da heute in der Software der Kostenfaktor für eine "Pressensicherheitsschaltung" hinfällig ist, verwenden wir nur noch Variante 2 , d.h. permanente Zustandsüberwachung.
Auch hier wird ein XOR und eine Zeitverzögerung von 250 ...500ms (abhängig vom Ventiltyp) vewendet. Alternativ könnte man auch die einzelnen Signale mit UND / ODER abfragen und auswerten, damit sind die Einzelzustände im Sicherheitsprogramm sofort ersichtlich.
 
Zuletzt bearbeitet:
Darf ich dieses Thema mal etwas erweitern?

Bei unseren Anlagen wird die elektrische Anlagensicherheit i.d.R. konventionell per Sicherheitsrelais hergestellt, deshalb habe ich als Programmierer damit nur selten mal zu tun. Wenn ich aber nun die Aufgabe bekomme die Sicherheitsfunktionen in einer Safety-SPS zu programmieren: Ist es dann meine Entscheidung und Verantwortung ob ich nun den Feedback-Baustein von Siemens verwende oder eine eigene (vielleicht fehlerbehaftete) Logik erstelle? Wie stelle ich als Programmierer sicher das der geforderte PL erreicht wird? Oder noch weiter ausgeholt: Darf jeder Honsel der ein Programmiergerät aufklappen kann Sicherheitsfunktionen programmieren, und steht damit (oft unwissentlich) schon mit einem Bein im Knast? Die SiFa's bei der Abnahme einer Anlage können teilweise Schaltpläne lesen und so eine Hardware-Sicherheitsfunktion überblicken und prüfen. Das so jemand sich aber mal das Safety-Programm zeigen läßt habe ich noch nicht erlebt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Darf jeder Honsel der ein Programmiergerät aufklappen kann Sicherheitsfunktionen programmieren, und steht damit (oft unwissentlich) schon mit einem Bein im Knast?
Zum Vergrößern anklicken....

Im Prinzip schon, jedoch sollte man die einschlägigen Normen für "seine" Maschinen schon kennen. Das war in Zeiten ohne programmierbare Sicherheitssteuerungen auch nicht anders, da traf es den Elektroplaner :D

Das so jemand sich aber mal das Safety-Programm zeigen läßt habe ich noch nicht erlebt.
Zum Vergrößern anklicken....

Habe ich schon bei einem Field- Labeling für Kanada erlebt (TüV). Von denen kam auch die Aussage die Sicherheitsprogramme "verständlich" und einfach zu halten,
"Sicherheit wäre keine Spielwiese um mit seinen Programmierfähigkeiten zu prahlen"...

Ist es dann meine Entscheidung und Verantwortung ob ich nun den Feedback-Baustein von Siemens verwende oder eine eigene (vielleicht fehlerbehaftete) Logik erstelle? Wie stelle ich als Programmierer sicher das der geforderte PL erreicht wird?
Zum Vergrößern anklicken....

Bei Problemen bzw. Fragen/ Zweifeln mit speziellen Sicherheitsfunktionen bzw. deren Validierung hilft sicher der Hersteller der Sicherheitstechnik, meist mit speziellen Applikations- Fachleuten, alternativ ist auch die Beauftragung eines freien Maschinensicherheitsbeauftragten keine schlechte Idee.
Bei uns erfolgt eine strikte Trennung bei der Programmerstellung zwischen Sicherheitsfunktionen (das "programmiert" der Elektrokonstrukteur) und der "normalen" SPS- Software welche
der Programmierer übernimmt. Bei der IB wird die Sicherheitsfunktion nach dem 4 Augen- Prinzip nochmals kontrolliert. Nachträgliche Änderungen bei IB vor Ort landen wieder beim Elektroplaner
und werden nur in gemeinsamer Absprache vorgenommen.
 
Die Funktion der mitgelieferten Bausteine ist validiert.
Das erspart dir viel Zeit und Dokumentation im Vergleich zu eigen erstellten Bausteinen.
 
Hallo hier noch mein Senf,
bevor man eine Software schreibt benötigt man eine Softwarespezifikation, dies ist eine Forderung der DIN EN ISO 13849-1 für SRASW.
Wenn es um die Diagnose eines Ventils geht muss man erst einmal Wissen was man erreichen will.
Welche Fehler kann das Ventil haben, welche sind gefährlich und welche erkenne ich mit meinen Maßnahmen. Und hier kommt dann auch die SRASW ins Spiel.
Bei den mir bekannten Ventilen wird eine Stellungsüberwachung am Kolbenschieber mit einem induktiven Sensor vorgenommen, gibt auch welche mit zwangsgeführten Kontakten, hatte ich bisher einmal. Diese Ventile haben meist eine positive Überdeckung.
Die SRASW ist jetzt entscheiden für den zu erreichenden DC!
Also was wollen wir diagnostizieren:

  • · Ventil geht nicht in Grundstellung, bleibt in Arbeitsstellung hängen
  • · Ventil bleibt in Zwischenstellung hängen (positive Überdeckung führt zum Verschließen der Kanäle, muss also kein gefährlicher Ausfall sein)
  • · Schaltzeitveränderungen, verzögertes Abschalten
  • · Ausfall des induktiven Sensors, kann sowohl Dauerhaft 1 als auch dauerhaft 0-Signal ausgeben.
Das wollen wir erreichen, jetzt kommt es auf die Steuerung an und die vom Hersteller bereitgestellten Bausteine wie man das löst.
Wenn man die Signale auf „nicht“ sicheren Eingängen (Siemens) einliest muss jeder Sensor einzeln überwacht (bei z.B. zwei Ventilen wie das oft so ist) werden also in der SRASW eine Reihenschaltung von zwei Sensoren auf einen FDBACK geht nicht, es muss jedes Ventil einzeln überwacht (Plausibilitätsprüfung Eingang zu Ausgang bei jedem Ein- und Ausschalten, mit Schaltzeitüberwachung) werden.
Kann aber auch noch andere Lösungen geben mit dem Einlesen auf „sichere“ Eingänge (zwei Ventile für eine SF) und einer entsprechenden Plausibilitätsprüfung der Eingänge zueinander, das muss man dann aber in einer FMEA darstellen, ich empfehle zwei FDBACK.
Aber ein einfaches Abfragen von 1-Signal führt zu einem wesentlich geringeren DC und die Anforderungen der Kategorien können eventuell nicht eingehalten werden.
Bei der Abfrage eines Schützes sieht das anders aus, da zwangsgeführte Kontakte.
 
Zuletzt bearbeitet:
Zurück
Oben