Dezentrale Lösungen: Messen, Steuern Und Regeln
Dezentrale Lösungen: Messen, Steuern Und Regeln
Dezentrale Lösungen
Varianten Art.-Nr.
EMD-XIO CAN 104 16/16 4A 10849802
EMD-XIO CAN 104 8/8 4A 10849804
Zubehör Art.-Nr.
Schraubklemmensatz XIO 104 10870293
24 V PC-Netzteile Seite 137
Dezentrale Lösungen
Dezentrale Lösungen
Schaltfrequenz 11 GND
Dezentrale Lösungen
HINWEIS:
Pro PIN ist nur eine Funktion möglich!
Dezentrale Lösungen
Dezentrale Lösungen
S3 S2 S1 Bitrate
- off off 125 kBit
- off on 250 kBit
- on off 500 kBit
- on on 1 MBit
S6 S5 S4 S3 S2 S1 Knotenadresse S6 S5 S4 S3 S2 S1 Knotenadresse
off off off off off off 0 on off off off off off 32
off off off off off on 1 on off off off off on 33
off off off off on off 2 on off off off on off 34
off off off off on on 3 on off off off on on 35
off off off on off off 4 on off off on off off 36
off off off on off on 5 on off off on off on 37
off off off on on off 6 on off off on on off 38
off off off on on on 7 on off off on on on 39
off off on off off off 8 on off on off off off 40
off off on off off on 9 on off on off off on 41
off off on off on off 10 on off on off on off 42
off off on off on on 11 on off on off on on 43
off off on on off off 12 on off on on off off 44
off off on on off on 13 on off on on off on 45
off off on on on off 14 on off on on on off 46
off off on on on on 15 on off on on on on 47
off on off off off off 16 on on off off off off 48
off on off off off on 17 on on off off off on 49
off on off off on off 18 on on off off on off 50
off on off off on on 19 on on off off on on 51
off on off on off off 20 on on off on off off 52
off on off on off on 21 on on off on off on 53
off on off on on off 22 on on off on on off 54
off on off on on on 23 on on off on on on 55
off on on off off off 24 on on on off off off 56
off on on off off on 25 on on on off off on 57
off on on off on off 26 on on on off on off 58
off on on off on on 27 on on on off on on 59
off on on on off off 28 on on on on off off 60
off on on on off on 29 on on on on off on 61
off on on on on off 30 on on on on on off 62
off on on on on on 31 on on on on on on 63
Dezentrale Lösungen
HINWEIS:
Für die elektromagnetische Verträglichkeit des Gesamtsystems, in welches die Steuerung integriert wird, ist derjenige
verantwortlich, der die Gesamtanlage in Verkehr bringt.
HINWEIS:
Technische Änderungen, die eine Verbesserung der Qualität bewirken, behalten wir uns vor.
Dezentrale Lösungen
CAN-Bus-Pegel
Bei CAN werden die Buspegel dominant und rezessiv unterschieden. Der dominante
Buspegel überschreibt den rezessiven. Wenn gleichzeitig von verschiedenen
Busstationen dominante und rezessive Buspegel gesendet werden, stellt sich am Bus
der dominante Pegel ein. Der rezessive Pegel ist dann am Bus vorherrschend, wenn
alle Bus-Teilnehmern im Zustand rezessiv, bzw. inaktiv sind.
Der rezessive Pegel hat den Wert logisch 1; der dominante den logischen Wert 0.
Wenn kein Teilnehmer sendet ist der Buspegel rezessiv.
Dezentrale Lösungen
Dezentrale Lösungen
CAN (Controller Area Network) wurde ursprünglich nur für den Austausch von Informationen innerhalb eines Kraftfahrzeuges
entwickelt. So sollte damit z. B. der Schaltvorgang verbessert werden, in dem das Getriebe dem Motormanagement über CAN
einen Schaltwunsch mitteilt. CAN wurde also konzipiert, kurze Botschaften unter Echtzeitbedingungen auszutauschen. Das ist
auch eine typische Aufgabenstellung bei Maschinensteuerungen in der Automatisierungstechnik.
Die Textilmaschinenindustrie zählt zu den CAN-Pionieren. Bereits 1990 rüstete ein Hersteller seine Webmaschinen mit modu-
laren Steuerungssystemen aus, die in Echtzeit über ein CAN-Netz kommunizieren. Inzwischen haben sich mehrere Hersteller von
Textilmaschinen in der „CAN Textfile Users Group“ zusammengeschlossen. Diese Gruppe ist ihrerseits wiederum Mitglied in der
internationalen Anwender- und
Herstellervereinigung „CAN in Automation“ (CiA). In den USA setzen mehrere Konzerne CAN in Produktionsanlagen und Werk-
zeugmaschinen als anlagen- bzw. maschineninternes Bussystem zur Vernetzung von Sensoren und Aktoren ein, unter anderem
Honeywell, Allen-Bradley, Coca-Cola und United Parcel Services. Einige Anwender, z. B. aus der Medizintechnik, entschieden
sich für CAN, weil sie besonders
hohe Sicherheitsanforderungen zu erfüllen haben. Ähnliche Probleme haben Hersteller von sicherheitsempfindlichen oder hoch-
verfügbaren Maschinen und Anlagen zu lösen (z.B. Roboter und Transportsysteme).
Die äusserst interessanten technischen Eigenschaften von CAN, in Verbindung mit seinem niedrigen Preis, der sicherlich aus den
hohen Stückzahlen bei der Verwendung im Automobilbau resultiert, sorgten dafür, dass CAN auch in der Automatisierungstech-
nik zu einem weltweit akzeptierten Bussystem wurde. Bei CAN werden gleichberechtigte Stationen (Steuergeräte, Sensoren und
Aktoren) über einen
seriellen Bus miteinander verbunden. Die Busleitung selbst ist eine symmetrische Zweidrahtleitung, die je nach Anforderung
geschirmt oder ungeschirmt ausgelegt wird. Die elektrischen Parameter der physikalischen Übertragung sind in ISO 11898 fest-
gelegt. CAN zeichnet sich, Dank seines robusten Protokolls und Chips durch Unempfindlichkeit gegenüber hohen Temperaturen
und Störfeldern, aus. Ebenso
zeichnet sich CAN durch ein besonders robustes Netzverhalten (Hammingdistanz = 6) aus. Neben der hohen Übertragungssi-
cherheit sind die niedrigen Anschlusskosten pro Teilnehmer häufig ein ausschlaggebendes Argument für CAN. In preiskritischen
Anwendungen ist die Verfügbarkeit von CAN-Chips verschiedener Hersteller eine wesentliche Voraussetzung. Alle sind natürlich
zu der Spezifikation und den OSIStandardschichten 1 und 2 kompatibel. Nicht zuletzt ist auch die Kompaktheit der Controller-
Chips ein wichtiges Argument, z. B. im Bereich von Niederspannungsschaltgeräten.
Bei einer CAN-Datenübertragung werden keine Stationen adressiert, sondern Nachrichten. Diese „Adressen“, auch Identifier ge-
nannt, sind netzweit eindeutig gekennzeichnet. Neben der Adresskennzeichnung legt der Identifier auch die Priorität der Nach-
richt fest. Dies ist für die Buszuteilung entscheidend, wenn mehrere Stationen um das Buszugriffsrecht konkurrieren. Um alle
Übertragungsanforderungen eines CANNetzes, unter Einhaltung der Latenzzeit-Bedingungen bei möglichst geringer Datenrate
abarbeiten zu können, muss das CAN-Protokoll ein Buszuteilungsverfahren (Arbitrierung) realisieren. Dieses Verfahren garantiert,
dass auch gleichzeitige Buszugriffe mehrerer Stationen immer zu einer eindeutigen Busvergabe führen. Durch das Verfahren
der bitweise Arbitrierung, über die Identifier der zur Übertragung anstehenden Botschaften, wird jede Kollision von mehreren
sendewilligen Stationen eindeutig aufgelöst, und zwar spätestens nach 13 (Standardformat) bzw. 33 Bitzeiten (erweitertes For-
mat) jedes zeitlich beliebigen Buszugriffs. Im Gegensatz zur nachrichtengemässen Arbitrierung des CSMA/CD-Verfahrens wird
mit dieser zerstörungsfreien Kollisionsauflösung gewährleistet, dass in keinem Fall Buskapazität benötigt wird, ohne dabei auch
Nutzinformationen zu übertragen.
Auch in Situationen der Busüberlastung erweist sich die Anbindung der Buszugriffspriorität an den Inhalt der Botschaft als
vorteilhafte Systemeigenschaft gegenüber existierenden CSMA/CD- oder Token-Verfahren: Alle aufgelaufenen Übertragungs-
anforderungen werden trotz der zu geringen Bustransportkapazität in der Reihenfolge der Wichtigkeit für das Gesamtsystem
(entsprechend der Botschaftspriorität) abgearbeitet. Durch die beschriebene inhaltsbezogene Adressierung wird eine hohe Sy-
stem- und Konfigurationsflexibilität erreicht. Es lassen sich sehr einfach Stationen zum bestehenden CAN-Netz hinzufügen, ohne
dass bei den vorhandenen Stationen Software- oder Hardwareänderungen vorgenommen werden müssen, wenn die neuen
Stationen ausschliesslich Empfänger sind. Da von Seiten des Datenübertragungsprotokolls keine physikalischen Zieladressen für
die einzelnen Komponenten vorgeschrieben sind, wird das Konzept der modularen Elektronik ebenso
unterstützt, wie die Möglichkeit des Mehrfachempfangs (Broad/multi-cast) und der Synchronisation von verteilten Prozessen.
Dezentrale Lösungen
CANopen-Profil
Bei der Realisierung von CAN-basierenden verteilten Systemen stösst man schnell auf Anforderungen, welche von den Schicht 1
und 2 Protokollen noch nicht berücksichtigt sind. Die Bereitstellung einer für verteilte Systeme geeigneten, auf dem Schicht 2-
Protokoll aufbauender erweiterten Kommunikationsfähigkeit in Form einer Anwendungsschicht (Schicht 7), war der Ausgangs-
punkt für die Spezifikation von CAL (CAN Application Layer). Aus einer Untermenge von CAL entstand CANopen. Es ist
durch die Definition von Profilen noch spezieller auf den Einsatz in industriellen Standardkomponenten ausgerichtet. CANopen
ist ein Standard der CiA (CAN in Automation e. V.) und hat bereits kurz nach seiner Verfügbarkeit eine sehr weite
Verbreitung gefunden. In Europa kann CANopen als der massgebliche Standard für die Realisierung von industriellen CAN-basie-
renden Systemlösungen betrachtet werden.
Die CANopen Profilfamilie basiert auf einem sog. „Kommunikationsprofil“, welches die zugrundelegenden Kommunikationsme-
chanismen und deren Beschreibung spezifiziert (DS301). Die wichtigsten in der industriellen Automatisierungstechnik eingesetz-
ten Gerätetypen, wie digitale und analoge Ein-/Ausgangsmodule (DS401), Antriebe
(DS402), Bediengeräte (DSP403), Regler (DSP404), programmierbare Steuerungen (DS405) oder Encoder (DS406), werden in
sog. „Geräteprofilen“ beschrieben. In den Geräteprofilen wird die Funktionalität von Standardgeräten des jeweiligen Typs
festgelegt. Grundlage der mit der Profilfamilie angestrebten Herstellerunabhängigkeit ist die Konfigurierbarkeit von Geräten
über den CAN-Bus. CANopen ist eine Sammlung von Profilen für CAN-basierende Systeme mit folgenden Eigenschaften:
• Offen,
• Echtzeitdatenaustausch ohne Protokoll-Overhead,
• modular und skalierbar,
• interoperabel und Austauschbarkeit der Geräte möglich,
• unterstützt durch viele internationale Hersteller,
• standardisiere Konfiguration von Netzwerken,
• Zugriff auf alle Geräteparameter,
• Synchronisation und
• zyklischer und/oder ereignisorientierter Prozessdatenverkehr (kurze Systemreaktionszeiten möglich).
Die CANopen-Spezifikationen sind von der CiA erstellt und teilweise auch für jedermann erhältlich. Sourcecode für Master- und
Slave-Geräte werden von verschiedenen Anbietern zur Verfügung gestellt. Alle Hersteller, die zertifizierte CANopen-Produkte am
Markt haben, sind in der Regel Mitglied in der CiA.
Die SW entspricht dem Draft-Standard CiA DS301 V4.01 Es ist allerdings nur ein Subset an Indexen daraus verwendet. Die be-
nutzten Indexe sind dem zugehörigen EDS zu entnehmen.
Das verwendete Device Profile entspricht CiA DS-401 V2.0, wobei ein Subset aus dieser Spezifikation verwendet ist. Das Map-
ping ist voreingestellt für 1 Receive-PDO und ein Transmit-PDO und kann per SDO verändert werden. Die benutzten Indexe sind
dem zugehörigen EDS zu entnehmen.
Durch aktive Mitgliedschaft in der CiA verfügt die Firma epis Automation über profundes CANopen Know-how zur Entwicklung
von Komponenten für dieses Bussystem.
Dezentrale Lösungen
1. Startup-Modus
Nach dem Einschalten des Moduls, bei fehlendem CAN-Bus (CAN nicht angeschlossen, keine anderen Teilnehmer oder falsche
Baudrate) geht das Modul in den Startup-Modus und sendet pausenlos die Initialisierungs-Message mit Index 700h + Kno-
tennummer einem Byte Daten. Es erfolgt kein Acknowledge. In diesem Modus ist keine Kommunikation mit dem Modul mög-
lich, bzw. die Kommunikation ist gestört.
Bootup-Nachricht
Als Sonderfall einer Heartbeat-Nachricht (Zustands-Status Data 0 = 0) meldet ein Knoten den Übergang in den „Preoperational-
Modus“ nach erfolgreicher Initalisierung mit der sogenannten „Bootup“-Nachricht. Über diese Nachricht ist es möglich, die in
einem Netzwerk im Modus „Preoperational“ vorhandene Netzknoten zu erkennen.
Signalisierung durch die LED: LED-Aus mit kurzem Aufblitzen ca. 2-3 x pro Sekunden
2. Preoperational-Modus
Nach dem Einschalten des Moduls, bei funktionierendem CAN-Bus (mindestens ein weiterer Teilnehmer am CAN ist angeschlos-
sen und funktionsbereit) geht das Modul in den Preoperational-Modus über. In diesem Modus reagiert das Modul auf alle NMT-
Befehle über den CAN-Bus (Identifier=000) und auf SDOs (Identifier = 6XXh). In diesem Mode können über SDOs die Eingänge
gelesen werden und die Ausgänge beschrieben werden. Die PDOs als unbestätigte Nachrichten sind nicht aktiv.
3. Operational-Modus
In diesen Zustand kann das Modul nur durch den NMT-Start-Befehl von außen über den CAN-Bus gelangen. Zum Starten aller
Knoten sendet der Master den Befehl 01 00 mit Identifier 000. Es ist auch möglich durch Angabe der Knotennummer einzelne
Knoten zu starten. Im Operational-Modus sendet das Modul PDOs auf den CAN-Bus bei Veränderung der Eingangspegel an
mindestens einem Eingang. Das Modul reagiert auf eingehende PDOs und setzt seine entsprechenden Ausgänge
Signalisierung durch die LED: LED brennt dauernd (mit kurzer Dunkeltastung )
Signalisierung durch die LED: LED-Aus mit kurzem Aufblitzen ca. 1 x pro Sek.
Bootup-Message
0x700 + Node ID
Nach der Initialisierungsphase und dem Selbsttest sendet die XIO die Boot-Up Message, eine CAN-Nachricht ohne Datenbytes
mit dem Identifier der Emergency
Nachricht: CAN-ID = 0x700 + Node-ID.
Damit kann ein temporärer Ausfall einer Baugruppe während des Betriebs (z.B. durch einen Spannungseinbruch) oder eine
nachträglich eingeschaltete Baugruppe zuverlässig auch ohne Nodeguarding festgestellt werden. Der Sender kann über den
Identifier der Nachricht (siehe Default-Identifier-Verteilung) bestimmt werden. Außerdem ist es mit Hilfe der Boot-Up Nachricht
möglich, die beim Aufstarten am Netz befindlichen Knoten mit einem einfachen CAN-Monitor zu erkennen, ohne daß ein
Schreibzugriff (etwa ein Netzwerk-Scannen durch Auslesen von Parameter 0x1000) auf den Bus erforderlich ist. Schließlich wird
durch die Boot-Up Nachricht das Ende der Initialisierungsphase kommuniziert; die XIO signalisiert, daß er nun konfiguriert bzw.
gestartet werden kann.
Dezentrale Lösungen
Mit dem Remote Telegramm mit Identifier 700h + Knoten-Nummer werden vom Master alle Knoten „gepollt“. Die Rückantwort
ist eine Message mit einem Byte, welches den Netzwerk-Status des Knotens angibt. Um sicherzustellen dass der Knoten „lebt“
ist festgelegt, dass das oberste Bit toggelt. Sobald der Knoten im Operational-Mode einmal das „Node-guarding-remote-
Telegramm“ empfangen und darauf geantwortet hat, wird die Zeitüberwachung innerhalb des XIO-Moduls aktiviert. Wird vom
XIO-Modul für eine voreingestellte Zeitdauer kein Remote mehr empfangen oder fehlt das Toggle des obersten Bits (Master de-
fekt, in dead-loop, oder Verbindung unterbrochen) so geht das XIO-Modul in den Status „preooperational“ und die Ausgänge
werden inaktiv geschaltet.
--> „Fallback-Funktion“.
Die Parameter für das node-guarding sind in Index 100C und 100D abgelegt.
Mit den Voreinstellungen ergibt sich eine maximale Ausfallzeit von 3 Sekunden. Wenn im Operational-Mode für länger als 3
Sekunden kein nodeguarding-Remote empfangen wird, dann geht das XIO-Modul in den Status „Preoperational“ (Fall-Back-
Mode)
Bei Anwendung dieses Verfahrens reduziert sich die Busbelastung durch Wegfall der Abfragenachricht. Hierbei meldet der Kno-
ten seinen Kommunikationsmodus durch zyklisches Senden einer sogenannten „Heartbeat“-Nachricht.
Index 700h + Knotennummer und einem Byte Daten (Kommunikationsmodus)
Diese Nachricht können alle Teilnehmer am Bus empfangen bzw. überwachen. Falls ein verantwortlicher Heartbeat Consumer
keine Heartbeat-Nachricht innerhalb der Heartbeat Consuming Time empfängt, wird dies als Heartbeat-Fehler registriert.
Die Beziehungen zwischen Heartbeat Producer (Index 1017) und Consumer (Index 1016) können über entsprechende Einträge
im Objektverzeichnis konfiguriert werden.
Dezentrale Lösungen
Die SDO-Transfers
SDO-Transfers haben immer die Länge von 8 Bytes und sind immer bestätigt, d.h. sie beanspruchen auf dem Bus die zweifache
Laufzeit einer CAN-Message mit Maximaldauer von 8 Bytes Über SDOs können die implementierten Indexe (siehe EDS-File) je
nach Definition der Attribute gelesen bzw. beschrieben werden oder beides. SDO-Transfers sind möglich im Preoperational-
Mode und im Operational-Mode.
Achtung!
Die Nutzdaten werden linksbündig im INTEL-Format dargestellt.
Wenn nach einer SDO-Anforderung das erste Byte der Rückantwort des Moduls 80h ist,
dann liegt eine falsche Anforderung vor, die das Modul nicht ausführen kann.
Dezentrale Lösungen
Beispiel – Lesen der Eingänge Objekt 6000 über SDO (Modul-Knoten = 1):
Die Eingänge der XIO mit der Node-ID 1 sollen über den SDO_Transfer (Parameterkanal 1) gelesen werden.
Berechnung Identifier
Identifier vom Parameterkanal 1 zum XIO = 0x600 + Node-ID
Identifier = 0x600 + 1 = 0x601
Kommando Read Request (Anforderung zum Lesen eines Parameter vom XIO)
Kommando = 0x40
Beispiel – Schreiben der Ausgänge Objekt 6200 über SDO (Modul-Knoten = 1):
Die Ausgänge sollen zum XIO mit der Node-ID 1 über den Parameterkanal 1 geschrieben werden.
Berechnung Identifier
Identifier vom Parameterkanal 1 zum XIO = 0x600 + Node-ID
Identifier = 0x600 + 1 = 0x601
Kommando Read Request (Anforderung zum Lesen eines Parameter vom XIO)
Kommando = 0x2B
Dezentrale Lösungen
Die PDO-Transfers
Bei vielen Feldbussystemen wird ständig das gesamte Prozeßabbild übertragen. CANopen ist nicht auf dieses Kommunikations-
prinzip beschränkt, da CAN durch die Multi-Master Buszugriffsregelung andere Möglichkeiten bietet.
Bei CANopen werden die Prozeßdaten in Segmente zu maximal 8 Byte aufgeteilt. Diese Segmente heißen Prozeßdatenobjekte
(PDOs). Die PDOs entsprechen jeweils einem CAN-Telegramm und werden über dessen spezifischen CAN-Identifier zugeordnet
und in ihrer Priorität bestimmt. Die PDOs werden aus Sicht der XIO als Receive-PDOs bezeichnet. (RxPDOs) werden von der XIO
empfangen und enthalten Ausgangsdaten, Transmit-PDOs (TxPDOs) werden von der XIO gesendet und enthalten Eingangs-
daten.
PDO Mapping
CANopen legt die Datenbelegung für die ersten beiden PDOs im Geräteprofil für Ein-/Ausgabebaugruppen (DS401) fest
(„Default Mapping“). Das erste PDO ist für digitale Eingänge (TxPDO1) bzw. Ausgänge (RxPDO1) vorgesehen. Das zweite PDO
Mapping ist nach dem Einschalten der XIO inaktiv!. Mit dem zweiten PDO kann der Analogbereich bzw. die schnellen Zähler
abgedeckt werden. Ansonsten kann auch noch ein Mischbetrieb aus Eventmode und Syncmode realisiert werden.
Die Belegung der Prozeßdatenobjekte (Mapping) ist in den Mapping-Tabellen im Objektverzeichnis hinterlegt. Diese Mapping
Tabellen bilden den Querverweis zwischen den Applikationsdaten im Objektverzeichnis (z.B. digitalen und analogen (Eingangs-
daten) und der Reihenfolge in den Prozeßdatenobjekten. An erster Stelle der Mapping Tabelle (Subindex 0) steht die Anzahl der
gemappten Objekte, die im Anschluß aufgelistet sind.
Die Mapping Tabellen befinden sich im Objektverzeichnis bei Index 0x1600 für die RxPDOs bzw. 0x1A00 für die TxPDOs. Dort
sind sie auch näher erläutert.
Die aktuelle Anzahl der digitalen und analogen Ein-/Ausgänge läßt sich durch Auslesen der entsprechenden Applikationsobjekte
im Objektverzeichnis ermitteln bzw. verifizieren:
Adresse Objektverzeichnis
Anzahl digitale Eingängsbytes Index 0x6000, Subindex 0
Anzahl digitale Ausgangsbytes Index 0x6200, Subindex 0
Anzahl analoge Eingänge Index 0x6401, Subindex 0
Anzahl analoge Ausgänge Index 0x6411, Subindex 0
Die von der XIO automatisch erzeugte Belegung der Prozessdatenobjekte genügt in der Regel bereits den Anforderungen. Für
spezielle Anwendungsfälle kann die Belegung jedoch verändert werden:
Die CANopen XIO unterstützen das variable Mapping, bei dem die Applikationsobjekte (Ein- und Ausgangsdaten) frei den PDOs
zugeordnet werden können. Hierzu müssen die Mapping-Tabellen konfiguriert werden:
Zunächst wird eine 0 auf Subindex 0 geschrieben, um die aktuelle Mapping-Konfiguration zu deaktivieren. Dann werden die
gewünschten Applikationsobjekte in Subindex 1...8 eingetragen. Abschließend wird die Anzahl der nun gültigen Einträge
in Subindex 0 parametriert, die XIO überprüft dann die Einträge auf Konsistenz.
Die PDOs können je nach Applikationsanforderung mit unterschiedlichen Kommunikationsparametern versehen werden. Diese
Parameter finden sich im Objektverzeichnis unter Index 0x1400 (RxPDO) bzw. 0x1800 (TxPDO).
PDO Identifier Der wichtigste Kommunikationsparameter eines PDOs ist der CANIdentifier (auch Communication Object Iden-
tifier, COB-ID genannt). Er dient zur Identifizierung der Daten und bestimmt deren Priorität beim Buszugriff. Für jedes CANDa-
tentelegramm darf es nur einen Sendeknoten (Producer) geben, da CAN jedoch alle Nachrichten im Broadcast-Verfahren sendet
kann ein Telegramm von beliebig vielen Knoten empfangen werden (Consumer). Ein Knoten kann also seine Eingangsinformati-
on mehreren Busteilnehmern gleichzeitig zur Verfügung stellen - auch ohne Weiterleitung durch einen logischen Busmaster.
PDO-Transfers sind unbestätigt und können die Länge von 1 bis 8 Bytes haben. Es findet immer nur die Übertragung einer CAN-
Message statt. Bei der vorliegenden Anwendung bestehen beim Default-Mapping beide PDOs je aus zwei Daten-Byte.
Im Operational-Mode sind die PDOs als kurze unbestätigte CAN-Messages aktiv. Bei Veränderung eines oder mehrerer Inputs am
Modul wird ein TXPDO mit einem Datenbyte ausgesendet. Beim Empfang eines RXPDOs mit einem Datenbyte werden die Bits
auf die Ausgänge übertragen.
Beispiel – Senden eines PDO nach Änderung von Input-Bits (Modul-Knoten = 1):
IO7=0V -> 24V: Modul sendet (Identifier und Daten in HEX): 181 80 00
Beispiel – Empfangen eines PDO und Setzen der Ausgangs-Bits (Modul-Knoten = 1):
Master sendet (Identifier und Daten in HEX): 201 48 00 (IO3 und IO6 aktiv!)
Dezentrale Lösungen
EDS Objektverzeichnis
Bei jedem Teilnehmer an CANopen ist in einem Objektverzeichnis (OV) festgelegt, welche Daten er senden bzw. empfangen
kann. Dieses Objektverzeichnis ist im Teilnehmer nicht flüchtig abgelegt. Die Struktur des Objektverzeichnisses ist in einem EDS
(Electronic Data-Sheet) definiert. Dieses EDS kann als Datei für jedes Gerät zur Verfügung gestellt werden und von einem PC-
Tools interpretiert und dargestellt werden.
Das EDS bildet den Rahmen für alle Indexe, die das XIO unterstützt.
Dezentrale Lösungen
1401 RPDO2ComPar
0 Anzahl Subindexe unsigned 8 ro 4 Subindex 1...4 fix eingestellt
1 COB-ID unsigned 32 rw 0x800000300 Identifier für RPDO2
+Node-ID Receive PDO 2 ist nach dem
Einschalten der XIO inaktiv!
2 Transmission-Type unsigned 8 rw 0xFF Übertragungsart (Event)
3 Inhibit-Time unsigned 16 rw 0x0 Wartezeit nach PDO-Transfer
in 1ms
4 CMS-Priority- unsigned 8 rw 0x4
Groupe
Dezentrale Lösungen
Dezentrale Lösungen
Dezentrale Lösungen
Dezentrale Lösungen
Fehlermeldungen (Emergency)
Die Emergency Fehlermeldung werden durch eine interne Fehlersituation (z.B. wenn im laufenden Betrieb die Input Spannung
zu klein wird) ausgelöst. Dann wird eine Emergency Fehlermeldung von der XIO an alle (broadcast) angeschlossenen Geräte
gesendet. Nach der Aufhebung des Fehlers wird ebenfalls die Emergency Fehlermeldung (ohne Fehler) an alle angeschlossenen
Geräte gesendet. Die folgenden Fehlermeldungen werden derzeit vom System unterstützt:
Error Code (LSB....MSB) Bedeutung
0x00, 0x00, 0x00, 0, 0, 0, 0, 0 Kein Error
0x20, 0x31, 0x01, 0, 0, 0, 0, 0 Input voltage too low
0x20, 0x33, 0x01, 0, 0, 0, 0, 0 Output voltage too low
COB IDs
Die Vergabe der COB IDs erfolgt für Tx bzw. Tx-PDO1, Rx bzw. Rx-SDO1, EMERGENCY, Nodeguard, NMT und SYNC anhand
der am DIL Schalter des Feldbuskopplers eingestellten Knoten-ID entsprechend dem DS301 (Predefined Connection Set). Bei
Power On steht diese Einstellung zur Verfügung. Die COB ID setzt sich aus dem Funktionscode und der Modul ID (entspricht der
Knoten-ID) zusammen.
10 0
Function Code Module ID
Der Funktionscode belegt also die 4 höherwertigen Bits der COB ID. Zur Berechnung der COB ID addiert man auf diesen Wer die
jeweilige Module ID. Für die unterstützten Objekte ergeben sich die folgenden COB IDs:
Objekt Func- Function COB ID dez Komm. Res. COB ID
tion Code mit Shift hex parameter bei
Code um Modul ID ab Index Modul ID 12
(binär) (dez.)
NMT 0000 0000 0000000 0 - 0 (00 hex)
SYNC 0001 0001 0000000 128 1005 128 (80 hex)
128 0x80
EMERGENCY 0001 0001 XXXXXX 129 – 255 - 128 + 12 = 140
128 0x81 - 0xFF (80 hex + Node-ID)
PDO1 (tx) 0011 0011 XXXXXX 385 - 511 1800 384 + 12 = 396
384 0x181 - 0x1FF (TX-PDO1 Mapping) (180 hex + Node-ID)
PDO1 (rx) 0100 0100 XXXXXX 513 - 639 1400 512 + 12 = 524
512 0x201 - 0x2F7 (RX-PDO1 Mapping) (200 hex + Node-ID)
PDO2 (tx) 0101 0101 XXXXXX 641 - 767 1801 640 + 12 = 652
640 0x281 - 0x2FF (TX-PDO2 Mapping) (280 hex + Node-ID)
PDO2 (rx) 0110 0110 XXXXXX 769 - 895 1401 760 + 12 = 772
768 0x301 - 0x3F7 (RX-PDO2 Mapping) (300 hex + Node-ID)
SDO (tx) 1011 1011 XXXXXX 1409 - 1535 1200 1408 + 12 = 1420
1408 0x581 - 0x5FF (580 hex + Node-ID)
SDO (rx) 1100 1100 XXXXXX 1537 - 1663 1200 1536 + 12 = 1548
1536 0x601 - 0x67F (600 hex + Node-ID)
Nodeguard 1110 1110 XXXXXX 1793 - 1919 100E 1792 + 12 = 1804
1792 0x701 - 0x77F (700 hex + Node-ID)
Die COB IDs können über SDOs geändert und abgespeichert werden. Nach einem Power On steht die abgespeicherte Einstel-
lung zur Verfügung, wenn keine Klemmen neu gesteckt oder gezogen werden.
Für die TxPDOs 2-5 und RxPDOs 2 -5 sind in dem Device Profile 402 keine Default Werte vorgesehen. Die COB IDs dieser PDOs
müssen vom Anwender unter Berücksichtigung der schon vom Netzwerk benutzten COB IDs vergeben werden.
Nach der Initialisierung durch den Buskoppler sind diese COB IDs standardmäßig deaktiviert.
Dezentrale Lösungen
Additional Information:
1. Bit gesetzt: Digital-Eingänge vorhanden
2. Bit gesetzt: Digital-Ausgänge vorhanden
3. Bit gesetzt: Analog-Eingänge vorhanden
4. Bit gesetzt: Analog-Ausgänge vorhanden
Dezentrale Lösungen
Dezentrale Lösungen
Die Remote-Anfrage des Masters wird auch ohne Einträge in die Objekte Guard-Time und Life-Time-Factor beant-
wortet. Die Zeitüberwachung wird erst aktiviert, wenn in beide Objekte Werte grösser 0 eingetragen sind. Typische
Werte für die Guard-Time liegen zwischen 250ms und 2 Sekunden.
Guarding-Protokoll
Das im ersten Guarding-Telegramm übertragene Toggle-Bit (t) hat den Wert „0“. Anschliessend wechselt („toggelt“) das Bit in
jedem Guarding-Telegramm und signalisiert so, ob ein Telegramm verloren ging. In den restlichen sieben Bit gibt der Knoten
seinen Netzwerk-Status (s) an:
Netzwerk-Status Antworttelegramme
Stopped 0x04 bzw. 0x84
Pre-operational 0x7F bzw. 0xFF
Operational 0x05 bzw. 0x85
Tabelle: Netzwerk-Status
Beispiel:
Die Guarding-Nachricht des Knotens 27 (=0x1B) muss mit einem Remote-Frame mit Identifier 0x71B = 1819 angefragt werden.
Wenn der Knoten OPERATIONAL ist, wechselt das erste Datenbyte der Antwort-Nachricht zwischen 0x05 und 0x85, im
Zustand PRE-OPERATIONAL wechselt es zwischen 0x7F und 0xFF.
Dezentrale Lösungen
Dezentrale Lösungen
Beispiel:
Um das erste Receive-PDO für den Identifier 0x201 zu konfigurieren und es gleichzeitig zu aktivieren, ist in das Objekt mit dem
Index 1400 und dem Subindex 1 der Wert 0x00000201 einzuschreiben.
Um das PDO zu deaktivieren, muss das Bit 31 im Subindex 1 gesetzt werden:
0x80000201.
Bit 30 (Subindex 1) gibt Auskunft, ob ein RTR-Zugriff auf dieses PDO zulässig ist (0) oder nicht (1).
Dezentrale Lösungen
PDO Kommunikationsarten
CANopen bietet vielfältige Möglichkeiten, die Prozeßdaten zu übertragen:
Ereignisgesteuert
Das „Ereignis“ ist die Änderung eines Eingangswertes, die Daten werden sofort nach dieser Änderung verschickt. Durch die
Ereignissteuerung wird die Busbandbreite optimal ausgenutzt, da nicht ständig das Prozeßabbild, sondern nur die Änderung
desselben übertragen wird.
Gleichzeitig wird eine kurze Reaktionszeit erreicht, da bei Änderung eines Eingangswertes nicht erst auf die nächste Abfrage
durch einen Master gewartet werden muß.
Synchronisiert
Nicht nur bei Antriebsanwendungen ist es sinnvoll, das Ermitteln der Eingangsinformation sowie das Setzen der Ausgänge zu
synchronisieren. CANopen stellt hierzu das SYNC-Objekt zur Verfügung, ein CANTelegramm hoher Priorität ohne Nutzdaten,
dessen Empfang von den synchronisierten Knoten als Trigger für das Lesen der Eingänge bzw. für das Setzen der Ausgänge
verwendet wird:
PDO Übertragungsarten
Übertr.-Art Zyklisch Azyklisch Synchron Asynchron
0 wird nicht unterstützt!
1 - 240 x x
254, 255 x
Dezentrale Lösungen
Inhibit Time
Über den Parameter „Inhibit-Zeit“ kann ein „Sende-Filter“ aktiviert werden, der die Reaktionszeit bei der relativ ersten Eingangs-
änderung nicht verlängert, aber bei unmittelbar darauffolgenden Änderungen aktiv ist. Die Inhibit-Zeit (Sendeverzögerungszeit)
beschreibt die Zeitspanne, die zwischen dem Versenden zweier gleicher Telegramme mindestens abgewartet werden muß.
Wenn die Inhibit-Zeit genutzt wird, so kann die maximale Busbelastung und damit die Latenzzeit im „worst case“-Fall ermittelt
werden. In dieses 16-Bit-Feld kann bei den Sende-PDOs die Sperrzeit (Inhibit Time) für die Übertragung des PDOs eingetragen
werden. Nach einer Datenänderung wird vor dem Senden eines PDOs überprüft, ob die Inhibit Time seit dem letzten Senden
vergangen ist. Erst nach Ablauf der Inhibit Time kann ein erneutes Senden des PDOs erfolgen. Die Inhibit Time ist bei asynchro-
ner Übertragung (Übertragungsart 255) sinnvoll, um eine Überlastung des CAN-Busses zu verhindern. Die Inhibit Time ist ein
Vielfaches von 100μs von Objekt 1800,03. Folgende Tabelle zeigt einige berechnete Inhibit Times.
Dezentrale Lösungen
Dezentrale Lösungen
3 4 Eingang 20
Erweiterung Eingang 1 Sonderplatine
5 Eingang 21
Erweiterung Eingang 2 Sonderplatine
6 -
7 -
Dezentrale Lösungen
Dezentrale Lösungen
Dezentrale Lösungen
Dezentrale Lösungen
Das Objekt 6401 wird in den Sende-PDOs beim Eventmode nicht unterstützt. Die Analogwerte würden den CAN-Bus blo-
ckieren, weil bei jedem Event eine Änderung des Analoginput festgestellt würde. Für die Analogeingänge stehen noch keine
Filter zu Verfügung!
Inhibit Time
Über den Parameter „Inhibit-Zeit“ kann ein „Sende-Filter“ aktiviert werden, der die Reaktionszeit bei der relativ ersten Eingangs-
änderung nicht verlängert, aber bei unmittelbar darauffolgenden Änderungen aktiv ist. Die Inhibit-Zeit (Sendeverzögerungszeit)
beschreibt die Zeitspanne, die zwischen dem Versenden zweier gleicher Telegramme mindestens abgewartet werden muß.
Wenn die Inhibit-Zeit genutzt wird, so kann die maximale Busbelastung und damit die Latenzzeit im „worst case“-Fall ermittelt
werden.
Technische Daten
Anzahl der Eingänge 4
Auflösung 10 Bit
Eingangsgröße 0 ... 10 V
Wandlungsdauer 20 μs
Wandlungsprinzip Successive Approximation
Maximaler Spannungsbereich +/- 30 V
Die analogen Messsignale werden mit einer Auflösung von 10 Bit übertragen.
Zahlenformate
Eingangsspannung Zahlenwert Hex. Dez.
Binär
> 10 V 11 1111 1111 3 FF 1023
10 V 11 1111 1111 3 FF 1023
5V 01 1111 1111 1 FF 511
2,5 V 00 1111 1111 0 FF 255
0V 00 0000 0000 0 00 0
Dezentrale Lösungen
Technische Daten
Anzahl Kanäle 2
Ausgangsbereich (Nennwert) +10 V
Taktfrequenz 2,604 kHz
Auflösung (0...3FFh) +10 Bit
Funktionseinheiten
Schnelle Zähler 1 + 2
Siehe Objekt 6300 (16 Bit) Subindex 3 und 4. Hier wird der Startwert bzw. der schelle Zähler aktiviert.
Siehe Beschreibung Sonderfunktion schnelle Zähler Objekt 6100.
Dezentrale Lösungen
Analog Output
Aufgezeichnete Beispiele bei Verwendung der Analog-Ausgänge (PWM-Signal)
Dezentrale Lösungen