Moeller XSystem - Grundlagen

Moeller XSystem - Grundlagen
PROcess FIeld BUS FMS AUTOMATION PROCESS PROFIBUS PROFIBUS ist ein herstellerunbhängiger, offener Feldbusstandard für Anwendungen in der Automatisierung. Die Herstellerunabhängigkeit und Offenheit wird durch die internationale Norm EN garantiert. Das PROFIBUS-Sortiment besteht aus drei Varianten: PROFIBUS-DP „Dezentrale Peripherie“ für die schnelle Kommunikation zu dezentralen Peripheriegeräten. PROFIBUS-PA „Prozess Automation“ für die Anwendung in explosionsgefährdeten Bereichen „eigensicher“ PROFIBUS-FMS „Fieldbus Message Specification“ für die umfangreiche Kommunikation in der Steuerungs- und Leitebene. Moeller bietet Ihnen Komponenten für PROFIBUS-FMS und PROFIBUS-DP. Persönliche Bemerkungen: EN 50170 DP PA FACTORY Moeller XSystem - Grundlagen 27-Mar-17, Seite 1

Sortiment DP FMS PA Moeller XSystem - Grundlagen Branche:
Allg. Automatisierung Verfahrens- technik Branche: Maschinenbau RS 485 IEC Elektr. Schnittstelle: Verständigung: PA-Geräte benötigen einen DP-Master; es gibt keine PA-Mastergeräte, sondern lediglich Gateways zur Umsetzung der Busphysik. Eigene Bemerkungen: Moeller XSystem - Grundlagen 27-Mar-17, Seite 2

Vernetzungsebenen Aktuator/ Sensor- Ebene Leitebene Feldebene Suconet K Interbus PROFIBUS-DP PROFIBUS-PA AS-Interface Profibus-FMS Multimaster azyklisch Master/Slave zyklisch CAN Vernetzungsebenen Diese Darstellung zeigt die Ebenen der Automatisierungspyramide; die „Aktuator-Sensor-Ebene“ , „Feldebene “ und die „Leitebene“. Die Darstellung berücksichtigt nur die Bussysteme, die auch von KM als Produkte angeboten werden. Der PROFIBUS-FMS mit der Möglichkeit des azyklischen Datenverkehrs ermöglicht ereignisabhängige Kommunikation; d.h. effizienter Datenverkehr zwischen Steuerungen und Visualisierungs-/ Leitstationen. Im Mittelfeld der Steuerungsebene liegen leistungsmäßig „Suconet K“, „Interbus-S“, „PROFIBUS-DP“ und „PROFIBUS-PA“ dicht an dicht. Sie alle arbeiten nach dem Verfahren des zyklischen Pollings. DP steht für Dezentrale Peripherie! PA steht für Prozess Automation! Der PROFIBUS-PA ist speziell auf die Bedürfnisse der Verfahrenstechnik durch seine „eigensichere Übertragungstechnik“ abgestimmt. Konkurrenzlos füllt das Aktuator-Sensor-Interface (AS-i) die untere Feldebene. Mit der festen Nutzdatenmenge von 4 Bit deckt das AS-i speziell den Kommunikationsbedarf der Sensor-/Aktuator Welt ab. Persönliche Bemerkungen: Moeller XSystem - Grundlagen 27-Mar-17, Seite 3

Topologien Kommunikations - Grenzen DP M 1 DP M 4 FMS M 8 FMS M 9 S 6 S 7 PA PA Topologien Das Bild zeigt eine mögliche PROFIBUS-Topologie, bei der alle PROFIBUS-Varianten an einer Busleitung arbeiten. Zur PROFIBUS-PA-Welt muß allerdings ein DP/PA-Koppler in die Busleitung geschaltet werden. Dieser Koppler setzt die RS-485 Signale in die „eigensichere Übertragungsphysik des PROFIBUS-PA um ( * Baudrate 31,25 kBit/s ). Zur Umsetzung von DP nach PA stehen grundsätzlich zwei Gerätetypen zur Verfügung: Die sogenannten Koppler (z.B. von Pepperl & Fuchs) setzen die Übertragungsgeschwindigkeit der DP-Seite auf die relativ langsame Geschwindigkeit von PA herunter; die sogenannten LINKs können Daten zwischenpuffern und erlauben deshalb DP-seitig höhere Geschwindigkeiten. Kommunikativ stehen die FMS-Komponenten untereinander und die DP- Komponenten untereinander in Verbindung. Eine Kommunikation zwischen FMS und DP-Geräten ist nicht möglich, obwohl alle Geräte an einer Busleitung betrieben werden (--> Kommunikationsgrenzen). Im Bereich des PROFIBUS-DP ist es möglich mehrere Master an einer Busleitung zu betreiben. Diese können jedoch untereinander nicht kommunizieren. Ebenso ist ein DP-Slave immer nur einem DP-Master zugeordnet. Persönliche Bemerkungen: FMS S 10 FMS S 11 DP S 2 DP S 3 DP S 5 * Moeller XSystem - Grundlagen 27-Mar-17, Seite 4

DP-Geräteklassen DP-Master Klasse 1 DP-Master Klasse 2 Config, Param Config, Param READ READ READ WRITE I / Q WRITE DP-Geräteklassen PROFIBUS-DP ist normalerweise ein Mono-Master-System mit einem zyklischen Datenverkehr zu den Slaves. Im Bereich der Master wird zwischen zwei Geräteklassen unterschieden : DP-Master Klasse 1 (DPM1) DP-Master Klasse 2 (DPM2) DPM1 arbeiten im zyklischen Datenverkehr mit den ihnen bei der Projektierung zugeordnenten Slaves (lesen der Eingänge, schreiben der Ausgänge, Statusabfragen). Ein Klasse 1 Master kann nicht mit einem anderen Klasse 1 Master kommunizieren (--> Kommunikationsgrenzen). DPM2 sind im allgemeinen Programmier- und Bediengeräte, mit denen es möglich ist, Klasse 1 Master über den Bus zu konfigurieren (azyklischer Datenverkehr). Zusätzlich kann ein Klasse 2 Master lesend auf die Ein- / Ausgangsdaten jedes Slaves (der zu einem Klasse 1 Master projektiert ist) zugreifen. Persönliche Bemerkungen: DP DP DP DP Slave Slave Slave Slave Moeller XSystem - Grundlagen 27-Mar-17, Seite 5

Projektierung (1) kBAUD Entfernung / Geschwindigkeit 12000 1500 500 187,5 9,6/19,2/93,75 Projektierung (1) Die Datenübertragungstechnik von PROFIBUS-DP basiert auf dem Industriestandard RS485. Als Übertragungsmedium wird eine zweiadrig, verdrillte und geschirmte Leitung verwendet. Die max.Länge einer Buslinie steht in reziprokem Verhältnis zur Datenübertragungsgeschwindigkeit. Bei einer Geschwindigkeit bis zu 93,75 kBaud kann eine max. Ausdehnung von 1200m erreicht werden. Bei der max. Geschwindigkeit von kBaud kann eine Ausdehnung von 100m realisiert werden. (Alle Angaben gelten ohne Repeater !) Persönliche Bemerkungen: 100 200 400 600 800 1000 1200m RS485 Moeller XSystem - Grundlagen 27-Mar-17, Seite 6

Projektierung (2) Linie 1 1 2 R 31 Max. 32 Tln. / Linie Linie 2 Max. 126 Tln R 32 50 Projektierung (2) Aufgrund der RS485-Physik erlaubt PROFIBUS-DP an einer Buslinie bis zu 32 Teilnehmer. Soll nun die Teilnehmerzahl erhöht werden, können sogenannte Repeater (R) in die Leitung geschaltet werden. Ein Repeater führt eine Signalaufbereitung (Regenerierung) durch. Mit Hilfe der Repeater können mehrere Buslinien zu einer Baumstruktur verbunden werden. Die maximale Anzahl der Teilnehmer (bzgl. der Adressierung) ist 126. Ein Repeater stellt an einer Linie einen Teilnehmer dar, der jedoch nicht adressiert wird. (Repeater sind transparent für die Kommunikation !) Zwischen 2 kommunizierenden Stationen dürfen sich max. 3 Repeater befinden. Typischerweise ist ein Master am Bus vorhanden, der eine feste, individuelle Datenmenge mit den Slaves austauscht. Maximal sind 244 Bytes in jede Richtung mit jedem Slave möglich. (Master--> Slave; Slave --> Master) Persönliche Bemerkungen: Linie n M S 244 Byte 100 Max. 126 244 Byte Moeller XSystem - Grundlagen 27-Mar-17, Seite 7

GSD - Geräte-Stamm-Daten Typ Ident Baudrate Data Status GSD - Geräte-Stamm-Daten Die GSD-Datei ist ein elektronisches Datenblatt zur eindeutigen Beschreibung der Leistungsmerkmale eines DP-Teilnehmers. Die Geräte-Stammdaten beschreiben diese Merkmale in einem durch die EN50170 genau festgelegten Format. Die Datei wird vom Hersteller erzeugt und mit dem Gerät ausgeliefert. Durch das genau definierte Format der GSD können diese Dateien mit jedem beliebigen Projektierungstool („Herstellerübergreifend“) gelesen und verarbeitet werden. Das bietet dem Anwender eine erhebliche Erleichterung bei der Projektierung von Geräten unterschiedlicher Hersteller an einem Bussystem. Persönliche Bemerkungen: Moeller XSystem - Grundlagen 27-Mar-17, Seite 8

(Bestandteil von Xsoft)
Konfiguration DP Konfigurator (Bestandteil von Xsoft) Konfiguration Master Genormte GSD GSD Geräte -Stamm-Daten Konfiguration Ein wesentlicher Vorteil des PROFIBUS-DP ist das einfache Einbinden von Geräten verschiedener Hersteller, das erst aufgrund der GSD-Dateien möglich ist. Die für die Konfiguration relevanten Daten können vom Projektierungstool (z.B. CFG-DP) aus der GSD-Datei des Slaves entnommen werden. Durch die Idee der GSD-Dateien wird das einfache Integrieren der verschiedenen Geräte möglich. An den Slave-Geräten selber ist meist nur die Busadresse einzustellen. Die Baudrate wird vom Master vorgegeben und von des Slaves eigenständig erkannt und eingestellt. Die Datenmenge, die ein Slave unterstützt, geht aus der GSD-Datei hervor und wird in der Konfigurationssoftware sichtbar. Der Master muss die Eigenschaften (Gerätetyp, Datenmenge,...) von jedem Slave kennen. Hierzu wird mit der Konfigurationssoftware eine Datenbasis erstellt, die die GSD-Daten aller Slaves enthällt. Diese Information wird dann zum Master übertragen und beim Start des Buszyklus auch auf Plausibilität geprüft. Persönliche Bemerkungen: DP M E/A Sensor Antrieb Messumformer Ventil Moeller XSystem - Grundlagen 27-Mar-17, Seite 9

Die DP-Konfiguration in der XSoft
Interne Modulreferenz; nicht verändern Startadressen des Moduladreßbereiches Schritt 1 Startadresse für die Diagnosedaten des Moduls Profibus DP Stationsadresse Schritt 2 Oben: Löschen der Ausgänge bei Busfehler Unten: Starten der Kommunikation bei Start des Automatisierungsgeräts Moeller XSystem - Grundlagen 27-Mar-17, Seite 10

Schritt 3 Einstellung der Baudrate für den gesamten Strang. Empfehlung: Automatische Optimierung ! Moeller XSystem - Grundlagen 27-Mar-17, Seite 11

Auswählen der Slave- Teilnehmer am Strang Schritt 4 Moeller XSystem - Grundlagen 27-Mar-17, Seite 12

Schritt 5 DP-Adresse einstellen Slave aktivieren Moeller XSystem - Grundlagen 27-Mar-17, Seite 13

Module auswählen Schritt 6 Doppelklick Moeller XSystem - Grundlagen 27-Mar-17, Seite 14

Schulungs - und Kommunikationszentrum Arbeitsblatt A101_701 Wählen Sie bei Ihrem XC-600 die Option „Autoconfig“ und lassen Sie das Gerät die eigene Konfiguration ermitteln. Überprüfen Sie die Konfiguration in der Anzeige der Bedieneinheit. Schalten Sie anschließend die Option „Autokonfig“ wieder ab. Was ist dabei zu beachten ? Bitte erstellen Sie die Steuerungskonfiguration für Ihre Steuerung XC-600. Berücksichtigen Sie dabei zunächst den Aufbau des zentralen Automatisierungsgerätes, also des „Turmes“ inkl. der Feldbuskarten und der lokalen XI/ON-Konfiguration. Für die XI/ON-Scheiben verwenden Sie bitte die typisierten Einträge; als generelle Einstellungen für XI/ON geben Sie bitte alle Diagnoseoptionen frei und definieren Sie die Ausgabe des Wertes „0“ für sämtliche Fehler- und Störungsfälle. Die Analogscheiben konfigurieren Sie bitte für 0..10V und für 15 Bit + Vorzeichen. Erstellen Sie anschließen auch die Konfiguration der dezentralen XI/ON-Station, die über Profibus DP angekoppelt ist. Die Station soll die Profibus-Adresse 2 bekommen und mit der maximal möglichen Baudrate angekoppelt werden. Die XI/ON-Scheiben sollen entsprechend den zentralen konfiguriert werden, nur daß die E/A-Punkte in Bytes zusammengepackt werden sollen. Was ist dafür zu tun ? Moeller XSystem - Grundlagen 27-Mar-17, Seite 15 PS: Hilfestellung zur Vorgehensweise bietet Ihnen der Fahrplan in den Seminarunterlagen.

Schulungs - und Kommunikationszentrum Arbeitsblatt A101_702 Schreiben Sie einen Funktionsbaustein „Lauflicht“ mit folgenden Merkmalen: An den IN_OUT-Parameter „output“ wird eine Byte-Variable angelegt, die mit einem beliebigen Bitmuster initialisiert ist. Dieses Bitmuster soll nun vom Funktionsbaustein verschoben (rotiert) werden, und zwar in dem durch den Eingangsparameter „period“ vorgegebenen Takt und in der durch den Parameter „direction“ vorgegebenen Richtung (0 = links, 1 = rechts). Instanzieren Sie diesen Baustein zweimal, einmal für ein Lauflicht auf den digitalen Ausgängen der DP-XI/ON-Station und einmal für die lokalen E/A. Die Laufrichtung wird durch den jeweils ersten verfügbaren Digitaleingang vorgegeben; die Taktgeschwindigkeit soll durch den jeweiligen Analogeingang per Potentiometer eingestellt werden. Für die ganz Schnellen: Erstellen Sie eine kleine Visualisierung für das Lauflicht. Verwenden Sie Platzhalter für alle Variablen, so daß Sie auch die Visualisierung entsprechend zweimal instanzieren können. Lauflicht BYTE output TIME period BOOL direction Moeller XSystem - Grundlagen 27-Mar-17, Seite 16

PROFIBUS-Nutzerorganisation PROFIBUS-Nutzerorganisation e. V. In der PROFIBUS-Nutzerorganisation in Deutschland (PNO) haben sich mehr als 180 Hersteller und Anwender des standardisierten Kommunikationssystems PROFIBUS (EN 50170) zusammengefunden, um gemeinsam die technische Weiterentwicklung sowie die internationale Durchsetzung zu fördern. Zweck und Aufgabe - Förderung der internationalen Verbreitung des Kommunikationssystems PROFIBUS - Pflege und Weiterentwicklung der PROFIBUS Technologie - Die PNO nimmt im Auftrag ihrer Mitglieder die Interessensvertretung gegenüber Normungsgremien und Verbänden wahr - Verkaufsförderung durch Pressearbeit - Profilbildung zur Vereinfachung der Handhabung von PROFIBUS durch den Anwender - Zertifizierung geprüfter Geräte, als Kennzeichnung der vollen Interoperabilität - Zusammenarbeit mit PROFIBUS Nutzerorganisationen in anderen Ländern. - Investitionsschutz für Anwender und Hersteller durch Einflußnahme auf die Standardisierung. Die Mitgliedschaft steht allen Firmen, Verbänden und Instituten offen, die die Interessen der PNO als Hersteller, Anwender, Systemhaus oder als Betreiber von PROFIBUS - Netzen unterstützen. Die PROFIBUS Nutzerorganisation e.V. ist Mitglied im internationalen Dachverband PROFIBUS International (PI), der mit 20 lokalen Organisationen und über 800 Mitgliedern die weltweit größte Interessengemeinschaft im Feldbussektor darstellt. Persönliche Bemerkungen: Moeller XSystem - Grundlagen 27-Mar-17, Seite 17

Steckbrief Profibus-DP
Zugriffsverfahren Master/Slave, Token Passing möglich deterministisch Topologie Linie, mit Repeater: Baum, Stern Übertragungsmedium Twisted Pair geschirmt, LWL Teilnehmerzahl 126 (31 ohne Repeater) Entfernung m; mit Repeater bis m Übertragungsrate 9,6 kbit/s / 19,2 / 93,75 / 187,5 / 500 / 1 500 / 12 Mbit/s Datenmenge pro Telegramm 244 Byte Datenverkehr zyklisch (und azyklisch mit DP V1) Normen EN 50170, DIN T3 Lobby Profibus Nutzerorganisation (PNO) mit über 170 Mitgliedern u.a. Bosch, Siemens, MOELLER, ABB Moeller XSystem - Grundlagen 27-Mar-17, Seite 18

Diagnoseinformation des Slaves (1) Master Slave DATA DIAG_DATA Data-Exchange DiagFlag 1. Master Slave DATA 1 DIAG_DATA Data-Exchange DiagFlag 2. Diagnoseinformation des Slaves (1) Zwischen einem PROFIBUS-DP-Master und einem zugeordneten Slave läuft ein zyklischer Datenverkehr „Data-Exchange“. Der Master schickt Nutzdaten zu einem Slave und der Slave schickt in seinem Antworttelegramm die Nutzdaten zu seinem Master. Jedes Nutzdatentelegramm eines Slaves enthält am Anfang ein sogenanntes Diag-Flag. Solange in einem Slave keine Diagnosedaten vorliegen, ist dieses Bit immer „0“. Tritt nun in einem Slave ein Fehler auf, setzt der Slave in seinem nächsten Antworttelegramm dieses Bit auf „1“. Nachdem der Master dieses erkannt hat, fordert er nun mit dem Kommando „Slave_Diag“ die Diagnosedaten des Slaves an. Der Slave schickt in seinem nächsten Antworttelegramm keine Nutzdaten sondern die Diagnosedaten einmalig zum Master. Damit liegt das Diagnosedatenfeld im Master vor und kann, zB. durch das SPS-Programm ausgewertet werden. Persönliche Bemerkungen: Master Slave Slave_Diag DIAG_DATA 1 3. Moeller XSystem - Grundlagen 27-Mar-17, Seite 19

Diagnoseinformation des Slaves (2) Master Slave 4. DATA DIAG_DATA Data-Exchange DIAG_DATA 1 DATA 1 DiagFlag Master Slave 5. DATA DIAG_DATA Data-Exchange DIAG_DATA 1 1 DATA DiagFlag Diagnoseinformation des Slaves (2) Sobald der Master das Diagnosedatenfeld empfangen hat, beginnt er wieder mit dem Nutzdatenaustausch „Data_Exchange“. Nachdem der Slave einmal das Diagnosedatenfeld zum Master übertragen hat, setzt er in seinem nächsten Antworttelegramm das Diag-Flag wieder auf „0“ (--> auch wenn der Fehler noch ansteht !). Erst wenn der Slave eine Änderung in seinen Diagnosedaten erkennt (also z.B. Fehler ist behoben), setzt er erneut das Diag-Flag. Der Master fordert darufhin erneut das Diagnosedatenfeld an, was dann wieder einmalig vom Slave übertragen wird. Für ein SPS-Programm bedeutet das, dass erneut eine Abfrage der Diagnosedaten erfolgen muss, um festzustellen, dass der Fehler behoben ist. Persönliche Bemerkungen: Master Slave 6. Slave_Diag DIAG_DATA DIAG_DATA DIAG_DATA Moeller XSystem - Grundlagen 27-Mar-17, Seite 20

Slave Diagnosedaten Byte-No Information DP-Master 1 Station_Status_1 2 Station_Status_2 3 Station_Status_3 Standard Diagnose 4 Diag_Master_Address 5 Ident_Number (high) EN50170 6 Ident_Number (low) 7 Block length (Bytes) 8 Diag Modul-No 9 Diag EM4 Slave Diagnosedaten Um die Buslast gering zu halten, transportieren die Slaves die Diagnosedaten nicht ständig zum Master, sondern nur einmalig wenn eine Änderung im Diagnosedatenfeld stattfindet. Das Diagnosedatenfeld kann (nach EN50170) eine Länge von 32 Bytes haben. Die ersten sieben Bytes des Diagnosedatenfeldes sind in der EN50170 festgelegt, die nachfolgenden Daten sind immer gerätespezifisch. Die Bytes 1-3 enthalten den Stations-Status (Status 1 - Status 3 ; siehe auch CFG-DP „Device Diagnostics“). Das Byte 4 enthällt die Adresse des Master, der das Diagnosedatefeld angefordert hat. In den Bytes 5 und 6 ist die Ident-Nummer des Slave eingetragen (High-Byte/Low-Byte). Die Daten ab Byte 7 werden auch als „Extended_Diag_Data“ bezeichnet. Byte 7 enthällt eine Längeninformation, d.h., der Eintrag in Byte 7 gibt an, wieviel Bytes Extended_Diag_Data benutzt werden.Wird ein EM4 mit LE‘s als PROFIBUS-DP - Slave benutzt, ist im Byte 8 bitcodiert das fehlerhafte Modul eingetragen (Bsp.: hat das EM4 einen Fehler ist Bit 0 an, hat das 3.LE einen Fehler ist Bit 3 an, ...). Im Byte 9 ist dann die Diagnoseinformation des EM4 enthalten, Byte enthalten die Diagnoseinformation für die LE‘s (falls angeschlossen). Persönliche Bemerkungen: 10 Diag 1.LE Ext_Diag_Data 11 Diag 2.LE Erweiterte Diagnose Gerätebezogen 12 Diag 3.LE 13 Diag 4.LE 14 Diag 5.LE 15 Diag 6.LE Moeller XSystem - Grundlagen 27-Mar-17, Seite 21

Diagnose der Buskommunikation
Startadresse für die Diagnosedaten des Moduls DP_STRANG AT % MB0 : GETBUSSTATE; Globale Variablenliste TYPE GETBUSSTATE: STRUCT BOLDENABLE : BOOL; ENABLE: BOOL; DRIVERNAME:POINTER TO STRING; DEVICENUMBER:INT; READY:BYTE; STATE:INT; EXTENDEDINFO:ARRAY[0..129] OF BYTE; END_STRUCT END_TYPE Das Anwenderprogramm zur Diagnose ist so aufzubauen, dass zunächst der lokale Strang, dann sukzessive die dezentralen Stränge nach Meldungen abgefragt werden. Voraussetzung dafür ist die BusDiag.LIB-Datei, die im Projekt eingebunden sein muß. Diese Datei enthält einen nicht sichtbaren Baustein, der vom Laufzeitsystem zyklisch aufgerufen wird. Die Ein- und Ausgangsdaten des Bausteins, auf die der Anwender zugreifen kann, werden in einem Datenfeld von 142 Byte gespeichert. Für jeden konfigurierten Strang wird vom System ein solches Datenfeld angelegt. Zur Erleichterung des Datenzugriffs sind die Ein-/Ausgangs-Daten in einer Struktur zusammengefaßt. Die Zuordnung zwischen dem Merkerbereich, beginnend mit der Diagnoseadresse, und der Struktur wird durch die Deklaration einer direkt adressierbaren Variablen vom Typ GETBUSSTATE getroffen (nicht taskgebunden), z.B.: DP_Strang AT %MB0: GETBUSSTATE; Es sind jedoch nur die Daten des (Struktur-) Ausgangs EXTENDEDINFO für den Anwender wichtig, da die einzelnen Byte dieses Ausgangs (Array[0..129]) die Diagnose der einzelnen Teilnehmer enthalten. Die Diagnoseadresse (Merkerbyte), ab der die Daten für das jeweilige Bussystem abgelegt werden, kann der Anwender der Steuerungskonfiguration entnehmen. Jedes Byte enthält die Diagnoseinformationen eines Teilnehmers. Sie sind in 3 Bit enthalten. Bit 0: 1 = Teilnehmer vorhanden Bit 1: 1 = Datenaustausch ok Bit 2: 1 = Diagnosedaten liegen vor Vom Anwender sind diese 3 Bit abzufragen. Byte 129 wird nur bei der Abfrage von PROFIBUS-DP-Teilnehmern verwendet. In diesem Fall enthält es die Anzahl der Teilnehmer, die Diagnosedaten melden. Moeller XSystem - Grundlagen 27-Mar-17, Seite 22

Schulungs - und Kommunikationszentrum Arbeitsblatt A101_703 Schreiben Sie einen Funktionsbaustein „line_diag“ mit folgenden Merkmalen: Der Funktionsbaustein soll für die lokale I/O-Konfiguration bzw. für einen angeschlossenen Feldbusstrang die Information liefern, wieviele Stationen derzeit an diesem Strang vorhanden sind und wieviele dieser Stationen derzeit aktiv Daten austauschen und/oder erweiterte Diagnoseinformationen liefern. An den Parameter vom Typ „VAR_IN_OUT“ wird das (globale) Feld des zu diagnostizierenden Stranges angelegt; die drei Ausgangsparamter liefern die gewünschten Informationen. Für die ganz Schnellen: Erstellen Sie einen Funktionsbaustein, der diese Informationen für jeweils einen Strang oder für die lokale Konfiguration auf dem Display des XC-600 darstellt. Wählen Sie dazu geeignete Abkürzungen. LINE_DIAG GETBUSSTATE Line_array number_diag number_stations USINT number_exchg Moeller XSystem - Grundlagen 27-Mar-17, Seite 23 PS: Informationen zu den Feldern vom Typ GETBUSSTATE und deren Inhalt finden Sie in den Seminarunterlagen oder in der XSoft-Hilfe.

Diagnose der Buskommunikation
Die weitergehende Diagnose erfolgt dann mit Hilfe des Bausteins „DiagGetState“. Dieser Funktionsbaustein läßt sich sowohl für lokale XI/ON-Konfigurationen als auch für die dezentralen Netzwerkanschaltungen Profibus DP und CANopen verwenden. Der Baustein liefert als Ergebnis ein Feld (ARRAY) mit 100 Elementen vom Typ BYTE. In diesen 100 Bytes sind sowohl die jeweils in den Spezifikationen festgelegten Standard-Diagnoseinformationen des Profibus DP oder CANopen enthalten als auch die zusätzlichen herstellerspezifischen Diagnoseinformationen. Das zu diagnostizierende Bussystem wird über die Angabe am Parameter „Drivername“ ausgesucht, der Steckplatz des jeweiligen Kommunikationsmoduls über den Parameter „Devicenumber“ angegeben. Eine umfassende Diagnose läßt sich also programmieren, indem man mit einer Schleife das Standardfeld vom Typ „GETBUSSTATE“ auf Stationen und Stationen mit Diagnose abfragt und dann den Funktionsbaustein gezielt zur Abfrage dieser Diagnose nutzt. Moeller XSystem - Grundlagen 27-Mar-17, Seite 24

Schulungs - und Kommunikationszentrum Arbeitsblatt A101_704 Schreiben Sie ein Programm „kurzschluss“, in dem Sie den Funktionsbaustein vom Typ „DiagGetState“ verwenden, um einen Kurzschluß am ersten Digitalausgang der Profibus-DP-XI/ON-Station feststellen zu können. Die Beschreibung des Funktionsbausteins und seiner Parameter entnehmen Sie bitte dem ausgehändigten Info-Blatt. Gestalten Sie das Programm außerdem so, daß ein entsprechender Fehlertext auf der Anzeige der Bedieneinheit des XC-600 eingeblendet wird, wenn der Kurzschluß am ersten Digitalausgang auftaucht. Tip: Bitte bedenken Sie bei der Auswertung der Informationen im Feld „EXTENDEDINFO“, daß die digitalen Eingangsmodule von XI/ON keine erweiterte Diagnose liefern. Moeller XSystem - Grundlagen 27-Mar-17, Seite 25 PS: Informationen zu den Feldern vom Typ GETBUSSTATE und deren Inhalt finden Sie in den Seminarunterlagen oder in der XSoft-Hilfe.

Schulungs - und Kommunikationszentrum Arbeitsblatt A101_705 Erstellen Sie eine Visualisierung für jeweils einen Teilnehmer am PROFIBUS DP-Strang, in der folgende Informationen dargestellt werden: Stationsnummer des Slaves Configuration OK Datenaustausch erfolgt Diagnose liegt vor Diagnosetext Verwenden Sie Platzhalter für die Bezeichnung der relevanten Variablenbestandteile, so daß Sie anschließend diese Stationsvisualisierung mehrmals in einer Visualisierung für den ganzen Strang instanzieren können. Moeller XSystem - Grundlagen 27-Mar-17, Seite 26 PS: Informationen zu den Feldern vom Typ GETBUSSTATE und deren Inhalt finden Sie in den Seminarunterlagen oder in der XSoft-Hilfe.

Moeller XSystem - Grundlagen

Ähnliche Präsentationen

Präsentation zum Thema: "Moeller XSystem - Grundlagen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Moeller XSystem - Grundlagen

Ähnliche Präsentationen

Präsentation zum Thema: "Moeller XSystem - Grundlagen"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback