Ich sag hier, wie immer, nur: Kommt auf den Anwendungsfall drauf an.
pro PnozMulti:
- Drehzahl- und Stillstandsüberwachung ohne sicheren Antrieb (z.B. mit 2 Inis)
- einzelner Ausgang erfüllt SIL2/Kat 3
- einfache (sehr schnelle) programmierung
- günstige Relais-Ausgänge
- abgesetzter Betrieb von ST-Steuerung - wird bei der ST-Steuerung z.B. die Hardware-Konfiguration geladen, hat man trotzdem keinen Not-Aus (besonders wichtig bei verketteten Anlagen)
- billig
- bei ST-SPS Herstellerunabhängig da verschiedene Bussysteme möglich
contra Pnozmulti
- begrenzte Anzahl IOs
- Rückführkreis-Funktion ist empfindlich
- bei I-Fehler (z.B. 1-kanalige Betätigung) muss der Sensor in den sicheren Zustand gebracht (bei Not-Aus kein Problem, aber z.B. bei Positionsschaltern an einem Roboter mit Antivalenten Kontakten eine Katastrophe)
- bei O-Fehlern muss das Pnoz neu gestartet werden
- keine Dezentralisierung möglich
- sehr begrenzte Diagnosemöglichkeiten (das System mit den Diagnosewörtern ist nicht wirklich Anwenderfreundlich), sehr begrenzet Kommunikationsmöglichkeiten
pro S7-F
- verschiedene Leistungsklassen verfügbar
- Dezentralisierung möglich
- viele Normslaves verfügbar (mit integrierter Sicherheitstechnik)
- Gruppenabschaltung bei ET200S
- einfache Kommunikation ST - F Teile (vor allen, wenn man Sensoren & Aktoren, welche auf F-Peripherie hängen, aus dem ST-Teil steuern muss - Stichwort "Zustimmbetrieb")
- einfache Kommunikation F-Steuerung zu F-Steuerung per DP/DP- oder PN/PN-Koppler
- viele Fehler lassen sich nach Erreichen eines gültigen Zustandes quittieren (nicht nur im sicheren Zustand)
- einfache Diagnose, da von der HMI direkt auf die F-Daten zugegriffen werden kann
contra S7-F
- sehr langsam
- lange Einarbeitungszeit und relativ aufwändige Programmierung (aber im Vergleich zur PSS einfach)
- wird sowohl F- als auch ST-Programm in einer CPU betrieben und die CPU stoppt, stoppt auch der F-Teil (besonders nervig bei verketteten Anlagen)
- Baugruppenauswahl sehr klein
Wir verbauen bei uns in der zwischenzeit in fast jeder Anlage zumindest ein PnozMulti - solange man mit den IOs eines PnozMulti auskommt. Stoßen wir an die Grenzen des PnozMulti, kommen mehr und mehr S7-F Steuerungen zum Einsatz (F und ST-Teil in 1 CPU) - meist sind dies allerdings kompakte Anlagen, wo 1 Teil ohne den anderen sowieso nicht laufen kann - wo also auch ein CPU-STOP keine allzugroße Katastrophe ist.
Ich habe allerdings letztes Jahr ein Projekt gemacht, wo ich massiv die Nachteile des Safety-Integrated System zu spüren bekommen hab: In einer Produktionslinie sind 6 F-CPUs verbaut, wobei je 3 direkt miteinander kommunizieren - die Kopplung der beiden 3er-Systeme erfolgt über die PSS-3006 eines anderen Anlagenherstellers.
Geht nun 1 der 7 CPUs in STOP, so steht die gesamte Produktionsanlage mit Not-Aus. Hier wäre in jeden fall sinnvoll gewesen, alle Not-Aus zentral mit 1 F-CPU zu verwalten, und nur die jeweiligen Lichtvorhänge, Ventile usw. direkt von der Maschinen-CPU verwalten zu lassen (mit Profinet ist das ja auch von der Verkabelung her kein Problem).
Einzelne Überlegungen gehen aber auch in die Richtung, ST und F-CPU zu trennen, aber dennoch für beides eine S7-F einzusetzen. Preis/Leistungtechnisch kann sich eine IM151-7F (ET200S-CPU) absolut mit einem PnozMulti messen. Nutzt man nun z.B. eine 317 als ST-CPU und eine IM151-7F als F-CPU, hat man die Vorteile des Abgesetzten Betriebes - und die Vorteile der S7F.
Also wie gesagt - kommt immer auf den Anwendungsfall drauf an.
mfg
Maxl