Vorschläge für Sicherheitsantriebe

SF_SafetyRequest für die Aktivierung und Überwachung der Antriebsfunktionen

In PLCopen Safety Part 1 ist der Funktionsblock SF_SafetyRequest, wie in Abbildung 4 graphisch dargestellt, definiert. Die Beschreibung von SF_SafeRequest in Abbildung 5 bietet einen grundlegenden Überblick über die Funktionalitäten. Die Hauptein- und ausgaben des SF_SafetyRequest sollten wie folgt verlinkt werden:

• Oben links (Activation through safety logic): Eingang S_OpMode ist mit der Logik verbunden und bestimmt, ob die Safety-Drive-Funktion (z.B. sicherheitsbegrenzter Torque) innerhalb der in der Input-MonitoringTime (nicht gezeigt) spezifizierten Zeit aktiv werden muss. Dabei kann es sich um den Ausgabewert eines FB handeln, der ein Gerät überwacht (z.B. SF_ESPE überwacht ein Lichtgitter oder SF_ModeSelector überwacht ein modusbestimmendes Gerät), oder eine Kombination von Zuständen.
• Oben rechts (Further use in safety logic): Ausgabe S_SafetyActive gibt Feedback, ob die Safety-Drive-Funktion innerhalb der spezifizierten Monitoring-Zeit aktiv geworden ist, nachdem der Bedarf determiniert wurde (Input S_OpMode). Wenn diese Ausgabe aktiv ist, kann sie dazu genutzt werden, die nächsten Schritte einzuleiten, z.B. das Öffnen eines Tors.
• Unten links (Bit in drive’s status word): Eingabe S_Acknowledge gibt den für die Safety-Drive-Funktion relevanten Antriebsstatus wieder, wie er vom FB angefordert wurde (z.B. ob die Begrenzung des Torques momentan aktiv ist), und ist das Abbild des Prozesseingabebildes in Bezug zum Antrieb.
• Unten rechts (Bit in drive’s control word): Ausgabe S_SafetyRequested ist das Bit, welches zum Antrieb im sicheren Steuerwort geht, um die Funktionen im Antrieb zu aktivieren. Beachten Sie, dass es sich beim Steuerwort um einen Byte handeln und der Antrieb eine Safe Logic sein kann.

Ist die Eingabe S_OpMode ‚FALSE‘, gibt es keine Aktivierung, also ist die Ausgabe S_SafetyActive ‚FALSE‘. Gibt es jedoch eine Sicherheitsnachfrage und die Eingabe S_OpMode ist ‚TRUE‘, zeigt die Ausgabe S_SafetyActive den Status des Antriebes oder seine Überschreitung der Überwachungszeit an. Der Bit/Teil S_SafetyRequest spiegelt den Betrieb durch Aktivierung des relevanten Sicherheits-Bits im Steuerwort wider. Nach der Aktivierungsbestätigung im Sicherheitsantrieb zeigt die Eingabe S_Acknowledge diese Veränderung als ‚TRUE‘ an. Diese SF_SafetyRequest-Funktionalität kann in einem weitreichenden Sicherheits-Verständnis genutzt werden, inklusive der Safe-Motion-Funktionalitäten. Beispielsweise, um dieses FB für SLT (Safely Limited Torque) zu nutzen, kann man die Eingaben Axis2SLT_noNeed und Axis2SLT_fdbk kombinieren, um die relevanten Sicherheitsausgaben Axis2SLT_Active und Axis2SLT_ctrl zu generieren, was die benötigten Sicherheitsfunktionalitäten gewährleistet. Mehrere Instanzen von SF_SafetyRequst können dazu benutzt werden, alle Safety-Drive-Funktionen abzudecken (IEC61800, Profiles, Anbieter-spezifisch). Auf diese Art und Weise können die meisten Funktionalitäten des Sicherheitsantriebes einfach abgebildet werden, besonders durch das Bereitstellen einer ‚Guideline‘. Dieser Leitfaden sollte ein generisches Schema enthalten, wie Signale in Bezug auf ihre vom Sicherheitsantrieb unterstützten Funktionen (siehe unten) benannt werden. Kombiniert mit einem E/A- oder Antriebs-Konfigurator können diese Bezeichnungen automatisch für die Bits im Antriebsstatus/ Steuerwort generiert werden – passend zum Antriebsprofil (symbolische Namen/Bezeichnungen). Dadurch bietet PLCopen all diese SafeMotion-Funktionen, während es mehrere Instanzen der selben Funktion auf dem selben Antrieb abdeckt, z.B. zweimal SLS mit verschiedenen Geschwindigkeiten. Und es erlaubt der Applikation in Antrieben, die diese Funktionen unterstützen, zwischen der Aktivierung von SS1 und der Aktivierung von STO zu unterscheiden, genauso wie zwischen der Aktivierung von SS2 und der von SOS. (Beachten Sie, dass der spezielle PLCopen FB SF_SafeStop1 nicht die Aktivierung von SS1 garantiert, aber abhängig vom Antrieb STO aktivieren könnte, und SF_SafeStop2 keine Aktivierung von SS2 garantiert, sondern SOS aktivieren könnte. Die Applikation kann im momentanen Zustand nicht auswählen, welche Funktion sie aktivieren soll.) Auch für den Lieferanten wird der Zertifizierungsprozess wesentlich einfacher, während der Anwender ein gleichbleibendes User Interface erhält, das alle benötigten Funktionen abdeckt und sogar die selben Funktionalitäten einfach gruppieren kann, um einen besseren Überblick über das Safety Application-Programm zu gewährleisten.

Das Sicherheitsantrieb-Benennungsschema

Um ein einheitliches Interface zu haben, wird das Bennenungsschema aus Abbildung 6 benötigt. Für jeden vom Antrieb passend zu seinem Profil und seiner Konfiguration unterstützten Sicherheitsantrieb d und jede Sicherheitsantriebs-Funktion f sollten die zugehörigen FB-Instanzen und E/A-Signale gemäß des Benennungsschemas aus Abbildung 6 erhalten.

Anzeige

Intralogistik: Neue Baumer ToF-Sensoren machen sich klein

In der Intralogistik ist die Maximierung der Lagerkapazität entscheidend. Kompakte Sensoren spielen dabei eine Schlüsselrolle: Höchste Leistung in kompakter Bauform schafft mehr Platz für die Ware, denn die Technik macht sich klein. ‣ weiterlesen

Zur Erläuterung:

‚d‘ steht für den in der Applikation vergebenen Namen des Sicherheitsantriebs (z.B. ‚MyAxis‘);

‚f‘ ist das Akronym für die Sicherheitsantriebs-Funktion; Für gängige Sicherheitsantriebs-Funktionen sollten folgende Akronyme benutzt werden: f { STO, SS1, SS2, SOS, SBC, SLA, SLI, SLP, SLS, SLT, SAR, SSR, STR, SDI, SEL, SCA, SSM, SMT };

Anzeige

Automatisierung neu gedacht

Digitale Souveränität in der Automation: Fraunhofer IOSB-INA entwickelt einen KI-Assistenten für die SPS-Programmierung. ‣ weiterlesen

‚k‘ ist die Anzahl an Instanzen der Sicherheitsantriebs-Funktion (wenn der Antrieb so konfiguriert ist, dass mehrere Instanzen von der selben Antriebsinstanz verwendet werden)

Beispiel: Bei einem CIP-safety-on-Sercos-Antrieb ‚MyAxis‘ ist die Safe Motion Monitoring-Funktion #1 als sicher begrenzte Geschwindigkeitsfunktion konfiguriert. Dann sollte die funktionsanzeigende SF_SafetyRequest-Instanz auf dem MyAxis die Bezeichnung ‚MyAxisSLS_Mon‘ bekommen, Bit #2 des MyAxis-Statuswortes im Eingangsabbild sollte den symbolischen Namen ‚MyAxisSLS_fdbk‘ bekommen und Bit #3 des MyAxis-Steuerwortes im Ausgangsabbild sollte den symbolischen Namen ‚MyAxisSLS_ctrl‘ bekommen. Wollen wir als Beispiel die Safe-Torque-Off-Funktionalität abbilden, ist es das erste Bit sowohl in der Steuerung als auch dem Status-Byte. Nutzen wir für dieses Beispiel Axis 2, könnte die Implementierung von SF_SafetyRequest wie in Abbildung 7 aussehen.

Mehr Informationen finden Interessierte auf www.PLCopen.org. Die Spezifizierung ist ebenfalls als Download verfügbar unter www.plcopen.org.

Seiten: 1 2