Herunterladen Diese Seite drucken

ABB ProcessMaste FEX300 Schnittstellenbeschreibung Seite 57

Werbung

Alarm Behandlung
Der Parameter DIAG_WORST_COND gibt bei mehreren aktiven herstellerspezifischen Alarmen
die Namur Alarm Gruppe und Klasse des Alarms mit der höchsten Priorität an.
DIAG_EXT_HISTORY enthält alle Vergangenheitsinformationen der herstellerspezifischen
Alarme. Die Größe und Anordnung der Bits entspricht exakt dem DIAGNOSIS_EXTENSION
Parameters (0 = Alarm war nie aktiv, 1 = Alarm war aktiv).
Mit
Hilfe
des
Parameters
DIAG_CONDITION_IDX
ist
es
möglich
zusätzliche
Vergangenheitsinformationen für einen Alarm abzurufen. Jeder herstellerspezifische Alarm
besitzt eine eindeutige Alarm ID (siehe Alarmübersicht des FEX300 / FEX500). Diese Alarm ID
wird in den Parameter DIAG_CONDITION_IDX geschrieben, um dann mit DIAG_DETAILS
zusätzliche Informationen wie Anzahl des Auftretens, Dauer des Alarms sowie letztes Auftreten
zu erhalten.
Alle
Vergangenheitsinformationen
können
mit
dem
Parameter
DIAG_CLEAR_ALARM_HISTORY gelöscht werden.
Mit
dem
Parameter
DIAG_ALARM_SIMULATION
wird
angegeben,
welcher
herstellerspezifische Alarm simuliert werden soll. Die Reaktion auf das System ist identisch zu
einem realen Alarm, mit dem einzigen Unterschied, dass simulierte Alarme nicht in der Historie
auftauchen.
Um dem Anwender die Möglichkeit zu geben zu entscheiden, welche Alarm Bits genutzt werden
oder nicht, wurden im Physical Block Parameter (Rel. Index 42 bis 49) zur Maskierung einzelner
Alarme bzw. Alarmgruppen angelegt.
Hinweis: Bei den Profilen 0 x 9740 und 0 x 9700 wird DIAGNOSIS_EXTENSION nicht im
GetDiag-Telegramm übertragen. Damit kann der Master am GetDiag-Telegramm nicht
erkennen, ob im Messumformer eine Simulation aktiv ist. Dies kann dann z. B. durch
azyklisches Lesen von DIAGNOSIS_EXTENSION aus dem Physical Block erkannt werden.
COM/FEX300/FEX500/PB-DE
FEX300, FEX500
57

Werbung

loading