TIA Ansteuerung Antrieb mit Safety

[sps_mitte]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
zum Ansteuern von Antrieben mit Safety nehme ich im Standardbereich ein Motorbaustein und verbinde den Ausgang über ein Com-DB an den Eingang vom FDBACK Baustein im sicheren Programmbereich. Somit kann ich die Standard zugehörigen Faceplates auch nutzen.
Wie läuft es nun aber mit der Rückmeldezeit vom Standardbaustein und der Rückmeldezeit (FDB_TIME) des FDBACK? Der vom Standardbaustein kann in der HMI verändert werden. Nach meiner Kenntnis darf man den FDB_TIME nicht durch ein HMI Schnittstelle ändern??
Wie bekomme ich diese beiden gleich?
Oder hat jemand ein besseren Stil/Idee?

 

[Credofire]

Hallo,

kannste dazu mal ein Bild posten, um was für einen Motorbaustein es sich handelt?
Im Allgemeinen wird der Feedback genutzt von den zwangsgeführten Meldekontakten von den Motorschützen. Das hat also nichts mit Software an sich zu tun. Da hast du vielleicht was falsch verstanden.
Wird dein Motor denn über ein Motoschütz geschalten? Wenn ja, ist auch dieser Meldekontakt als Feedback zu verwenden.
Nach den Sicherheitsrichtlinien sind bewährte Bauteile zu verwenden, wie eben die meisten Motorschütze.

Es gibt aber von Siemens auch die sicheren Motorstarter, leider nur bis zu einer begrenzten Größe. Die sind eigensicher und müssen nicht zurückgeführt werden.

p.s. Mit dem Ändern auss dem HMI hast du Recht, das darf nicht sein. Denn jede Änderung am Sicherheitsprogramm verändert auch immer die Checksum. UNd das ist sehr gefährlich wenn jemand in deinem Sicherheitsprogramm "rumpfuscht".
Wenn du gleiche Zeiten haben willst, lege die Diskrepanzzeit im Safety DB fest, dann kannst du diese Zeit auch im nichtsicheren Bereich verwenden, aber eben immer nur lesend.

 

[sps_mitte]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Credofire,
so meinte ich das, wie abgebildet. Blau Standard Teil, Gelb Sichere Teil.

 

[Credofire]

Also so wie du das darstellst geht es nicht.
Du brauchst in deinem safety Teil den EStop, welcher die eigentliche Stop-Bedingung abbildet. Dann brauchst du den FDBack für die Wiedereingliederung.
Für den EStop brauchst du SICHERE Eingangssignale. Den Ausgang vom EStop nimmst du als Freischaltung für den FDBack. Als Feedback Eingang musst du aber wie schon geschrieben die zwangsgeführten Meldekontakte vom Schütz nehmen. Die Feedback Zeit kannst du aus einem normalen DB nehmen. Die darf aber von aussen nicht änderbar sein. Ich persönlich würde das vermeiden. Ich habe die Zeiten immer direkt dort angetragen.

Auf jeden Fall darfst du NICHT den Ausgang von deinem Motorbaustein als Bedingung für den Safety Teil nehmen. Ich hab leider grad keine Safety Lizenz greifbar, sonst würd ich es dir aufmahlen.
Du darfst aber wohl ein sicheres Signal an deinem unsichern Baustein verwenden. Also quasi die Abschaltverriegelung vom NotAus (Estop). Ich habe das immer aus einem DB genommen so wie du es darstellst.

Also immer beachten: Unsichere Signale im Safety sind als Eingangsvariablen verboten! Ausser Feedbackkanal oder Reset, die können unsicher sein.
Prinzipiell müsstest du deine Zeichnung umdrehen. Erst den Safety Teil und dann den unsicheren Teil.


Gaaanz vereinfacht folgendes Bild:


And den Feedback müssen die Meldekontakte mindestens vom Netzschütz und besser noch vom Motorschütz auch dran.

 

[sps_mitte]

Hallo Credofire,
das mit dem NOT-Halt ist natürlich voraussetzung. Man darf direkt über Merker (S7-Classic) oder auch DBs (TIA) in den sicheren Bereich Befehle zuschicken.

Siehe Bilder

 

[Credofire]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dein Start A macht deinen Safety Teil aber zunichte. Du darfst keinen unsicheren Eingang zur Freischaltung benutzen.
Allenfalls wie gesagt am Feedback oder Reset.

p.s. das mit dem Daten Austausch ist mir klar, man kann auch beide Richtungen in einen DB mit struct packen. Es müssen nicht zwangsläufig 2 DB sein.

 

[sps_mitte]

Diese Info kommt direkt von Siemens
Anhang anzeigen 21331098_Feedback_DOC_V31_de.pdf
https://support.industry.siemens.co...tt_908900/v4/21331098_Feedback_DOC_V31_de.pdf

 

[Credofire]

OK, das ist mir neu. Ich wäre mir aber nicht sicher, ob das auch Sicher im dem Sinne ist.
Normalerweise ist wenn du eine unsichere Variable am Eingang hast, das ganze unsicher.

Aber wie gesagt... kann man halten wie ein Dachdecker.
Am Ende muss du allein entscheiden und deine Entscheidung im Falle auch begründen können.
Ich halte den unsicheren Eingang dort nicht für zulässig, es ist auch keine bewährte Methode meiner Meinung nach.

Und auch Siemens hat keinen Anspruch auf die alleinige Weisheit

 

[sps_mitte]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nach deiner Auffassung müsste jede sichere Ansteuerung von einem sicheren Signal kommen (z.B. Schalter/Taster). Ich habe einige Applikationen gesehen, die genauso aufgebaut sind. Gerade wenn der Befehl von einer Schrittkette kommt, führt kein Weg vorbei.

 

[Credofire]

Wenn du sichere Signale auswerten willst, zB NotAus oder Türschalter, dann muss du es sicher auswerten. Auf jeden Fall am Estop. Möglicherweise ist es ja am FDBack zulässig ein unsicheres Siganl beizumischen.
Du hast deinen Sicherheitsteil der ja zyklisch bearbeitet wird. Daraus kannst du dir eine sichere Variable ziehen wie in meinem Beispiel und diese im Unsicheren Teil verknüpfen.

Mir ist aber grad nicht klar, was du mit jede sichere Ansteuerung meinst.
Du muss wissen, welche Eingänge sicher sein müssen, siehe NotAus usw.... Du must nicht jeden Schalter an einen sicheren EIngang verwenden, nur die, welche du sicher auswerten willst. Dies müssen dann zumindest bewährte Bauteile sein.

 

[sps_mitte]

Eine sichere Ansteuerung ist für mich eine Ansteuerung aus dem F-Teil z.B. über den FDBACK mit dem sicheren Befehlseingang, wo auch Notaus Signal usw. abgefragt werden.

 

[Credofire]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du musst die sicheren Signale aus dem Sicherheitsteil nicht zwangsläufig in deinem Programm verwenden. Es reicht, wenn der Sichere Teil meinethalben dein Netzschütz sicher abschaltet. Wenn du willst, kannst du aber zusätzlich zu dieser Hardwareabschaltung noch dein sicheres Signal im Nichtsicheren Teil verwenden. Ich habe an meinen Motorbausteinen immer auch einen NotHalt Eingang dran, der quasi das Motorschütz bei NotAus verriegelt. Aber je nach PLr kann es vllt. notwendig sein eine Hardwareund eine Softwareverriegelung zu verwenden.

Aber der Sichere Teil ist nunmal der sichere Teil. Dort haben unsichere Signale bis auf Reset und Feedback nichts zu suchen. Das ist meine Meinung. Meiner Meinung nach steht das Siemens Beispiel entgegen dem Automatischen wiederanlauf. Da muss meiner Meinung nach zuerst der Sichere Teil wieder eingegliedert sein, also Netzschützein mit dem FDback, danach darf erst das Motorschütz gestartet werden.

Vielleicht bringt ja noch jemand anderes seine Meinung mit ein. Sicherheit ist ein sehr defiziles Thema. Du bekommst nichtmal genaue Antworten von deiner Berufsgenossenschaft. Allenfalls kannst du deine Anlage/Maschine vom TÜV abnehmen lassen wenn du es genau wissen willst. Aber gratis wirddas nicht

Ich erhebe keinen Anspruch auf Richtigkeit meiner Aussagen, es gibt nur meine Meinung wieder, wie ich es programmiere. Für TÜV hatte ich auch noch kein Geld

 

[Howard]

Moin,
also pauschal zu sagen, dass nicht sichere Eingänge/Variablen nicht in das F-Programm gehören, halte ich für nicht praktikabel. An meinen E-Stop-Bausteinen habe ich bspw auch einen Mix aus Sicher und "Unsicher" auf einem gelben UND-Baustein zusammengefasst. Es müssen also ALLE Signale, die sicheren wie die unsicheren OK sein um meinen E-Stop zu "entriegeln" und das einschalten zu ermöglichen.
Als Beispiel würde ich hier eine nicht sichere Spaltkontrolle an einem Regalbediengerät nennen, die halt nix mit Personenschutz zu tun hat, aber dennoch bei Auslösen unter der Fahrt für ein möglichst schnelles anhalten und abschalten des Gerätes sorgen soll. Die Spaltkontrollen wären samt der sicheren Signale wie Schutztüren, Notaus, Notendlagen usw "verundet" am EStop-Eingang für meinen SS1.
Um das ganze vielleicht ein wenig hübscher in die Safety-Welt zu integrieren, kann man natürlich sämtliche unsicheren Signale zunächst auf eine gelbe Variable umladen, und diese dann an seinen EStop-Bausteinen verschalten. Das ändert aber nix an dem Grundsätzlichen Mix. Wichtig ist ja nur, dass alle sicheren Abschaltfunktionen auch abschalten und nicht durch unsichere Variablen überbrückt werden können. Das erledigt in meinem Fall das gelbe UND.

 

[Credofire]

Moin,

naja, es gibt halt verschiedene Weisen zu programmieren.
Ich versuche immer den SafetyTeil, das ist bei mir der Personenschutz, vom Anlagenteil zu trennen. Deine Spaltkontrolle fällt nicht unter Personenschutz, also kann man das auch im unsicheren Teil genauso programmieren, das es wie von dir gewünscht reagiert.
Es gibt aber wie gesagt nicht DIE Lösung oder DIE Weise. Leider schade. Mit dem UND könntest du wohl recht haben, wenn du da unsichere Signale mit verwendest. Ich vermeide es aber. Ich baue in den Safety Teil nur das rein, was auch wirklich safety sein muss.
Alles andere kann man via DB nach aussen führen.
Unsichere Signale per DB gelb/sicher zu machen finde ich voll den falschen Ansatz. So machst du ein Signal sicher, was nicht sicher ist. Das kann dich in Teufels Küche bringen im Ernstfall. Das kann im schlimmsten Fall vielleicht einen Unterschied von fahrlässig zu grob fahrlässig ausmachen, wenn nicht sogar vorsätzlich.

 

[Wincctia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich sehe das so:

Schütz oder 2 Schütze die am sicheren Aussgang hängen werden zum normalen Prozessbetrieb und sicherheitsabschaltung verwendet.

Z.B. Motor von Fötech drehen lassen nach Anforderung also z.b inis oder Handbetrieb mit Inis und das sichere abschalten bei einen Not aus oder Schutztüre auf.

Hier haben natürlich unsichere Signale ihren Sinn im F Prog aber nur im Und und meiner Meinung nach wo es nicht schadet die Überwachungszeit würde ich höchstens mit Begrenzung vom Hmi Standardprogramm in das F Prog übertragen aber wer braucht das schon.

Diese Variante hat natürlich vor und Nachteile

vorteile
man Spart sich Schütze
man braucht weniger Platz
man Spart sich Stard Do
dadurch natürlich kosten


Nachteil

alle Schaltvorgäne auch im normalen Prozessbetrieb müssen in die Sicherheitsbetrachtung
dadurch muss das Schütz evtl regelmäßig getauscht werden

Z.b. 2


reine Notaus Schutztürfunktion bzw Schutztürefunktion,


hier haben unsichere Signale noch viel verloren im Estop Zweig, für was auch sieht natürlich beim Quit oder Feedback wieder anders aus.

Vorteile

evtl weniger F Ea notwendig ( macht doch irgendwann immer Ärger)
Sicherheitsbetrachtung an sich evtl einfacher weil nur Not aus und Schutztüre Schaltvorgänge relevant sind
evtl kosten Sparend weniger F Hardware notwendig

nachteil
natürlich nicht so Flexibel ( einrichten nur schwerer möglich)

So aber nun etwas was im Bereich Tia wirklich Elementar meiner Meinung Nach ist! Wie im Programmierleitfaden sind sämtliche Signale vom und zum F Programm über Koppel DB zu führen und NICHT auf irgendwelchen anderen DB zu nehmen denn wenn hier nur ein Symbol verändert wird will Tia das F laden im Stopp natürlich. Was nicht optimal ist.


Ps Verhalten tritt auch auf wenn nur der veränderte Baustein mit Teilübersetzen übersetzt wird weil dann übersetzt Tia den Rest beim Druck auf den Download Pfeil.


Gruß Tia

 

[Howard]

Ich glaube halt, dass es unter Umständen gar nicht anders geht als unsichere Signale zu verwenden und eine Applikation sogar sicherer machen kann. An einem Profisafe Antrieb kann ich, um ein sicheres Bremsen und Abschalten zu realisieren halt nur ein sicheres SS1 und STO-Bit senden und dann ggf. noch sicher ein Haupschütz absteuern. Und es gibt, je nach Applikation, eine menge unsicherer Signale, die dieses Abschaltprozedere einleiten sollten, auch wenn die Risikobewertung hier keine sicheren Bauteile vorschreibt. Mein Beispiel Spaltkontrolle: Es ragt etwas im Scherbereich heraus, das RBG wird nicht sicher abgeschaltet, das Regal wird beschädigt. Jetzt muss sich jemand in Gefahr bringen und das Regal auf 40m Höhe reparieren.
Nächstes Beispiel: Der Absolutwertgeber meldet Störung -> das RBG wird nicht sicher abgeschaltet, das Gerät saust in seinen Endanschlag, springt ggf aus den oberen Führungsrollen. Wieder muss sich jemand ggf in Gefahr bringen und das Gerät begutachten oder reparieren.
In solchen oder ähnlichen Fällen würde ich eher die Frage stellen, warum hier keine sichere Abschaltung erfolgte obwohl die Fehlfunktionen ja vom unsicheren Teil der Steuerung erkannt wurden?
Es lässt sich halt nicht jeder einzelne Sensor an jeder Maschine gelb ausführen und eine kompletter Maschinenablauf ins F-Programm verlegen
Deshalb kurz zusammengefasst: Alle Signale, ob sicher oder unsicher müssen OK sein (also UND) um ein sicheres Einschalten zu ermöglichen, aber irgendein Signal kann NOK sein (also ODER) um ein sicheres Ausschalten zu initiieren.

 

[Credofire]

...

die Überwachungszeit würde ich höchstens mit Begrenzung vom Hmi Standardprogramm in das F Prog übertragen aber wer braucht das schon.
...
Gruß Tia

Ich glaube nicht, dass es zulässig ist die Überwachungs- / Diskrepanzzeit am HMI zu verändern. Somit kannst du die ganze Sicherheit wieder aushebeln, indem du den Wert wahlweise sehr hoch setzt.

Ich habe eine Zeit lang nur mit der 1200er programmiert. Bei den F-Hardware sind das aber Elefanten im größentechnischen Sinne. Keine Ahnung warum Siemens die so groß gestaltet. Hier habe ich mit Wieland gute Erfahrung gemacht, da ist ein Netzwerkanschluss schon mit dabei. So bekommt man eine gute Querkommunikation zur SPS. Und die Baugröße ist gegen die 1200er F-Bausteine quasi mikrominiaturisiert

Mit dem Koppel-DB gebe ich dir recht. Nur bin ich der Meinung, dass man nicht unbedingt 2 braucht. Man hat halt den Nachteil, dass im nichtsicheren Teil die Variable nicht gelb hinterlegt ist.

Natürlich ist das ganze ja auch abhäng vom PLr. Je höher desto mehr Bauteile brauchst du meist auch, und kommst auch nicht drumrum.

Warum ist das Einrichten schwer möglich? Du kannst doch einen Einrichtemodus berücksichtigen, beispielsweise mit Totmanschalter und SafeLimitedSpeed o.ä.

In deinem ersten Beispiel musst du dann aber auch wirklich alle beteiligten Bausteine sicherheitstechnisch betrachten. Dann kannst du evntl. gar nicht den Endlagenschalter nehmen den du möchtest, weil der nicht als bewährtes Bauteil gilt und musst einen teureren nehmen. Wie du gesagt hast kann es dann notwendig sein die Schütze sehr oft zu tauschen. Das muss man sich dann ausrechnen was günstiger kommt. Und du hast evntl viele nichtsichere Signale, die du über sichere Eingänge ausgleichen musst. Hier kommt am Ende eventl dir hinterrücks das Platzproblem in die Quere, zB wenn du mit einer F1200er arbeitest und 2 F-DI Bausteine mehr brauchst. Die bauen schon einiges breiter als 2 Schütze.


@Howard
Du bringst aber Personensicherheit mit Anlagensicherheit durcheinander. Die Safety hat den Hintergrund Personen zu schützen und nicht Anlagenteile.
Wenn wie in deinem Fall etwas passiert, muss eben beor der Fehler abgestellt werden kann jemand den NotAus drücken. Schon ist deine Anlage im Sicheren Betrieb und jemand kann in den Gefahrenbereich. Am besten man hat dann NotAus System mit Schlöüsselschalter wo du den Schlüssel dann in der Tasche hast. Somit kann niemand anderes in der zwischenzeit die Anlage wieder in betrieb setzen.

 

[Wincctia]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Credofire,

da geb ich dir schon recht war auch ein für und wieder,
mit dem Einrichten heist es bei uns so es darf nur eine Funktion aktiv werden können und zwar im Bereich Personsensicherheit was halt heißt wenn ich z.B eine Gruppe von Antrieben mit Vorschützen die Leistung Wegschalte —> wieder fötech, so muss ich im einrichtbetrieb allen Antrieben auf ihre nicht Sichren Motorschütze oder Umrichter Leistung gegeben und im Fehlerfall könnte so eine Ungewollte Bewegung geben.

Gruß Tia

 

[Credofire]

Ich bin persönlich auch kein Freund von Arbeiten unter kritischen Bedingungen. Aber auch ich habe schon an Maschinen gearbeitet, wo der Einrichtbetrieb unsicher war. Wichtig dazu ist, dass man dann auf geschultes und genauestens instruiertes Personal zurückgreifen kann. Das beinhaltet natürlich auch eine Belehrung über eventuell im Einrichtbetrieb fehlenden Sicherheitsmaßnahmen. Es müssen dann temporär für den Einrichtbetrieb geeignete Maßnahmen (Abschranken o.ä.) ergriffen werden. Das Servicepersonal wurde dahingehend auch geschult.

Trotzdem werde ich bei meinem Stil bleiben und keine nichtsicheren mit sicheren Variablen im Safety verknüpfen. Das mache ich lieber im nichtsicheren Teil. Bisher hatte ich damit keine Probleme. Aber das scheint nunmal reine Philosophie zu sein. Bisher konnte mir keiner erschöpfend bestätigen, dass das so in Ordnung ist, aber auch nicht das Gegenteil. Wenn es irgendwann mal explizit in einer Norm steht, vielleicht mache ich es ja dann

 

[Howard]

Du bringst aber Personensicherheit mit Anlagensicherheit durcheinander. Die Safety hat den Hintergrund Personen zu schützen und nicht Anlagenteile.

und das ist der Punkt, niemand verbietet dir, auch die Anlage zu schützen.

Wenn wie in deinem Fall etwas passiert, muss eben bevor der Fehler abgestellt werden kann jemand den NotAus drücken.

aber es geht ja nicht darum wann der Fehler abgestellt ist, sondern in dem Moment wenn ein Fehler auftritt eine maximal schnelle und sichere Abschaltung zu gewährleisten auch wenn der Fehlergrund nicht aus einem sicheren Signal kommt.
Ganz allgemein kannst du deine Maschine mit 10 sicheren Signalen sicher abschalten
Ich kann meine mit 10 sicheren Signalen und 10 unsicheren sicher abschalten.
Ergo finde ich meine Variante sicherer

Aber verstehe mich nicht falsch. Ich möchte dich in deiner Programmierung nicht beirren oder belehren und sie ist auch auf keinen Fall falsch. Bei einer normalen Fördertechnik sammel ich auch nur sichere Signale wie Not-Aus auf.
Ich schalte nur gerade bei großen, schnellen oder teuren Maschinen lieber einmal zu oft, als einmal zu wenig sicher ab