Profibus-DP

1 Profibus-DP Telegrammarten Ein Profibus-Telegramm besteht aus dem Telegrammheader, den Nutzdaten, einem Sicherungsbyte und dem End-Delimiter (Ausnahme: Tokentelegramm) SD1 = Telegramm ohne Daten SD1 DA SA FC FCS ED 10H xx xx xxH x 16H Die aktive Station (SA) sucht nach neuen Teilnehmern am Bus. SD2 = Telegramm mit variebler Datenl nge SD2 LE LEr SD2 DA SA FC DSAP SSAPDU FCS ED 68H x x 68H xx xx x x x x 16H Es werden Daten (DU) vom Sender (SA) an die Empfangsstation (DA) bermittelt.

2 SD3 = Telegramm mit fester Datenfeldl nge SD2 DA SA FC DU FCS ED A2H xx xx x x 16H Die Daten (DU) haben immer eine L nge von 8 Byte. SD4 = Tokentelegramm SD2 DA SA DCH xx xx Telegramm zwischen 2 aktiven Busteilnehmern zum Erteilen der Buszugriffsberechtigung. SD: Start Delimiter, zur Unterscheidung des Telegrammtyps LE: L nge der Nettodaten inkl. DA, SA, FC, DSAP, SSAP LEr: Wiederholung (repeated) von LE FC: Function Code, Kennzeichnung des Telegrammtyps (Aufruf-, Quittungs-, Antworttelegramm, Anzeige von Fehlern) DA: Destination Address, Zieladresse SA: Source Address, sendende Station DSAP: Destination Service Access Point, welcher Dienst soll ausgef hrt werden SSAP: Source Service Access Point DU: Data Unit, Nettodaten (1.)

3 246 Byte) FCS : Frame Checking Sequence, Pr fsumme ED: End Delimiter Kurzquittung SC E5H Wichtige Dienste, deren Bedeutung und Kennzeichnung Bei Profibus gibt es Dienstzugangspunkte (SAP), sie sind in den Bytes DSAP oder SSAP vermerkt. Default-SAP = 0 Datenaustausch (Write_Read_Data) SAP 54 Master-Master-Kommunikation SAP 55 ndern der Stationsadresse (Set_Slave_Add) SAP 56 Lesen der Eing nge (Rd_Inp) SAP 57 Lesen der Ausg nge (Rd_Outp) SAP 58 Steuerkommandos an den Slave (Global_Control) SAP 59 Konfigurierdaten lesen (Get_Cfg) SAP 60 Diagnoseinformation lesen (Slave_Diagnosis) SAP 61 Parametrierdaten senden (Set_Prm) SAP 62 Konfigurierdaten pr fen (Chk_Crg)

4 Innerhalb der Nutzdaten (DU) k nnen noch folgende, wichtige Dienste bekannt gegeben werden. Freeze-Mode - Wird als Multicast-Telegramm verschickt - Eingangsdaten der Slaves werden eingefroren - Serielles bertragen aller Eingangsdaten an den Master mit Data_Exchange Sync-Mode - Wird als Multicast-Telegramm verschickt - Die betreffenden Slaves geben ihre Ausgangsdaten erst nach Erhalt des Kommandos an ihre Ausgangsports - Serielles bertragen aller Ausgangsdaten an den Master mit Data_Exchange Fehlererkennung und Behandlung Datensicherung mit Paritybit und Pr fsumme Hamming-Distanz d = 4 (maximal 3 Fehler im Telegramm werden sicher erkannt)

5 Aufrufe, die als fehlerhaft erkannt wurden, werden verworfen und m ssen wiederholt werden Gest rte Antworten bedingen ebenfalls die Wiederholung des Aufrufs Antwortet ein Teilnehmer nicht, erfolgt eine Markierung (nicht funktionsf hig). Antwortet er beim n chsten Aufruf ordnungsgem , wird er wieder als funktionsf hig betrachtet. Paritybit, Parit tsbit Verwendung eines redundanten Codes, der nicht alle m glichen Codew rter ausnutzt. Das Anf gen eines Parit tsbits gibt bei einem Minimalcode die M glichkeit der Erkennung eines Fehlers. Durch das Parit tsbit wird die Quersumme, auch das Gewicht (Zahl der Einsen) eines Codewortes genannt, vereinbarungsgem einheitlich auf eine gerade oder ungerade Zahl erg nzt.

6 Beispiel f r ein 4bit Code, das 5. Bit ist das Parit tsbit z d3 d2 d1 d0 P 0 0 0 0 0 0 1 0 0 0 1 1 2 0 0 1 0 1 3 0 0 1 1 0 4 0 1 0 0 1 5 0 1 0 1 0 9 1 0 0 1 0 10 1 0 1 0 0 11 1 0 1 1 1 12 1 1 0 0 0 Pr fsumme Jedem Record wird eine 8-Bit-Pr fsumme hinzugef gt. Alle Datenbytes, zum Teil auch Bytes des Rahmens, werden modulo-256 ausummiert.

7 Modulo-256 bedeutet dabei, dass bei jeder Summation der bertrag in das Bit mit der Wertigkeit 256 einfach ignoriert wird. Die entstandene 8 Bit lange Pr fsumme wird vom Sender ins Telegramm eingef gt. Der Empf nger pr ft die empfangenen Daten und f hrt die selbe Addition durch. Die Pr fsumme muss gleich sein. bertragung Asynchrone bertragung Jedes Byte im Telegramm ist als UART-Zeichen mit Start-, Parity- und Stopbit eingerahmt. UART: universal asynchronous receiver transmitter bertragungseffizienz Verh ltnis von Nutzdaten zu gesamt bertragenen Daten Mittlere Effektivit t Maximum 70% Minimum 0,6% Projektierung Projektierung mittels Projektierungstools ber den Profibus-Master Geringer Aufwand f r eine Slave-Realisierung Kombil sungen und L sungen vorhanden Breite Marktakzeptanz Kosten pro Anschaltung (Ger t)

8 150 1500 DM Adressierung der Teilnehmer Slave-Adressen k nnen ber den Master ge ndert werden Tokenmanagement IM Besitz des Tokens f hrt der Master zun chst den hochprioren Datenverkehr durch. Anschlie end berpr ft er die verbleibende Token-Haltezeit f r den niederprioren Datenverkehr. Nach Beendigung des niederprioren Datenverkehrs und noch verbleibender Haltezeit,sucht der Master nach neuen Teilnehmern. Nachdem der Tokenhalter seinen Datenverkehr beendet hat oder die Token-Haltezeit abgelaufen ist, versucht er den Token an die n chste Station weiterzugeben. Klassifizierung der Teilnehmer und deren Aufgaben Unterteilung in Klasse 1-Master, Klasse 2-Master und Slave Klasse 1-Master.

9 - autark arbeitende Baugruppe innerhalb einer SPS, sie stellt der CPU ihre Daten zur Verf gung - CPU-Baugruppe - Standard-PC-Baugruppe - Stand-alone-board - Projektierung mittels Projektierungstools - Einlesen der Parameters tze - Token-Management - Initialisiert den logischen Ring - Erster gefundener Teilnehmer wird als n chste Station (NS) in Liste aufgenommen - Im Besitz des Tokens erfolgt Nutzdatenverkehr - Hochpriorer Datenverkehr - Niederpriorer Datenverkehr - Suche nach neuen Teilnehmern im GAP-Bereich - GAP-Bereich: eigene Adresse+1 bis zur Adresse der n chsten Station - Abgabe des Token an n chste Station (wenn erfolglos an bern chste Station) - Fehlerbeherrschung Klasse 2-Master - Anwender kann sich ber Klasse 2-Master ber den Zustand der Slaves informieren und in den Prozess eingreifen - Dient der Entlastung des Klasse 1-Master Slave - Intelligente Feldger te (Sensoren, Aktoren) - Ger te zum Bedienen und Beobachten - SPS, PNK