×
Siemens Industry Online Support
Siemens AG
Beitragstyp: Anwendungsbeispiel Beitrags-ID: 19387060, Beitragsdatum: 15.09.2004
(0)
Bewerten

Melden des Modulstatus der Module an einer ET200S CPU (eingesetzt als DP Slave) an einen DP-Master

  • Beitrag
  • Betrifft Produkt(e)

FRAGE:  
Wie kann der Modulstatus einer als DP-Slave eingesetzten ET200S CPU an den DP-Master weitergeleitet werden? 

ANTWORT:  
Bei Einsatz der ET200S-CPU (IM151-7) als DP-Slaveanschaltung an einem DP-Master, stehen dem Anwender verschiedene Systemfunktionen zur Verfügung, um Diagnoseinformationen an den Master mitzuteilen.Um mit diesen Diagnoseinformationen auch den Modulstatus der an der Slaveanschaltung eingesetzten Module an den Master zu melden, gibt es prinzipiell zwei Lösungsansätze: 

Variante 1: 
Diagnosedaten über den zyklischen Datentransfer an den DP-Master senden.

Vorteile: 

  • Mit jedem DP Master (V0/V1) einsetzbar.

Nachteile:

  • Die Datenmenge, die maximal zyklisch übertragen werden kann (240 Bytes), reduziert sich um die Anzahl der Diagnosebytes. (im Beispiel 8 Bytes für die Lifelist)
  • Im Master muss der Anwender die zusätzlichen Bytes programmtechnisch auswerten.
  • Um eine detaillierte Diagnose (z. B. Drahtbruch an Kanal 1 der Analogbaugruppe) an den DP-Master zu schicken, müssten abhängig vom Baugruppentyp bis zu 44 Bytes zusätzlich zyklisch übertragen werden.

Variante 2: 
Daten alarmgesteuert über den azyklischen Datentransfer an den DP-Master zu senden.

Vorteile:

  • Beim DP-Master wird ein Diagnosealarm ausgelöst. Es müssen keine zusätzlichen Infobytes im Master programmtechnisch ausgewertet werden. Es erfolgt ein Eintrag im Diagnosepuffer.
  • Keine Reduzierung der zyklischen Datenmenge.

Nachteile:

  • Nur mit S7-Mastern/DPV1-Mastern verwendbar.
  • Nur bis maximal 2-kanaligen Baugruppen möglich. Bei 4-kanaligen Baugruppen müssen die Diagnosedaten vom Anwender modifiziert werden.

Das hier verfügbare Beispiel stellt eine Kombination beider Lösungen dar.

 

Bild 1: Zusammenwirken der Funktionseinheiten im Beispielprogramm

 

Beschreibung des Programmbeispiels:

Im Programmbeispiel werden OB82, OB83 und der Datensatz 1 des intelligenten Slave benutzt, um die Störungen der Module zu ermitteln. Der gestörte Slot wird in einen Datenbaustein (Lifelist) DB10 und die detaillierten Diagnosedaten des Datensatzes 1 des gestörten Moduls werden in den DB11 eingetragen. 
Der Inhalt des DB10 wird im zyklischen Datenverkehr an den Master übertragen (die ersten 8 Bytes Eingänge am Master). Da an der ET200S-CPU maximal 64 Baugruppen eingesetzt werden dürfen, reichen dazu 8 Bytes aus.

Damit der Master schnell ein gestörtes Modul identifizieren kann, wurde Bit 0.0 als "Sammelmerker" benutzt. Dieses Bit ist gesetzt, wenn mindestens 1 Modul eine Störung aufweist. 

Um die detaillierte Diagnose an den Master zu senden, wird im OB1 des Slaves ein Diagnose-Alarm an den Master abgesetzt. Dieser löst im Master den OB82 aus. Somit kann im Master das Lesen der Detaildiagnose mittels der azyklischen Funktion SFC59 "RD_REC" angestoßen werden. Dabei wird der Datensatz 1 des im OB82 des Masters angegebenen Moduls gelesen.

Da die Detaildiagnose mittels SFB75 bereits übertragen wird, könnten diese Daten vom Master alternativ auch über SFB54 "RALARM" oder SFC13 "DPNRM_DG" ausgelesen werden.
Falls mit SFC13 "DPNRM_DG" im Master gearbeitet wird, so werden die über SFB75 versendeten Daten nach dem Modulstatus in der Diagnose angehängt.

Die Bedeutung der Bits im Datensatz 1 der ET200S CPU kann dem Handbuch "ET 200 S Interfacemodul IM151-7 CPU" BID '12714722'  im Kapitel 7.7 entnommen werden.

Im Beispiel wurde darauf verzichtet, den OB83 (Ziehen/Stecken) mit Alarmbearbeitung zu versehen. Bei Ziehen eines Moduls wird nur der gestörte Slot in einen Datenbaustein (Lifelist) DB10 eingetragen und kein Alarm erzeugt.

Hinweise:

  • Die Anzahl der kanalspezifischen Diagnosebytes hängt von der Anzahl der Kanäle im Modul ab. Der DS1 eines Moduls der ET200S kann bis zu 44 Bytes lang sein. Da mittels SFB75 nur maximal 16 Bytes Alarminformation erzeugt/weitergeleitet werden können, muss der Anwender die benötigte Information auf die 16 Bytes kürzen. 
    Dabei dürfen die ersten 4 Bytes nicht verändert werden, denn diese nutzt der OB82 des Masters um einen gültigen Diagnosepuffereintrag zu erzeugen. 
    Die Daten sind bei Modulen mit mehr als 2 Kanälen anzupassen (2 kanalige Baugruppen liefern max.16 Bytes Diagnoseinformation).  Die Länge der Diagnosedaten steht im DS1 Byte 5.
  • Die azyklischen Funktion "RD_REC" vom Master sollte immer auf die OB82 angegebene Adresse, also auf einen virtuellen Slot, ausgeführt werden. Wird hier die Diagnoseadresse des Slaves angegeben, so wird ein anderer Datensatz 1 ausgelesen. Dieser bezieht sich nicht auf ein Modul, sondern zeigt nur an ob der Slave in RUN oder STOP ist.
    Der Datensatz 1 des virtuellen Slots kann auch erst ausgelesen werden, nachdem auf diesen virtuellen Slot ein Alarm erzeugt wurde. Der Aufruf des SFB75 erzeugt in diesem Fall erst den DS1.
    Der virtuelle Slot ist der Datenbereich, der zum Datenaustausch mit dem Master genutzt wird, also kein real vorhandener Slot.
  • Der SFB 75 kann nur Diagnose- und Prozessalarme erzeugen- kein Ziehen/Stecken-Alarm.
  • Im Beispiel wurde darauf verzichtet den STATUS des SFB75 auszuwerten. Dies macht im laufenden Betrieb Sinn, denn wenn der Master in STOP ist, so quittiert er den Alarm nicht und der Slave muss ihn nochmals senden oder abbrechen. Die Bedeutung der Statusmeldungen kann der Online-Hilfe von STEP 7 entnommen werden.
  • Zu jeden kommenden Ereignis, sollte auch ein gehendes Ereignis an den Master gemeldet werden. Erst mit dem gehenden Ereignis wird die SF-Led am Master zurückgesetzt.

 

Der Download enthält ein STEP 7-Projekt mit dem oben beschriebenen Programmbeispiel:

  ET_200S_ModStatus.exe

Kopieren Sie die Datei "ET_200S_ModStatus.exe" in ein separates Verzeichnis und starten diese anschließend per Doppelklick. Das STEP 7-Projekt wird entpackt. Anschließend können Sie das STEP 7-Projekt mit dem SIMATIC Manager öffnen und bearbeiten.

 

Ablauffähigkeit und Testumgebung:
In der folgender Tabelle sind die Komponenten aufgeführt,  mit denen dieser Beitrag erstellt und die beschriebene Funktionsweise verifiziert wurde:

Testumgebung Version 
PC Plattform Pentium III, 800MHz, 510 MB Hauptspeicher
PC-Betriebssystem Windows 2000 Professional 5.0
STEP 7  STEP 7 V5.3, SP 1
Optionspakete --
S7-CPU CPU 316-2DP V1.2 (6ES7 316-2A600-0AB0)
ET200s-CPU IM 151-7 V2.0 (6ES7 151-7AA10-0AB0)

 

Securityhinweise
Um technische Infrastruktur, Systeme, Maschinen und Netzwerke gegen Cyber-Bedrohungen zu sichern, ist es erforderlich, ein ganzheitliches IT Security-Konzept zu implementieren (und kontinuierlich aufrechtzuerhalten), das dem aktuellen Stand der Technik entspricht. Die Produkte und Lösungen von Siemens formen nur einen Bestandteil eines solchen Konzepts. Weitergehende Informationen über Cyber Security finden Sie unter
https://www.siemens.com/cybersecurity#Ouraspiration.