Printed in the Federal Republic of Germany
TR-Electronic GmbH 2018, All Rights Reserved
08/29/2018
TR - ELA - BA - DGB - 0029 - 00
Page 51 of 111
8.3.4 Kollisionen
●
Fehlerquelle
Die Anzahl der Hubs im EPL Netzwerk kann die in IEEE 802.3 definierten
Anforderungen für Verzögerungsschwankungen nicht erfüllen. Grund hierfür sind
der Einsatz von Standard Ethernet-Controllern nach IEEE 802.3, welche
Kollisionen nur in bestimmten Fällen erkennen können.
Ethernet POWERLINK hängt nicht von der Feststellung von Kollisionen ab.
Im
NMT_CS_PRE_OPERATIONAL_1
,
NMT_CS_PRE_OPERATIONAL_2
,
NMT_CS_READY_TO_OPERATE
und im Zustand
NMT_CS_OPERATIONAL
sollten
aufgrund des EPL Zyklusaufbaus keine Kollisionen auftreten. Wenn ein Knoten
diese Anforderungen nicht erfüllt, dann können der Determinismus und die präzise
Synchronisierung nicht mehr garantiert werden. Trotzdem können bei falscher
Konfiguration und einem defekten Knoten Kollisionen auftreten.
●
Fehlererkennung
Wenn der Ethernet Controller eine Kollision im EPL Netzwerk feststellt, wird der
Standard Ethernetablauf für Kollisionen gestartet.
●
Fehlerabwicklung
Wenn ein Kollisions-Fehler erkannt wurde, wird dieser als Error Code im
StatusResponse-Frame eingetragen und an den MN übermittelt. Die
Fehlerauslösung wird über den Threshold Counter Mechanismus im Objekt
1C0Ah: DLL_CNCollision_REC vorgenommen. Wenn der Grenzwertzähler den
Grenzwert erreicht, wird die Fehlerquelle von der CN NMT-Zustandsmaschine als
„Internal Communication Error“ (NMT_GT6) behandelt und das Mess-System in
den Zustand
NMT_GS_RESET_APPLICATION
überführt.
●
Fehlermeldung
Über den internen Fehlerfunktionsmechanismus wird der Fehler in das so
genannte „Static Error Bit Field“ eingetragen und stellt ein Fragment des
StatusResponse-Frames dar.
Format:
Byte Offset
Beschreibung
1
Inhalt aus Objekt 1001h: ERR_ErrorRegister_U8, 0x01
2
reserved
3-8
Error Code = 0x8163
Tabelle 14: Static Error Bit Field, Fragment des StatusResponse-Frames
