Buslast bestimmen – BECKHOFF FC5101 Benutzerhandbuch
Seite 50
Eiserstraße 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149
50
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 und spätestens nach Verstrei-
chen des Ablauf-Timers erneut gesendet.
·
Parametriert wird die Kommunikationsart über den Transmission Type.
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 kombi-
niert man die Vorteile beider Prinzipien: Synchronität der Achskommunikation und kurze Reaktionszeit für End-
schalter. Durch die dezentrale Grenzwertüberwachung wird trotz Ereignissteuerung vermieden, dass der Tem-
peratur-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 End-
schalterdaten, die niedrigste das mit den Temperaturwerten.
In aller Regel ist es aber nicht erforderlich, die Identifier-Verteilung anzupassen, um die Latenzzeit beim Bus-
zugriff zu optimieren. Dagegen müssen die Identifier verändert werden, um eine masterlose Kommunikation zu
ermöglichen (PDO Linking). 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 da-
durch 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 wer-
den; 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äte-
anbietern 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 Rei-
henfolge 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 Fehlermel-
dungen, 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 angenom-
men 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 PC Karten FC510x zeigen die Buslast über den System Manager ein. Diese Variable kann auch
in der SPS verarbeitet oder in der Visualisierung zur Anzeige gebracht werden.
Neben den Kommunikationsparametern ist natürlich die Datenbelegung der Prozessdatenobjekte entschei-
dend: das PDO Mapping.