TIA Optionshandling + F-SPS

Hallo Zusammen,

ich bin gerade dabei mal wieder unser SPS-Konzept über den Haufen zu... ähm ...zu optimieren!

Ich habe hier folgendes Szenario:

1x ET200SP F-CPU + paar EA Module u.a. F-DI und F-DQ.

Drei Profinet Slaves:

1x Kuka Roboter (+ Profisafe)
1x Fanuc Roboter (+ Profisafe)
1x Mitsubishi Roboter (kein Profisafe)

Es ist immer nur einer der Roboter in der Roboterzelle verbaut.
(Für mehr ist auch gar kein Platz )

Was ich nun mache ist Folgendes:

1. Ich habe den Maximalausbau der ET200SP + alle drei PN-Slaves im Projekt
2. Ich lasse bei Initialisierung den Vollausbau aktiv und warte welcher PN-Slave online kommt.
3. Dann deaktiviere ich die zwei anderen mit dem SFC12
4. Aktiviere ich eine passende Konfiguration für die ET200SP, da je nach Roboter noch F-RQ Module gesetzt werden

Das habe ich nun soweit zufriedenstellend im Griff!

Jetzt geht es an das Safety-Programm. Da ich ja jetzt ein so schönes Optionshandling habe was meine Hardware angeht,
wäre es jetzt eine Schande das Safety-SPS Programm jedesmal anpassen zu müssen.

Daher ist mein Plan wie folgt:

Not-Halt + Bedienerschutz-Signale werden immer an alle Roboter gesendet (via Profisafe, oder via F-DQ an die F-RQ)

Not-Halt Signale von den Robotern werden verodert auf die Auswertungsbausteine geführt.
Da nur ein Not-Halt-Signal aktiv sein kann sollte hier eine passende Funktion gegeben sein.
Ich habe hier nur ein bisschen "Bauchschmerzen" wegen einer Kleinigkeit:
Eines der Not-Halt-OK Signal von einem Roboter kommt via F-DI auf die ET200SP.
Hier besteht die Gefahr, dass jemand eine Drahtbrücke setzt oder etwas anschließt und
somit den anderen Not-Halt überbrückt. Auf der anderen Seite ist dies auch mit jeder
anderen Not-Halt-Funktion ohne weiteres möglich! Also eigentlich zu paranoid gedacht.

Mein Ansatz wäre also auch darauf auszuwerten, dass wirklich nur ein Not-Halt-OK
Signal ansteht. Seht ihr damit meine Bedenken ausgeräumt oder habe ich noch etwas
übersehen?

Freue mich auf euer Feedback!

Grüße

Marcel

Hallo Marcel,

interessanter Ansatz. Ich wusste nicht dass man zur Laufzeit auch die Konfiguration einer CPU ändern kann (Dein Schritt 4). Dachte dies ist nur bei IO-Devices möglich.

Um die Manipulationsmöglichkeiten zu reduzieren, könntest Du dir deine gewählte Hardware-Config in einem Bit merken(Variante 1, 2 oder 3). Dieses Bit dann jeweils mit dem dazugehörigen Not-Halt-Signal verunden. Das Not-Halt-Signal kommt somit nur zum Zuge wenn die Konfig auch aktiv ist.
Das von Dir angedachte verodern ist eine gute zusätzliche Massnahme.

Eine weitere Alternative wäre den Mitsubishi Robi mit einem eigenen ET200SP Interface und F-DI/F-DO auszustatten. Alle drei Varianten würden dann via Pofisafe kommunizieren. Aber wie immer wird dies vermutlich das Budget sprengen.

Grüße

Peter

Hallo Marcel,
dein Ansatz hört sich wirklich interessant an - ich muss dir allerdings sagen, dass ich, wenn ich für die Instandhaltung bei deinem Kunden zuständig wäre, dies so nicht akzeptieren würde. Welcher IH-ler, egal, wie gut er ausgebildet ist, soll denn nach ein paar Monaten noch wissen, dass 2 von deinen Robbi-Slaves eigentlich nur Dummies im Projekt sind - in der HW-Konfig stehen sie ja immerhin noch drin ...
Was spricht denn dagegen, hier ein Template-Projekt zu haben, in dem von mir aus die Robbi's erstmal drin sind und die nicht verwendeten dann herausgelöscht werden ?
Genauso könnt man mit Hantierungsbausteinen (sogar auf der F-Seite) verfahren. Dann kommst du sogar aus der Nummer raus, dass jemand irgendwann deine Reserve-IO's fehl-interpretiert (se sind ja dann gar nicht da ...).

Gruß
Larry

Hallo ihr Zwei,

Danke für eure Antworten!

Das mit dem Bit welche Config aktiv ist könnte man als zusatz noch einbringen - kommt zwar aus dem nicht sicheren Programmteil, aber besser als nichts zu machen ist es schon.

Die Bedenken aus der Instandhaltung kann ich nachvollziehen - da es sich aber um eine Serienmaschine handelt die mit Passwort und Co geschützt ist haben nur wir auf diese Zugriff.
(Und ja, es gibt Kunden die es kaufen... die Grundsatzdiskussion verkneife ich mir hier mal).

Sollte man es dennoch in Betracht ziehen sollte für die Meisten schnell ersichtlich sein warum ein Slave fehlt.
Zum einen heißen Sie Kuka, Fanuc und Co -> Wenn nun jemand den Roboter anguckt sollte er merken welcher der passende ist
Außerdem sieht man in der HW-Config wenn ein PN-Teilnehmer deaktiviert wurde.

Edit:

Der Grund gegen das Template: So schaffe ich gerade. Es macht halt viel Arbeit! Ich muss den PN-Slave löschen, die Verwendung im Programm (Weil ich mit DP_READ usw. arbeite und die Verweise auf die HW-Konstanten dann fehlen),
und die Verwendung im sicheren Programm löschen muss. Außerdem ändert sich dann jedesmal die Sicherheitssignatur, und das ganze ist einfach Fehleranfällig bzw. man vergisst halt schnell mal was.
Daher der o.g. Ansatz!

Und ja: Ein eigener PN-Knoten sprengt das Budget...

Grüße

Marcel

Ich wollte auch keine Grundsatzdiskussion anstossen ... obwohl dieses Thema zweifelsfrei das Potential dazu hat.
Lediglich wollte ich dir aber meine Meinung nicht vorenthalten. Ich habe etwas in diesem Range so noch nicht gemacht, bin mir aber sehr sicher, dass sich das mit nur geringem Aufwand so, wie von mir geschrieben umsetzen liesse. Mir wäre es tatsächlich nur um Löschen der jeweils nicht benötigten Aufrufe / Bausteine gegangen ... und natürlich muss dann das F-Programm neu generiert werden - aber einmal muss es das ja sowieso ...

Gruß
Larry

Hallo Marcel,
ich bin mit deinem Vorgehen auch eher Konform.
Wie währe es den, wenn du in der Steuerung eine Logik einbauen würdest, wenn die Konfiguration
der Maschine geändert wird, muss die Sicherheitssensoren betätigt und wieder quittiert werden.
Als Beispiel, du hast mehrer Not-Halt Taster in der Anlage, die Montiert werden oder auch nicht.

Hast du jetzt Konfiguriert es sollen 2 sein, dann zeigst du das am Bildschirm an:
"Maschine ist für den Betrieb mit 2 Not-Halt Taster" Konfiguriert.
Als nächstes kommen folgende Meldungen (wie auch immer)

1. Drücken Sie Not-Halt Taster 1.
2. Ziehen Sie Not-Halt Taster 1.
3. Drücken Sie Not-Halt Taster 2.
4. Ziehen Sie Not-Halt Taster 2.
5. Maschine ist für den Betrieb mit 2 Not-Halt Tastern Konfiguriert.

Meldung 5 könntest du dann auch bei jedem Systemstart anzeigen.

So hättest du dann auch die Sicherheit das niemand mal eben einen Not-Halt
Taster überbrückt hat.

Worüber man auch nachdenken kann, ist die Konfiguration über ein paar Eingänge
weinetwegen 4, Binär Hard verdrahten lassen. Mir Persönlich währe die Konfiguration
im Sicherheitsbereich nur über Berdienung mit Passwort zu riskant.

Hallo Zusammen,

@Larry: Nicht falsch verstehen. Ich unterstelle Dir nicht das Du Grundsatzdiskussionen anstößt - ich wollte dies nur vorweg "unterbinden" da es hier einige gibt die das gern machen

@RN: Netter Ansatz, aber knapp daneben.

Es geht nicht um die Anzahl der NH-Taster, sondern darum, dass es 3 Quellen für das NH-OK Signal gibt, und immer nur eine aktiv ist.
Das sind: F-DI auf der ET200SP -> Not-Halt OK von Mitsubishi, F-DI via Profisafe direkt von Kuka, und F-DI via Profisafe direkt vom Fanuc Roboter.
Mein Plan wäre somit ganz grob:

Not-Halt-von-Roboter-OK := NH_Taster_Mitsubishi OR NH_Taster_Kuka OR NH_Taster_Fanuc;

Rein technisch kann nur ein Signal da sein -> Somit ist meine Funktion OK. Wenn nun aber jemand den F-DI auf der ET200SP brückt oder noch irgendwo nen zweiten
passend konfigurierten Roboter organisiert (recht unwarscheinlich) wäre mein Konstrukt "überbrückt". Deshalb eine Auswertung, dass nur ein Signal aktiv ist. Wenn mehr als ein Signal kommt -> Not-Halt nicht OK -> Sicherer Zustand.

Die Konfiguration passiert vollautomatisch! Die Steuerung fährt im Vollausbau hoch -> Es wird einer der drei Profinet-Teilnehmer gefunden -> die anderen beiden werden deaktiviert und die Konfig wird angepasst.
Ich sehe hier Sicherheitstechnisch absolut keinen Unterschied -> und wollte dies nur nochmal einer externen Meinung unterziehen.

Grüße

Marcel

Marcel, das war doch nur ein Beispiel, ob es jetzt eine Auswahl von 3 ist oder
1 bis 3, du musst doch nur gewährleisten das der richtige Not-Halt für den entsprechenden
Roboter kommt. Das Beispiel ist ja nur um eine Kontrollfunktion zu schaffen, das
alles richtig verklemmt ist.
Dein Verknüpfung gefällt mir schon mal garnicht, ich würde die Not-Halt Signale als
'UND' verknüpfen, die nicht belegten Signale müssen dann gebrückt werden.
Wie man das man mit Profisafe Signale macht habe ich noch keine Idee.

Okay dann haben wir nur ein wenig aneinander vorbei geredet.

Genau wegen dem OR statt AND hab ich ja hier geschrieben
Aus dem Bauchgefühl ist ein ODER in nem Safety-Programm immer etwas... heikel.

Ich denke mit folgender Logik wäre es Safe:

Not-Halt-OK := ((NH1_OK AND NOT NH2_OK AND NOT NH3_OK) OR (NOT NH1_OK AND NH2_OK AND NOT NH3_OK) OR (NOT NH1_OK AND NOT NH2_OK AND NH3_OK));
(Ja ich weiß, es gibt XOR -> Will es aber so simpel wie möglich halten und gut dokumentieren)

Die anderen Not-Halt-Taster der Anlage sind natürlich mit einem AND verknüpft.

Aufgrund der HW-Konstelation und der o.g. Abfrage dürfte alles so funktionieren wie geplant.

@Larry: Das Ziel ist es einen Stand für die Serienmaschine zu haben den man einspielt und es tut.
Das widerspricht der Lösch-Orgie bei der Erstellung. Und drei Stände pflegen macht auch wenig Spaß.
Ja bis dahin ist es ein weiter weg, und es wird auch immer was anzupassen geben.

Und als entschärfung: Das ganze ist mal eine kleine Studie von mir... das ganze geht jetzt noch
nicht ins echte Leben. Vorher kommt der ganze Spaß mit Risikobeurteilung usw. Und natürlich
wird auch bei jeder IBN die Funktion der Sicherheitseinrichtungen getestet...

Grüße

Marcel

Mir gefällt dieses automatische/selbständige Soft-Umkonfigurieren einer F-SPS nicht. Vor allem, weil die Umkonfiguration im nicht sicheren Softwareteil passiert. Wie willst Du im Falle eines Unfalls nachweisen, daß der Unfall nicht deshalb passieren konnte, weil die falsche Konfig aktiviert wurde? Der nicht-sichere Softwareteil kann ja vor und nach dem Unfall manipuliert worden sein...

Desweiteren meine ich, daß immer die höchstmögliche Sicherheit angestrebt werden sollte, und nicht nur so viel, wie die Faulheit/Bequemlichkeit des teuer bezahlten Programmierers gerade hergab. Unnötige Funktionen/Gefahrenherde haben in einer F-SPS nichts zu suchen und sollten im Endprodukt rausgelöscht werden.

Harald

Ich finde das nicht so abwegig, serienmaschinenbau ist etwas anderes als Projektarbeit
und hat nichts mit Faulheit oder Bequemlichkeit zu tun. Ich finde sogar im Gegenteil
wenn es richtig ausgeführt wird kann es sogar zur Sicherheit beitragen, da nur ein Projekt
gepflegt wird und nicht viele von vielen Programmierer.

Siemens geht da sogar drauf ein https://support.industry.siemens.co...-1200-bzw-s7-1500-zu-beachten-?dti=0&lc=de-DE

Vielleicht sollte man für jede Art der Konfiguration eine F-Baugruppe verwenden.

Hallo Zusammen,

ich weiß, dass ich mich wiederhole - aber zur Sicherheit möchte ich mein Anliegen noch einmal detailliert beschreiben.

Ich habe eine ET200SP F-CPU mit DIO und FDIO
Ich habe (der einfachheit halber) zwei Roboter die via Profinet kommunizieren.
Ein Roboter tauscht seine sicheren Signale via Profisafe aus, der andere via F-EA.

Es gibt ein Projekt das im Maximalausbau projektiert ist.

Aufgrund der Projektstruktur ist es so, dass nur einer der Roboter tatsächlich vorhanden ist.
Der andere projektierte wird daraufhin via SFC12 deaktiviert.

Somit ergibt sich, dass das Signal "Not-Halt-OK" von dem deaktivierten Roboter inaktiv ist
und somit die Roboterzelle in einen sicheren Zustand überführt wird.

Mein Gedanke ist nun, da nur einer der Roboter tatsächlich vorhanden sein kann, die sicheren
Signale der Roboter zu verodern. Außerdem wird in dem sicheren Teil geprüft, dass auch nur
eines der Signale ansteht. Steht mehr als ein Not-Halt-OK an wird dies als Fehler interpretiert und
die Anlage in einen sicheren Zustand überführt. Dies ist eine zusätliche Prüfung, ein Betrieb mit zwei
Robotern ist zwar aus Sicht des Projektes bzw. der Topologie möglich - Aufgrund der mechanischen
Abmaße der Roboterzelle technisch aber nicht möglich. Außerdem würde die Software einen zweiten
Roboter via SFC12 deaktivieren - dies ist zwar nicht sicher, macht aber recht schnell kurzen Prozess mit
dem zweiten Roboter.

Der Ausbau der ET200SP F-CPU verändert sich auch je nach Roboter.
Bei beiden Roboter gibt es DIO sowie eine F-DI und eine F-DQ Karte.
Bei dem Roboter ohne Profisafe werden außerdem 2 F-RQ Module gesetzt.

Über das Optionshandling werden die zwei F-RQ Module deaktiviert, wenn
nicht der Roboter erkannt wird der diese benötigt. Im F-Programm werden keine
Änderungen vorgenommen. Die Signale auf der F-DQ-Karte welche die 2 F-RQ ansteuern
um den Roboter Not-Halt-OK sowie Bedienerschutz OK zu melden werden dennoch angesteuert.
(Und selbst wenn ich dies noch unterbinde führt es ja nur zu einem sicheren Zustand).
Werden diese beiden F-RQ Module fälschlicherweise deaktiviert geht die Anlage in einen
sicheren Zustand über, da der dort angeschlossene Roboter keine Not-Halt-OK Signale mehr bekommt.
Wird fälschlicherweise die Aktivierung der F-RQ Module ausgeführt passiert nichts, da sie ja gar nicht
da sind um etwas zu tun.

Somit bin ich der Meinung, dass mein Konzept so funktionieren würde und sicher ist.
In jeder Situation mit einer Fehlfunktion der o.g. Deaktivierung ist das schlimmste was passiert,
dass ein Bediener vor einer Roboterzelle steht die sich nicht starten lässt, da kein Not-Halt-OK
Signal vorhanden ist. Es kann aber nie passieren, dass ein Not-Halt-Taster nicht funktionsfähig ist.

Das soll wie gesagt kein "ich habe DOCH recht" oder ähnliches werden, sondern das ist eine
Idee für eine Serienmaschine - und ich bin weiterhin an eurer Meinung interessiert.

Ich könnte, wie vorgeschlagen, auch noch eine F-DI Karte setzen um die Varianten zu codieren.
Aber die 200€ kann ich mir meiner Meinung nach im Monent sparen.
Das ganze Thema möchte ich noch im Detail und im Rahmen der Risikoanalyse mit meinen
Kollegen besprechen, wollte hier nur schonmal eine breit gestreute Meinung einholen.

Grüße

Marcel

Edit: Etwas mehr Detaillierung

Hast du mal den Link von Siemens gelesen, ich würde jeden oder mindestens zwei Robotern
eine F-DI Karte zuweisen, wenn nicht sowieso gesteckt. Die entsprechende Karte wird gesteckt,
die den vorhanden Roboter zugeordnet ist. Durch den Status der Karte kannst du dann erkennen
welche Karte gesteckt ist und kannst dieses auswerten. Durch die Codierelemente der Karte, ist
doch auch keine Manipulation möglich.

Das habe ich gelesen und verstanden.

Problematik ist hier: nur einer der Roboter kommuniziert via Safety-EA.
Alle anderen über Profisafe. Somit ist das mit dem Stecken und Codieren so eine Sache
Und ne F-DI Karte verheizen nur damit ich über Drahtbrücken nen Roboter vorwähle...
hmmm... Serienmaschinen dürfen nix kosten... Kennst Du ja...

Grüße

Marcel

nicht ganz verstanden, wie ich es meine.

Wenn du in deiner Hardware Konifig für jeden Robi ein F-DI Karte setzt.
Robi 1 - Karte 1
Robi 2 - Karte 2
Robi 3 - Karte 3

So hast du doch in wirklichkeit nur immer eine Karte verbaut, da du ja nur
ein Robi betreiben kannst.
Eine F-DI Karte wirst du ja immer im jeden Fall gebrauchen, da du sicherlich auch
einen Not-Halt hast und Schutztür.
Diese kannst du dann ja je nach verwendenten Robi an die gesteckte Karte anschließen.

Also du brauchst immer nur eine Karte und nicht drei.

Jetzt versteh ich was Du meinst... eigentlich ne Coole Idee...

Nachteil: Dadurch muss ich dann die anderen Signale auf der Karte verordern, weil sie können ja dann von Karte 1,2 oder 3 kommen.
Und ich muss beim Vergeben der F-Adresse die Karte im richtigen Slot stecken haben... was je nach Ausbau mit Blindmodulen etc. einhergeht.

Aber sonst ne coole Idee

Grüße

Marcel

Vielleicht solltest du auch nicht die Signale ver- 'ODER' -n, sondern
für jede Konfiguration einen eignen FB schreiben und diesen
Bedingt je nach Konfiguration aufrufen.

So ist es auch später für Service Arbeiten eindeutiger.