Werbung
Produktübersicht
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.
Neben den Kommunikationsparametern ist natürlich die Datenbelegung der Prozessdatenobjekte
entscheidend: das PDO Mapping. [} 32]
4.7.4
Servicedatenobjekte (SDO)
Die im Objektverzeichnis aufgeführten Parameter werden über Servicedatenobjekte gelesen und
beschrieben. Diese SDOs sind Multiplexed Domains, also Datenstrukturen beliebiger Größe, die mit einem
Multiplexor (Adresse) versehen sind. Der Multiplexor besteht aus 16-Bit-Index und 8-Bit-Subindex, die die
entsprechenden Einträge im Objektverzeichnis adressieren.
CX7050
Version: 1.0
35
Werbung
