TIA Safety: Sichere Erfassung einer Walzendrehzahl über Inkrementalgeber

NBerger

Level-3
Beiträge
1.390
Reaktionspunkte
387
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,
Hab da mal ein Problem:
Die Drehzahl einer Walze soll sicher erfasst werden. Antrieb der Walze erfolgt über einen Servoantrieb mit Profinet aber es ist kein Profi-Save möglich.
Ansatz ist nun einen 2. Geber anzubauen (Profinet). Diese ist dann aber auch nur ein "normaler" Geber.
CPU 1515F TIA 15.1
Frage: Reicht es die Gebersignale (Profinet) beider Geber (Externer und Motorgeber) im Safety-Teil zu verarbeiten und gegeneinander auf Sinnhaftigkeit zu prüfen oder ist da mehr notwendig?
 
Hallo NBerger,

ich bin kein Safety Crack, aber ich denke, dass das so nicht reicht um die Safety Norm Konform zu verwenden. ABER sicherer ist immer besser. Der zweite Geber erhöht also die Sicherheit. Der unwahrscheinliche Fall, dass beide Geber gleichzeitig ausfallen wird halt nicht erfasst. Letztendlich müsst ihr ja unterschreiben (und dafür haften) dass die Maschine sicher ist. Vermutlich bricht hier gleich wieder eine Diskussion aus.. ;)

Ist denn wirklich keine Safety Extended Funktion für den Servo möglich? SS1 etc. wäre natürlich die schönere (und TÜV zertifizierte) Lösung...

Gruß Christian
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi...,
Ist denn wirklich keine Safety Extended Funktion für den Servo möglich? SS1 etc. wäre natürlich die schönere (und TÜV zertifizierte) Lösung...

Das ist ja das blöde. Der Umrichter wird zwar über STO abgeschltet, im Not-Halt Fall, aber für die zusätzliche Safetyfunktion soll er weiterlaufen. Lediglich der Speed darf in diesem Fall nicht über ein vorgegebenes Limit gehen.
 
Moin,
das was du suchst nennt sich ja SLS - safety limit speed. In der Regel haben die Antriebshersteller dafür Lösungen im Portfolio (bspw. bei SEW via UCS usw.)
 
das was du suchst nennt sich ja SLS - safety limit speed. In der Regel haben die Antriebshersteller dafür Lösungen im Portfolio (bspw. bei SEW via UCS usw.)

Ja, ist bekannt. Das kann der FU nicht. (Und ich sage hier nicht, was das für ein spuddeliger Herstelller ist)

Vielleicht ist ein anderer Weg besser:
- keine F-CPU
- Von Siemens das Drehzahlüberwachungsgerät verbauen mit Inkrementalgeber
- Safetylogik in Hardwareverdrahtung

So kompliziert wird das glaube ich nicht.
Es sei denn hier hat noch einer eine Idee wie ein Geber Safetykonform eingebunden werden kann (mit Analogwerten geht sowas ja auch).
 
Es gibt von der Firma TR-Electronic einen geber mit Profisafe.
Such mal nach K-CDV75-PN-1
Den könntest du zur Überwachung einsetzen.

Als andere Möglichkeit gibt es von Siemens ein Drehzahlüberwachungsrelais welches auch für SLS geeignet ist.
Es ist ein 3TK2810-1
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich frage mich ehrlich gesagt, ob dir SLS überhaupt reicht. Denn wenn du den Antrieb einfach abschaltest (STO Verhalten), dann kann es ja sein, dass deine Walze noch lange austrudelt. Mit SS1 würde der Antrieb ja runtergerampt und es käme nicht zu eventuell unkontrolliertem Austrudeln.
 
Die Walzen drehen schon extrem langsam. Max. 2 U/min Min. 1U/h >> Hohe Getriebeuntersetzung; Eigenhemmung ... passt schon.
Werden nun auch Plan B favorisieren...
 
Ich bin jetzt nicht der 100% ige Safety Papst, aber das geht durchaus mit 2 normalen Gebern.
durch 2 Geber am besten unterschiedliche hat man schon mal Diversität, dann kann man noch ne Diagnose bauen. Bringen beide Geber den gleichen Speed ? Ansonsten Fehler und stop. Usw.. muss man halt validieren welcher pl erreicht wird. Ansonsten bietet Pilz das s30 an. Aber auch hier muss der pl validiert werden. Welcher pl ist denn gefordert ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Fa. Siemens hat eine Applikation für Deinen Fall.
Man braucht nur eine F-CPU und einen sicheren T&R Geber, der Rest ist Software.
Sieh mal hier.
Ist zwar für Classic, das Prinzip sollte sich aber auf TIA übertragen lassen.

Gruß
Erich
 
Die Fa. Siemens hat eine Applikation für Deinen Fall.
Man braucht nur eine F-CPU und einen sicheren T&R Geber, der Rest ist Software.
Sieh mal hier.
dabei handelt es sich aber wieder um einen sicheren (F-)Geber - dem TE ging es aber eher um zwei unsichere Geber.

Das was mitchih schreibt, deckt sich mit meinem Post #6 - und sollte das Problem vom TE eigentlich lösen.
 
Zurück
Oben