PCS7 gerechte Diagnose eines "fremd" - PN Slaves

Hallo Kollegen, 

 ich suche nach einem PCS7 konformen Weg einen fremd PN - Slave zu "diagnostizieren". Es geht nur darum, ob der Teilnehmer gestört bzw. nicht erreichbar ist. Ist es möglich bzw. legitim hier die Daten des OB_DIAG1_PN zu verschalten oder gibt es einen anderen Weg? Die Möglichkeit den SFC51 zu nutzen ist mir bekannt, allerdings scheint es kein Beispiel zu geben, wie man dies in PCS7 handhabt. 

Vielen Dank für Eure Unterstützung

Pete

Eine Verschaltung mit den automatisch generierten Plänen würde ich nicht machen, da mir das zu unsicher wäre, dass diese unter allen Umständen erhalten bleibt. Außerdem ist die Fehlerauswertung über die Event-OBs nicht in allen Fehlerfällen zuverlässig, und wenn man es selber macht, dann kann man es auch gleich richtig machen.

Ich würde mit einen SCL FB schreiben, der in einer kleinen Schrittkette eben den SFC51 mit den entsprechenden Parametern aufruft, und dann entsprechend den Daten Ausgänge setzt oder zurücksetzt. Also im Grunde so wie man den SFC auch klassisch einsetzen würden, nur eben alles in einem FB gekapselt mit den entsprechend sinnvollen PCS7 Attributen versehen, damit es in CFC funktional einsetzbar ist.

Ich binde mir dann bei Fremd-Slaves mit dem Fehlerzustand des Teilenehmers einen entsprechenden Signalzustand in das Signal ein.

Hallo Thomas, 

 nicht wundern, ich hatte mich aus versehen nochmal registriert und mich gewundert, wo denn mein eigentlicher Account hin ist... also gleiche Person, welche hier schreibt nur diesmal mit meinem richtigen Account.

Das Thema ist ein "heiß" diskutierte Geschichte, da ich von Seiten des Support den Einwand gehört habe (den du ja auch schon angesprochen hast), dass dieses Einfügen in den OB1 hinsichtlich der Performance Probleme nach sich ziehen kann. da der SFC51 mitunter länger als einen Zyklus benötigt, um alle Daten gelesen zu haben. Kann man dieses Lesen der Daten mit dem SFC51 auf das Vorhandensein von zwei bestimmten PN Slaves beschränken?

GRUND: wir haben einen Coater (wie ein klassischer Betonmischer...) und wir wollen damit den Sensor für die Neigung überwachen. Sprich, wenn der Sensor kein (gültiges) Signal mehr liefert, soll die Trommel weder rotieren noch im Neigungswinkel verfahren werden können. 

Es muss auch eine Möglichkeit geben, sich eigene Eingangstreiber zu schreiben, nur leider bekommt oder findet man keinerlei Hinweise, wie dies zu bewerkstelligen ist oder auf was man dabei achten muss.

Noch eine Frage zum SFC51: ich habe natürlich hier im Portal das Beispiel für den SFC51 gefunden. Logischerweise im S7 - 300/400er Umfeld. Was ich noch nicht gefunden habe, wie denn die Daten strukturiert sind, die der SFC51 ausliest? Kannst du das erklären oder hast du ein kurzes Beispiel dafür?

Vielen Dank!

Hi vanDyk,

mit deiner Treiberproblematik kann ich dir nicht helfen, aber ich kann dir sagen wo du die Informationen zum SFC 51 erhalten kannst. Siemens hat nämlich ein Handbuch für alle Systemfunktionen die eine 300- bzw. 400-CPU unterstützt. Diese findest auch im Online Support unter SIMATIC System- und Standardfunktionen für S7-300/400 - Band 1/2, im Kapitel 13.3 findest du dann die Beschreibung des SFC 51.

P.S. Frag mich bitte nicht warum, dass Band 1/2 heißt obwohl diese Dokument sowohl Band 1 als auch Band 2 beschreibt.

Schöne Grüße
Heisenberg

Moin,

das Problem ist eigentlich ziemlich trivial.

Im Original werten die SIemens-Treiber sowohl zyklische als auch azyklische DIagnosedaten aus. Dir reichen scheinbar nur die zyklischen. Hier ein Auszug aus einem PN-BG Treiber:

Deklaration der Struktur für den 0C96h Datensatz:

BGR_ZUST : STRUCT
logadr : WORD ;    //Bits 0 bis 14: Adresse der Baugruppe Bit 15: 0 = Eingang, 1 = Ausgang
System : WORD ;    //Kennung für zentrale Baugruppe / DP-Mastersystem-ID / PROFINET IO-System ID
API_1 : WORD ;    //Application Process Instance
API_2 : WORD ;    //Application Process Instance
Station : WORD ;    //Baugruppenträger-Nr./Stationsnummer/Gerätenummer
Slot : WORD ;    //Steckplatz-Nr.
Subslot : WORD ;    //Submodulsteckplatz (falls kein Submodul gesteckt werden kann, ist hier 0 anzuge
Offset : WORD ;    //Offset im Nutzdatenadressraum der zugehörigen Baugruppe
Solltyp_1 : WORD ;    //Herstellernummer oder Profilidentifikation
Solltyp_2 : WORD ;    //Gerät
Solltyp_3 : WORD ;    //Laufende Nummer oder Profilindex
Solltyp_4 : WORD ;    //1. Wort des Doppelwortes Modul Identifikation
Solltyp_5 : WORD ;    //2. Wort des Doppelwortes Modul Identifikation
Solltyp_6 : WORD ;    //1. Wort des Doppelwortes Submodul Identifikation
Solltyp_7 : WORD ;    //2. Wort des Doppelwortes Submodul Identifikation
Soll_ungleic_Ist_typ : WORD ;    //Kennung Soll/Ist
reserve : WORD ;
Eastat : WORD ;    //E/A-Status
Ber_bgbr : WORD ;    //Bereichskennung/Baugruppenbreite
reserve_bgr_zust : ARRAY  [0 .. 4 ] OF WORD ;
END_STRUCT ;

 Aufruf SFC51 Baustein:

//===============================================================================================
//************************************** SUBNETZ 1 **********************************************
//===============================================================================================
IF PNIO_ADR <> 0  AND NOT A_sdwRESERVE[24] THEN

REPEAT
(* Module status information centrally or at a PROFIBUS DP/PROFINET
Abfrage Subnetz-Status - Diagnoseadresse der PN-IO Schnittstelle - Primäres Subnetz *)
RETURN_CODE         :=      RDSYSST     (
REQ         :=  TRUE,
SZL_ID      :=  W#16#C96, //Module status information centrally or at a PROFIBUS DP/PROFINET
INDEX       :=  INT_TO_WORD(PNIO_ADR),
BUSY        :=  tPNIO_ADR,
SZL_HEADER  :=  SZL_HEADER,
DR          :=  BGR_ZUST
);

UNTIL NOT OBSTART.OB_100 OR NOT tPNIO_ADR END_REPEAT;
(* ===============================================================================

Bit 0 = 1: Baugruppe gestört (über Diagnosealarm erkannt)
Bit 1 = 1: Baugruppe vorhanden
Bit 2 = 1: Baugruppe nicht verfügbar
Bit 3 = 1: Baugruppe deaktiviert
Bit 4 = 1: Störung der Station (nur Stellvertreter-Slot)
Bit 5 = 1: Ein CiR-Vorgang für diese Baugruppe /Station ist gerade aktiv oder noch nicht abgeschlossen
Bit 6 = 1: reserviert für S7-400
Bit 7 = 1: Baugruppe im Lokalbussegment (nur bei S7-300)
Bit 8 = 1: Baugruppe Wartungsbedarf ("grün")
Bit 9 = 1: Baugruppe Wartungsanforderung ("gelb")
Bit 10 bis 15: reserviert

=============================================================================== *)

IF NOT tPNIO_ADR THEN
IF RETURN_CODE  =   0 THEN
IF (* (BGR_ZUST.Eastat AND W#16#2) = W#16#2 AND *) (BGR_ZUST.Eastat AND W#16#200) = W#16#0 THEN
ASIG1_bool[2]       :=  FALSE;  // PN-IO-System @1%d@: Instandhaltungsanforderung
END_IF;
IF (* (BGR_ZUST.Eastat AND W#16#2) = W#16#2 AND *) (BGR_ZUST.Eastat AND W#16#200) = W#16#200 THEN
ASIG1_bool[2]       :=  TRUE;   // PN-IO-System @1%d@: Instandhaltungsanforderung
END_IF;
IF (* (BGR_ZUST.Eastat AND W#16#2) = W#16#2 AND *) (BGR_ZUST.Eastat AND W#16#100) = W#16#0 THEN
ASIG1_bool[3]       :=  FALSE;  // PN-IO-System @1%d@: Instandhaltungsbedarf
END_IF;
IF (* (BGR_ZUST.Eastat AND W#16#2) = W#16#2 AND *) (BGR_ZUST.Eastat AND W#16#100) = W#16#100 THEN
ASIG1_bool[3]       :=  TRUE;   // PN-IO-System @1%d@: Instandhaltungsbedarf
END_IF;
ELSE
IF NOT CPU_DIAG.CPU_ERR0 THEN
tPNIO_ADR           :=  RETURN_CODE = -32635 OR
RETURN_CODE = -32604 OR
RETURN_CODE = -32605 OR
RETURN_CODE = -32606 OR
RETURN_CODE = -32571;
IF NOT tPNIO_ADR THEN
ASIG1_bool[3]       :=  TRUE;
END_IF;
END_IF;
END_IF;
END_IF;
END_IF;

 Du müsstest also die 0C96h Zustandsliste an der RACK-Diagnose deines PN-Devices im Haupt-Subnetz und im redundanten Subnetz lesen (es sind jeweils verschiedene LOGADDR).

Dann musst du den Zustand des PN-Slaves anhand der Informationen im Returnwert der SFC51 auswerten. Die generelle Zugriffsstruktur über Area/Subnetz/Rack/Slot/Modul/Submodul sollte soweit verstanden worden sein, daß du deinem Baustein die richtigen Adressen übergeben kannst.

Wenn die Anzahl der PN-Devices <= 100 ist, würde ich mir keine Sogen über die Laufzeit machen. In den Originalquellen der Basic Library sind noch Mechanismen vorgesehen, um die CPU-Last zu reduzieren und nicht in jedem Zyklus eine Diagnoseanforderung abzusetzen. Das wird allerdings erst bei Mengengerüsten interessant, die in die 1000er gehen.

Weiterer Support gerne per PN.

Hallo Severus Snape,

 das nenne ich mal eine Hilfe! Werde dein Sourcecode in unsere Quelle übernehmen und dann würde ich mich noch mal melden!

Erst einmal vielen Dank für Deine Unterstützung!

vanDyk

Hallo Severus Snape,

 das nenne ich mal eine Hilfe! Werde dein Sourcecode in unsere Quelle übernehmen und dann würde ich mich noch mal melden!

Erst einmal vielen Dank für Deine Unterstützung!

 Wenn Du noch mehr Support brauchst, ruhig Bescheid sagen. Vielleicht habe ich speziell für deinen Anwendungsfall irgendwelchen passenden Quellen für dich.

Generell gilt: Diagnose unter PCS7 geht nach dem selbem Schema wie der Aufbau des Profinet an sich, sprich: Area / Subnet / Rack / Slot / Subslot.

Ein Diagnosebaustein nach PCS7 wird i.d.R. (mindestens) in die folgenden Ablaufebenen eingefügt:

- OB86 (Rackausfall)
- OB83 (Ziehen/Stecken)
- OB82 (Diagnosealarm)

Die Diagnoseeinformationen aus diesen Ebenen, bereitgestellt durch den OB_BEGIN(_PN), werden ausgewertet, und bei der Übereinstimmung der geografischen Daten in der  CPU_DIAG_PN Struktur mit den GEO-Daten der adressierten Komponente, dann eine Diagnoseanforderung abgesetzt.

Ein Event (Diagnoseereignis) im OB86 oder OB83 führt zur Ausführung des SFC51, um ein Status-Update für die Komponente zu bekommen, und ein Diagnosealarm im OB82 ohne RACK_ERR führt hingegen zu einem RDREC-Request auf den Datensatz 800Ah oder 800Ch.

Daneben gibt es noch die Möglichkeit, den Zustand der Ports zu diagnostizieren. Alles in einem ergbit sich für dein RACK folgende Zustandsliste:

- Station im Betrieb
- Station nicht erreichbar
- Station gestört
- Station meldet Redundanzverlust

Wenn dein PN-Device noch steckbare Module enthält (z.B. IO-Link, oder Hart) müsstest Du also neben dem "RACK"-Baustein noch den "MOD"-Baustein für deine steckbaren oder konfigurierbaren (Sub-)Module nachbilden, um ihre Diagnose sicherstellen.

Das (Sub-)Modul kann demnach folgende Zustände annehmen:

- Modul im Betrieb
- Modul ausgesteckt
- Modul gestört (Störungsnummer per Diagnosealarm, mit Textliste)

Freundliche Grüße

Severus