Beckhoff BX5100 Dokumentation Seite 151

dann entsprechende Verzögerungszeiten einstellen können, bis ein relativ niederpriores PDO
verschickt werden kann - eine seriöse Netzwerkplanung erfordert demnach eine worst-case
Betrachtung. Auch muss, z. B. durch Verwendung der Inhibit Zeit [} 143], verhindert werden, dass ein
sich ständig ändernder Eingang mit hoher PDO-Priorität den Bus blockiert (Fachbegriff: "babbling
idiot"). Aus diesem Grund ist beispielsweise die Ereignissteuerung bei Analogeingängen im
Geräteprofil per Default abgeschaltet und muss gezielt aktiviert werden. Über den Ablauf-Timer lassen
sich Zeitfenster für die Sende-PDOs einstellen: Das Telegramm wird frühestens nach Ablauf der
Inhibit-Zeit [} 143] und spätestens nach Verstreichen des Ablauf-Timers erneut gesendet.
• Parametriert wird die Kommunikationsart über den Transmission Type [} 143].
Es ist auch möglich, beide PDO Kommunikationsprinzipien zu kombinieren. So kann es beispielsweise
sinnvoll sein, die Soll- und Istwerte einer Achsregelung zyklisch synchron auszutauschen, während
Endschalter oder die mit Grenzwerten versehene Motortemperatur mit ereignisgesteuerten PDOs überwacht
werden. So kombiniert man die Vorteile beider Prinzipien: Synchronität der Achskommunikation und kurze
Reaktionszeit für Endschalter. Durch die dezentrale Grenzwertüberwachung wird trotz Ereignissteuerung
vermieden, dass der Temperatur-Analogwert ständig zur Buslast beiträgt.
Im genannten Beispiel kann es auch sinnvoll sein, die Identifier-Verteilung gezielt zu beeinflussen, um den
Buszugriff durch die Prioritätsverteilung zu optimieren: die höchste Priorität bekommt das PDO mit den
Endschalterdaten, die niedrigste das mit den Temperaturwerten.
In aller Regel ist es aber nicht erforderlich, die Identifier-Verteilung anzupassen, um die Latenzzeit beim
Buszugriff zu optimieren. Dagegen müssen die Identifier verändert werden, um eine masterlose
Kommunikation zu ermöglichen (PDO Linking [} 143]). Im genannten Beispiel könnte je ein RxPDO der
Achsen denselben Identifier wie das TxPDO des Endschalters zugewiesen bekommen und dadurch eine
Veränderung des Eingangswertes verzögerungsfrei empfangen.
Buslast bestimmen
In jedem Fall ist es sinnvoll, die Buslast zu bestimmen. Doch welche Buslastwerte sind zulässig bzw.
sinnvoll? Unterscheiden sollte man zunächst den kurzfristigen Burst von Telegrammen, bei dem eine Anzahl
CAN-Nachrichten direkt aufeinander folgt - kurzzeitig 100% Buslast. Das ist nur dann problematisch, wenn
die dadurch ausgelöste Folge von Empfangsinterrupts auf den CAN-Knoten nicht mehr abgearbeitet werden
kann, es also zu einem Datenüberlauf (CAN-Queue-Overrun) kommt. Das kann bei sehr hohen Baud-Raten
(> 500 kBit/s) bei Knoten mit Software-Telegrammfilterung und relativ langsamen oder stark ausgelasteten
Mikro-Controllern vorkommen, wenn z. B. eine direkte Folge von Remote Frames (diese enthalten keine
Datenbytes und haben daher minimale Länge) auf dem Bus ist (bei 1 Mbit/s kann so alle 40 µs ein Interrupt
erzeugt werden; Beispiel: ein NMT-Master sendet alle Guarding-Anforderungen direkt hintereinander). Durch
geschickte Implementierung läßt sich das vermeiden, der Anwender sollte davon ausgehen können, dass
von den Geräteanbietern hierfür Sorge getragen wurde. Ein Burst-Zustand ist z. B. direkt nach dem SYNC
Telegramm völlig normal: vom SYNC getriggert versuchen alle synchron arbeitenden Knoten quasi
gleichzeitig Ihre Daten zu senden, es finden viele Arbitrierungsvorgänge statt, die Telegramme sortieren sich
nacheinander in der Reihenfolge ihrer Priorität auf den Bus. Das ist in der Regel unkritisch, da es sich hier
um Telegramme mit einigen Datenbytes handelt und die Telegrammfolge damit zwar eine schnelle, aber
überschaubare Folge von Empfangsinterrupts auf den CAN-Knoten auslöst.
Unter Buslast versteht man meist den gemittelten Wert über mehrere Primärzyklen, also z. B. das Mittel über
100-500 ms. CAN, und damit CANopen, ist zwar in der Lage, nahe 100% Buslast auf Dauer zu bewältigen,
aber dann steht keine Bandbreite für eventuelle Wiederholungen bei Störeinflüssen, asynchrone
Fehlermeldungen, Parametrierung etc. zur Verfügung. Selbstverständlich hat die vorherrschende Art der
Kommunikation einen großen Einfluss auf die sinnvolle Buslast: ein komplett zyklisch synchron arbeitendes
Netz befindet sich ja bereits nahe am worst case Zustand und kann daher mit Werten von 70-80% betrieben
werden. Für ein rein ereignisgesteuertes Netz ist diese Zahl nur schwer anzugeben: es muss hier
abgeschätzt werden, wie viele zusätzliche Ereignisse im Vergleich zum derzeitigen Anlagenzustand
auftreten können und für wie lange das zu einem Burst führt - also wie lange die relativ niederpriorste
Nachricht dann verzögert würde. Ist dieser Wert von der Applikation her zulässig, so ist die aktuelle Buslast
akzeptabel. Als Näherungswert kann meist angenommen werden, dass ein ereignisgesteuertes Netz mit
30-40% Grundlast genügend Reserven für worst-case-Szenarien hat - diese Annahme macht aber eine
sorgfältige Analyse nicht überflüssig, wenn Verzögerungen zu kritischen Anlagenzuständen führen können.
Die BECKHOFF CANopen-Master-Karten FC510x / CANopen-Masterklemme EL6751 zeigen die Buslast
über den System Manager ein. Diese Variable kann auch in der SPS verarbeitet oder in der Visualisierung
zur Anzeige gebracht werden.
BX5100 Version: 2.2.0
CANopen Kommunikation
151