PROFIBUS Handbuch

Alle für die geregelte Abwicklung der Kommunikation notwendigen Zustände der MAC-Steuerung gehen aus der untenstehenden Abbildung hervor.  Da die jeweili­gen Zustände in der Norm (IEC 61158-4-3 Abschnitt 8.2) ausführlich beschrieben sind, soll hier nur ein grober Überblick gegeben werden.

Nach dem Einschalten der Betriebsspannung (Power ON) gelangen sowohl aktive als auch passive Busteilnehmer in den Zustand 0ffline, führen einen Selbsttest durch und laden die für die Kommunikation notwendigen Betriebsparameter.  Passive Teilnehmer gehen danach in den Zustand Passive Idle, in dem sie nach Aktivieren ihres Empfängers die Leitung passiv abhören.  Falls Telegramme mit der eigenen Stationsadresse erkannt werden, müssen sie von der Station ordnungsgemäss quittiert werden.

Aktive Busteilnehmer nehmen nach dem Zustand Offline den Zustand Listen Token ein, falls sie für die Aufnahme in den logischen Ring bereit sind. Im Zustand Listen Token hört der Teilnehmer die Telegramme auf der Busleitung ab und baut aus den empfangenen Token-Telegrammen zunächst eine Liste der bereits akti­ven Teilnehmer (LAS: List of Active Stations) auf.  Nach dem Aufbau der LAS muss die Station warten, bis sie von der Vorgängerstation mit einem "Request FDL-Status" angesprochen und in den logischen Ring "eingeladen" wird.  Der "Neuling" quittiert mit einem "bereit für den Ring" und geht über in den Zustand Active Idle.  Er ist somit offizieller Teilnehmer im Ring.  In diesem Zustand hört er die Leitung ab, quittiert und antwortet ebenso wie ein passiver Teilnehmer im Zustand Passive Idle.  Der aktive Teilnehmer wechselt nach Erhalt eines an ihn gerichteten Token-Telegramms in den Zustand  Use Token. Erhält der aktive Teilnehmer über längere Zeit kein Token­Telegramm, so geht er in den Zustand Claim Token, um den logischen Ring neu zu initialisieren bzw. zu reinitialisieren (Im letzteren Fall behält die LAS ihre Gültigkeit).

Bild 122: FDL Zustandsdiagramm

Im Normalfall kommt jedoch der aktive Teilnehmer innerhalb einer bestimm­ten Zeit in den Besitz des Token-Telegramms, so dass, nachdem im Zustand Check Access Time die noch zur Verfügung stehende Token-Haltezeit über­prüft wurde, im Use Token-Zustand Nachrichtenzyklen abgewickelt werden können.  Wird zur Kommunikation ein Dienst mit Rückantwort verwendet, geht der Teilnehmer in den Zustand Await - Data - Response und wartet für die Slot-Time (abhängig von der Bitrate) auf eine Rückmeldung.  Bleibt die erwartete Antwort aus, so wird nach einer durch den Parameter max_retry_limit bestimmten Anzahl von nochmaligen Sendeversuchen eine Fehlermeldung an den User aus­gelöst.

Nachrichtenzyklen können so lange abgewickelt werden, bis die Token-Halte­zeit abgelaufen ist.  Danach wechselt der Teilnehmer in den Zustand Pass Token, in welchem der Token an den nächsten aktiven Teilnehmer weiterge­geben wird.  Die Übergabe wird im Zustand Check Token Pass überwacht. Geht bei der Tokenweitergabe etwas schief, weil sich z.B. der Nachfolger nicht meldet, wechselt der Teilnehmer in den Await - Status - Response ­Zustand über und wartet dort eine bestimmte Zeit auf ein Quittungssignal.  Kommt dieses Signal nicht, wird der Aufruf im Pass Token - Zustand wieder­holt.  Erhält der Teilnehmer ein anderes Telegramm (Situation bei Mehr­fachtoken), geht er in den Zustand Active Idle über. Nach der - normalerweise fehlerfreien - Tokenweitergabe befindet sich der Teilnehmer bis zum nächsten Empfang des Tokens im Zustand Active Idle.