Sonstiges Unsere Sicherheitsfachkraft will unsichere 16bit Kodierung mit Safety-SPS auswerten

Angsthase

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

ich bin Roboter-Programmierer, kein SPS-Programmierer. Im Safety-Bereich überschneiden sich aber immer öfters die Anforderungen. Deshalb suche ich hier in diesem Forum um Rat.

Wir haben einen Industrieroboter bei dem mehrere Greifer zum Einsatz kommen. Da der Durchschlagschutz des Schutzzauns im Worst Case nicht gegeben ist, kommt eine sichere Variante des Industrieroboters zum Einsatz.

Da die verschiedenen Greifer teils unterschiedliche Geometrien aufweisen, werden diese vermessen und in der Sicherheits-SW des Roboters als Räume verwaltet.
Da der Roboter keine eigene Sicherheits-SPS hat, muss eine externe Sicherheits-SPS (meist Siemens) der Robotersteuerung über sichere Eingänge mitteilen, welcher Greifer sich tatsächlich am Roboterflansch befindet. Das ist technisch soweit umgesetzt.

Das Problem ist aber: Wie bekommt die Sicherheits-SPS die Information, welcher Greifer sich tatsächlich am Roboterflansch befindet?
In der Regel kommt hier eine einfache 16bit Kodierung, die mit Kontakten abgefragt wird zum Einsatz, also:

Code:
0000 0001 = Greifer 1
0000 0010 = Greifer 2
0001 0000 = Greifer 16 u.s.w

Diese Kodierung ist nach meiner Meinung aber nicht "sicher". Das heißt, wenn z.B. ein Bit ausfällt, könnte ein anderer Greifer mit einer anderen Geometrie an die Robotersteuerung übermittelt werden. Dies könnte bei einem Worst Case fatale Folgen haben, die doch eigentlich mit der Sicherheits-SW abgesichert werden sollen.
Unsere Sicherheitsfachkraft ist hier aber anderer Meinung. Er möchte genau diese 16bit Kodierung mit der SSPS auswerten.

Meine Frage ist nun, ist das nach den Sicherheitsbestimmungen überhaupt erlaubt?

Nun, im Grunde geht es mich ja nichts an, Ich schreibe nicht das SPS-Programm und ich erstelle auch nicht die Risikobeurteilung in unserem Betrieb. Ich habe nur meine Bedenken zum Ausdruck gegeben.
Allerdings viel der Emailverkehr ziemlich „konstruktiv“ aus, was die Sache leider nicht einfacher macht. Deshalb hänge ich den Emailverkehr an das Posting an:

mail1a.png
mail11a.png

Dazu schrieb ich:
Im Prinzip möglich. Da habe ich aber ein Frage: Wie wird dann eine Fehlkodierung z.B. aufgrund eines Defektes verhindert?

Erläuterung:
1100 = 12
1101 = 13 -> 110X = 12

Letztes PIN hat kein Kontakt, es wird statt Code 13, Code 12 erkannt, somit der falsche Greifer.
Dazu kam folgende Mail von unserer Sicherheitsfachkraft:
mail2a.png

Dazu schrieb ich:
Doch genau dafür gibt es doch sichere Signale! Wenn wir diese nicht nehmen stellt sich für mich die Frage wie wir eben so eine Fehlkodierung verhindern, die du selber oben beschreibst.
Das würde doch sonst das ganze sichere System in Frage stellen. Entweder ist es "sicher" oder nicht. Und sollten die Greifer keine Gefahr darstellen, so brauchen wir auch keine sichere Software, oder?
Wenn du es so in der Risikobeurteilung verantworten kannst ist das deine Sache. Ich werde meine Bedenken aber auf dem Protokoll vermerken, das ich unterschreibe, wenn dem so sei.
Ich sehe es aber als meine Pflicht bedenken anzumelden.


Dazu kam wiederum folgende Mail von unserer Sicherheitsfachkraft:
mail3a.png

Was meint ihr dazu? Was würdet ihr als SPS-Programmierer tun, wenn ihr sowas projektieren oder programmieren müsstet?


Vielen Dank im Voraus
Martin
 
Zuletzt bearbeitet:
Eine Greifercodierung so zu gestalten, dass sie PLd entspricht, ist nicht ganz einfach.
Ich kenne kein Transponder / RFID-System für eine sichere Greifer-Codierung.
Wahrscheinlich würde ich das ganze über sichere Ini's von IFM und eine ET200S mit F-Baugruppen am Robi lösen.
Die Frage in dem Zusammenhang ist:
Wieviele Sicherheitszonen brauchst du wirklich?

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi!

Lass die Sicherheitsfachkraft die Risikobeurteilung machen und unterschreiben.
In der Risikobeurteilung ist durch die Bewertung festgehalten, welche PL zu erreichen sind und damit wie die Technik dann ausgeführt werden soll.

Ich verstehe deine Bedenken, aber im Prinzip machst du persönlich die Bewertung nicht, du setzt lediglich die Anforderungen der Risikobeurteilung um.


Gruß,

Ottmar
 
Hallo Dieter,

danke für die schnelle Antwort. Wir haben öfters über zehn Greifer für verschiedene Produkte, aber im Grunde dürften drei Zonen genügen, weil wir einige Greifer zusammenfassen können. Das ist aber nicht der Punkt.
Beim letzten Projekt habe wir den Greifer-Code und den Werkzeug-Code der Spritzgussmaschine bitweise in der SSPS verglichen. Nur wenn beide Codes identisch waren, wurde der Code von der SSPS ausgewertet.
Das wurde von unserer Sicherheits-Abteilung so genehmigt.

Das Problem ist nun aber, dass unsere neue Sicherheitsfachkraft es bei der Auswertung der "unsicheren" Kodierung belassen will, weil er dass für ausreichend hält, ich aber meine Bedenken habe. Und die Kommunikation ist schwierig, wie du bei den Emails oben sehen kannst. Da brauchen wir stichhaltige Argumente.
An Transponder / RFID-Systeme haben wir auch schon gedacht, diese sind aber nun vom Tisch, weil wir Programmierer das nicht zu entscheiden haben.

Deshalb meine Frage: Was würdet ihr als SPS-Programmierer tun, wenn ihr sowas projektieren oder programmieren müsstet?
Ist es OK wenn die Greifercodierung nicht PLd entspricht? Ist das Sache der Risikobeurteilung, kann es hier Ausnahmen geben?

Gruß, Martin
 
Zuletzt bearbeitet:
Hallo Ottmar,

danke für deine Antwort. So wollte ich es auch machen. Ich wollte aber dazu noch meine Bedenken äußern falls hier gegen eine grundlegende Verordnung verstoßen würde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi

Im Prinzip möglich. Da habe ich aber ein Frage: Wie wird dann eine Fehlkodierung z.B. aufgrund eines Defektes verhindert?

Erläuterung:
1100 = 12
1101 = 13 -> 110X = 12

Letztes PIN hat kein Kontakt, es wird statt Code 13, Code 12 erkannt, somit der falsche Greifer.

Die Lösung könnte sein:

Paritätsüberprüfung !

D.h. es muß IMMER eine Geradzahlige Anzahl der Nocken sein.
Bei 16 bit könntest du ein Paritätsbit verwenden.


Oder du verwendest mehrere Signale Paralell.

(Parität gerade)
P8421
00000 --> 0 --> O.K.
10001 --> 1 --> O.K.
10010 --> 2 --> O.K.
00011 --> 3 --> O.K.

oder Paralelbetrieb:

8421 8421
0000 0000 --> 0 --> O.K.
0001 0001 --> 1 --> O.K.
0010 0010 --> 2 --> O.K.
0011 0011 --> 3 --> O.K.
0010 0011 --> undefiniert/Fehlerhaft
 
Das Stichwort ist hier Hamming-Abstand. Der für eine sichere Übertragung erforderliche Hamming-Abstand kann durch verschiedene Verfahren erreicht werden. Ob ein einfaches Paritätsbit für deine Anforderungen ausreicht oder so etwas wie eine zyklische Redundanzprüfung (CRC) sein muss, musst du selber bewerten. Ich würde mich an den Werten von gängigen Sicherheitsprotokollen orientieren.
 
Hi,

wie währe es wenn du deine Greifer in 3 Greifergrößen sortierst.
Und nur die Baugröße über sichere Taktsignale "garantierst".
Bit 14=1 Bit 15=0 Bit16=0 Greifergröße 1
Bit 14=0 Bit 15=1 Bit16=0 Greifergröße 2
Bit 14=0 Bit 15=0 Bit16=1 Greifergröße 3
Alle anderen Bitkombinationen der Bits 14 bis 16 währen nicht erlaubt!
Das schränkt die anzahl der möglichen Codierungen ein, reicht aber bestimmt trotzdem noch dicke.

Taktleitung 1 Bit1 bis Bit13
Taktleitung 2 Bit14
Taktleitung 3 Bit15
Taktleitung 4 Bit16

Beim Pilz-PNOZ geht sowas (4 Taktsignale vorhanden). Bei Siemens sicherlich auch.

Nur so eine Idee ...... Denk mal drüber nach :cool:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hello,

es ist eine schwierige Frage ob die Greifercodierung sicher sein muss oder nicht. Für den Maschinenschutz würde in manchen Fällen eine 1-kanalige Auswertung reichen.
Es kenne zwar Schutzzäune die laut Hersteller einen Robi-Crash standhalten sollen, leider kann ein schlecht programmierter Roboter den gesamten Schutzzaun mit Verankerung ausreisen.

Du bekommst doch sicher von der SPS einen Befehl welcher Greifer genommen werden soll?? Die SPS muss nur noch den Sollgreifer mit der Codierung des aufgesetzten Greifers überprüfen. Stimmt diese überein, bekommt der Robi die Freigabe zum weiterfahren, ansonsten Stillstand und Störung. Dann muss so oder so der TE kommen. Zusätzlich kann noch überprüft werden ob alle 16bit auf 0 sind, wenn kein Greifer angeschlossen ist. Damit lässt sich überprüfen ob eine Kontakt fehlerhaft ist.

Das letzte Wort vor der Abnahme hat aber immer der TÜV.

MfG
 
Die Vorschläge sind ja alle soweit ok ... Nur:
Welchen davon könnt ihr sicherheitstechnisch bewerten / rechnen so dass ein Nachweis von PLd als Ergebnis rauskommt?

@Holgero:
Taktsignale ok ... Damit kann ein Querschluß ausgeschlossen werden.
Aber was ist mit Leitungsbruch?
Und dummerweise ist Leitungsbruch bei Robotern nicht unwahrscheinlich.
Greifer werden über meist über Werkzeugwechseleinrichtungen (Drehdurchführungen) angekoppelt.
Die elektrischen Signale werden dabei Schleifringe geführt ... und damit hatten wir auch schon sehr heftige Probleme.

Wenn man Platz hat (hat man nur leider zu selten), dann kann man überlegen sichere E/As direkt auf dem Greifer zu montieren und per Profisafe / ASI-Safe die Greifersignale zu übertragen.
So kann man eine sichere Übertragung vom Greifer bir zur SPS sicherstellen und hat keine Probleme mit dem Nachweis.

@Ottmar
Deine Argumentation krankt.
Für Roboter gibt es C-Normen.
Wie Angsthase schreibt, kommt hier ein Safe-Robot zum Einsatz.
Im Gegensatz zu normalen Robotern müssen hier die Schutzzäune einem Durchbrechen des Roboters nicht standhalten.
Die Absicherung der Zelle dient hier nur dem Personenschutz und muss einen Zutritt in den Gefahrenbereich verhindern.
Die definierten Schutzbereiche des Roboters INKLUSIVE WERKZEUG müssen dokumentiert und geprüft / validiert werden.
Hier kommst du als Roboterprogrammierer schon mal nicht raus aus der Verantwortung.
Sind unterschiedliche Schutzbereiche notwendig, so erfolgt dies über sichere Eingänge auf der Robotersterung.
All dies lernt man auf den Hersteller-Schulungen zu Safe-Robot.
Wenn du dagegen verstösst, dann kann das evtl. schon in Richtung grobe Fahrlässigkeit gehen.
Und da hilft dir eine Unterschrift einer Sicherheitsfachkraft nur wenig.
Ich kann persönlich Angsthase sehr gut verstehen.
 
Wird hier zu sehr nach der Devise "ich bin nicht Schuld" gedacht?
Oder hat nur jemand gelesen, es gibt Safe Steuerungen?

Ich würde mich auf die Risikobeuteilung zunächst verlassen.
Die Kollegen, die diese erstellen verstehen das Geschäft bzw sollten ihr Geschäft beherrschen.

Welche zusätzlichen Gefahren gehen von den verschiedenen Greifern aus?
Müssen die Greifer im Betrieb regelmäßig getauscht werden?
Gibt es keine Möglichkeit den Sicherheitsbereich so zu definieren, dass nichts passieren kann?
Man kann doch über einfache Plausabilitätsabfragen prüfen, ob der Greifer richtig eingewechselt wurde. :confused:
So machen wir es.

Ohne die Anlage zu sehen, würde und kann ich keine Beurteilung abgegeben.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
hier ist die DIN EN ISO 10218-2 anzuwenden, es ist durchaus möglich bei der Risikobeurteilung für diese Sicherheitsfunktion einen eigenen PLr zu definieren. Kommt halt drauf an was welches Risiko entsteht.
Die Problemlösung von Dieter, 3 Sensoren am Roboter und damit dann die 3 Werkzeugvarianten erkennen ist am besten. Das kann man eventuell auch mit 3 Standard Sensoren machen da man diese ja miteinander vergleichen kann, ähnlich wie bei einem Betriebsartenwahlschalter. Also eine mechanische Kodierung am Greifer einfach eine Nocke am richtigen Platz.
Damit ist bei durchaus ein PLd erreichbar, leichter wird das mit Sensoren die schon PLd haben, hat Dieter erwähnt.
Wenn die Werkzeuge immer am gleichen Platz sind wäre auch hier die Abfrage möglich, aber dann ist bei umsortieren usw. wieder ein Fehler möglich.
 
hier ist die DIN EN ISO 10218-2 anzuwenden, es ist durchaus möglich bei der Risikobeurteilung für diese Sicherheitsfunktion einen eigenen PLr zu definieren. Kommt halt drauf an was welches Risiko entsteht.

Das kann bei Robotern hilfreich sein.
Den verschiedenen Schutzzonen werden unterschiedliche PLd zugeordnet.
Du kannst z.B. zwischen Bedienseite und Rückseite unterscheiden oder ggf. Bereiche mit geringerer (sicherer) Geschwindigkeit fahren.
Man verlässt halt den "sicheren Hafen" der C-Norm.

Die Problemlösung von Dieter, 3 Sensoren am Roboter und damit dann die 3 Werkzeugvarianten erkennen ist am besten. Das kann man eventuell auch mit 3 Standard Sensoren machen da man diese ja miteinander vergleichen kann, ähnlich wie bei einem Betriebsartenwahlschalter. Also eine mechanische Kodierung am Greifer einfach eine Nocke am richtigen Platz.
Damit ist bei durchaus ein PLd erreichbar, leichter wird das mit Sensoren die schon PLd haben, hat Dieter erwähnt.

Standard-Sensoren würde ich nur verwenden, wenn ich sichere Eingänge nah an der Roboter-Hand hätte.
Für normale Ini's musst du doch einige Fehlerausschlüsse machen, wie wahrscheinlich sichere, getrennte Verlegung.
Und sowas ist bei nem Robi eher schwierig. Da ist der Weg über sichere Ini's einfacher realisierbar. Ich brauch einfach nur 3 Adern mehr im Steuerkabel.

Gruß
Dieter
 
Es wird so denke ich die Sicherheit ereicht, wenn
Der Greifer und dessen Ablageplatz eindeutig elektrisch und mechanisch codiert sind.
Ob das mit Safesensoren geschehen muss, sein dahingestellt.
Die zwei unabhängigen Kanäle sind in jedem Fall so gegeben.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Blockmove
Taktsignale ok ... Damit kann ein Querschluß ausgeschlossen werden.
Aber was ist mit Leitungsbruch?

Bei Leitungsbroch ist keins der Bits 14..16 vorhanden -> Fehler.


(
wie währe es wenn du deine Greifer in 3 Greifergrößen sortierst.
Und nur die Baugröße über sichere Taktsignale "garantierst".
Bit 14=1 Bit 15=0 Bit16=0 Greifergröße 1
Bit 14=0 Bit 15=1 Bit16=0 Greifergröße 2
Bit 14=0 Bit 15=0 Bit16=1 Greifergröße 3
Alle anderen Bitkombinationen der Bits 14 bis 16 währen nicht erlaubt!
Das schränkt die anzahl der möglichen Codierungen ein, reicht aber bestimmt trotzdem noch dicke.

Taktleitung 1 Bit1 bis Bit13
Taktleitung 2 Bit14
Taktleitung 3 Bit15
Taktleitung 4 Bit16

Beim Pilz-PNOZ geht sowas (4 Taktsignale vorhanden). Bei Siemens sicherlich auch.
)


Ich würde mich sogar auf 2 Taktsignale beschränken (Takt1 Bit1 bist Bit13 / Takt2 Bit14 bis Bit16).
Z.B. Querschluss zwischen Bit14 und Bit15 führt ja schon zu einer unzulässigen Codierung.

Somit würde man bei der PNOZ-Variante nicht alle 4 Taktsignale verplempern.
Eben weil die Leitungen zum Greifer irgend wann kaput gehen, kann man so die Taktignale des Greifers und die der übrigen Sicherheitskreise entkoppeln (erleichtert die Fehlersuche).

Naja. Ist nur ein Vorschlag. Und nicht unbedingt bis zu Ende gedacht.
 
Der Greifer und dessen Ablageplatz eindeutig elektrisch und mechanisch codiert sind.

Diese Lösung verwenden wir auch. Hat aber den Nachteil, dass du bei Neustart der Robotersteuerung eine Greifererkennung durchführen musst.
Dies kann auch recht aufwendig sein.
Wenn wir Werkzeuge ohne Pneumatik und Elektrik haben, dann verwenden wir auch einfach einen Werkzeug-Abfrageplatz.
Der Robi fährt bei Neustart / Typwechsel auf einen definierten Platz und dort werden Nocken bzw. Transponder des Werkzeugs durch Sensoren bzw. Lesesystem abgefragt.
Wenn man entsprechend Platz hat, ist dies meist die einfachste Lösung.
In Verbindung mit Sicherheitstechnik haben wir diese Lösung bislang noch nicht verwendet.

Gruß
Dieter
 
Also wwer schaltet denn überhaupt aus? :ROFLMAO:

Für diesen Fall haben wir eine Init Routine. da wird eine bestimmt Postiton angefahren und dort kann eindeutig der Greifer indentifiziert werden.
Bei manchen Wechselgreifern wird auch ein anderer Slave aktiviert, da hast du dann dreifache Sicherheit. ;-)

Wobei eines klar ist:
100% Sicherheit gibt es nicht und muss auch nicht sein.
Man kann und muss sich auf die Bediener verlassen und die sind meist besser als wir es ihnen zutrauen.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die entscheidenden Fragen sind:
Hierbei wird von einem automatischen Wechsel ausgegangen.
Was kann passieren, beim Wechsel zwischen großen und kleinen Endeffektor können sich die Arbeitsbereiche erheblich verändern so dass es eine Gefahr ist, das muss man anhand eines Layouts und dem Bewegungsbereich bewerten.
Kann der Endeffektor sich lösen, wegfliegende Teile.
Können sich bei falschen Endeffektor Teile lösen, wegfliegende Teile.
Kann es zu Bruch von Maschinenteilen kommen, dadurch dann zu Gefahren werden.
Je nachdem ist dann ein Risiko vorhanden und dies ist dann wenn es sich um eine Steuerungstechnische Maßnahme handelt eine Sicherheitsfunktion. Aber es muss nicht immer Steuerung sein. Schutzzäune die hoch genug sind oder eben auch mechanische Verriegelungen usw. sind möglich. Die Norm lässt da einiges zu. Man muss auch verstehen das es Kombinationen von Risikominderungsmaßnahmen geben kann, z.B. eine bestimmte Höhe nicht überfahren, Schutzzaun hoch und stabil genug und dann kann die Abfrage des Endeffektors schon weniger sicher sein.
Zurück zu dem Problem, welche Gefahren nun vorliegen muss die RB zeigen, aber hier wurden schon gute Ansätze aufgezeigt. Wenn es eine höhere Gefahr darstellt dann ist die drei Sensor Lösung am einfachsten und die Fragen den Endeffektor dauerhaft ab. Das Abfragen an einer Kodierungstelle ist auch nicht schlecht hat aber bestimmte Nachteile die Dieter auch schon angesprochen hat.
Es gibt einen Sicherheitsschalter von Pilz der drei verschiedene Transponder unterscheidet und je nach dem die OSSD Ausgänge schaltet. Kann PLc denke das wäre auch ein Ansatz. PSENcs 3.19
 
Hallo,

vielen Dank für Eure vielen Antworten.
Nun es ist so, dass wir schon einige Ideen haben die auch plausibel erscheinen. Auch haben wir einige Möglichkeiten die Greifer plausibel abzufragen, damit ein Drahtbruch nicht zu einen Worst Case führen kann. Technisch sehe ich da keine Probleme.
Hat aber alles keinen Sinn weil unserer SiFa hier anderer Meinung ist.
Einige können wir selber verwirklichen, wenn wir die Kodierungsverdrahtung selber bestimmen können. Die Idee von gravieren mit der Paritätsüberprüfung könnte uns hier auch sehr nützlich sein. Doch oft gibt es der Kunde vor.

Wie schon geschrieben kommt ein sicherer Roboter zum Einsatz und es müssen verschiedene Greiferräume berücksichtigt werden. Der Grund, der Roboter könnte im Worst Case mit einem seiner Greifer den Schutzzaun durchschlagen und den Werker treffen der dahinter arbeitet.
Dass wir so eine Absicherung brauchen steht ja schon von vorn hinein fest, sonst hätten wir ja nicht für tausende Euros diese sichere Option bestellt. Es geht natürlich nicht bloß um Maschinensicherheit, dann dafür brauchen wir diese Option nicht!

Habe mal folgendes Bild aus dem bgi5123.pdf hier angehängt:
safe1a.png

Es geht hier um den rot eingezeichneten Arbeitsplatz der mit der Sicheren SW zu schützen ist.

– ein ausreichender Abstand des Roboters zur Umzäunung,
[Leider nicht vorhanden]

– mechanische Anschläge (Puffer),
[Nein, weil nur schwer möglich und außerdem durch Sichere SW ersetzt]

– eine ausreichende Festigkeit der Umzäunung,
[Nein, im Regelfall nicht gegeben]

– eine sicher überwachte Robotersteuerung,
[Ja, kommt zum Einsatz]

– sichere kontaktbehaftete oder elektronische Achsnocken,
[Nein, weil nur schwer möglich und außerdem durch Sichere SW ersetzt]

– innen angeordnete Lichtschranken bzw. -vorhänge.
[Nein, weil durch Sichere SW ersetzt, wäre aber auch eine der Lösungen]

Was kann passieren, beim Wechsel zwischen großen und kleinen Endeffektor können sich die Arbeitsbereiche erheblich verändern so dass es eine Gefahr ist, das muss man anhand eines Layouts und dem Bewegungsbereich bewerten.
Genau darum geht es!
Die Information welcher Endeffektor (groß oder klein) sich im Roboter befindet möchte unserer SiFa über die unsicheren Kodierungseingänge auswerten.
Wenn es nun zu einem Drahtbruch in der Kodierung käme, kann doch die Sicherheit dieses Arbeitsplatzes nicht mehr gewährleistet werden, weil dann der falsche Werkzeugraum in der Sicherheits-SW aktiviert werden würde? Also ich kann mir nicht vorstellen, dass es erlaubt ist in einem durchdachten sicheren System, sicherheitsrelevante Information unsicher zu verarbeiten!

hier ist die DIN EN ISO 10218-2 anzuwenden, es ist durchaus möglich bei der Risikobeurteilung für diese Sicherheitsfunktion einen eigenen PLr zu definieren. Kommt halt drauf an was welches Risiko entsteht.
Gibt es konkrete Richtlinien bei der die Verwendung von unsicheren Signalen in einem sicheren System zulässig sind?

Das letzte Wort vor der Abnahme hat aber immer der TÜV.
TÜV???


Gruß, Martin
 
Zuletzt bearbeitet:
Nur mal so nebenbei - welchen Roboter setzt ihr eigentlich ein?
Fanuc kann ja sehr gut mit Sicherheitsbereichen umgehen. Aber was Fanuc kann, können ja andere mittler Weile bestimmt auch.
 
Zurück
Oben