CANopen
Winkel- und Neigungssensoren als »CANopen Safety«-Teilnehmer
Fortsetzung des Artikels von Teil 2
Meldung des Sensors als »CANopen Safety«-Teilnehmer im CAN-Bus
Der prinzipielle Aufbau erlaubt, Anwenderwünsche umzusetzen. Das beinhaltet z.B. ein Geschwindigkeitssignal, welches die Digits bezogen auf eine Torzeit (parametrierbar – 16 Bit) generiert, davon ein Beschleunigungssignal ableitet, ein zusätzlicher Zeitstempel, CRC-Berechnungen für die Bewertung der Übertragung vom Codierer zum Master uvm. Als Beispiel ist im Bild 4 ein spezifisches Datenformat für SRDOs dargestellt.
Insgesamt muss bei der sicherheitstechnischen Anlage das Zusammenspiel zwischen sicherheitsgerichteter Steuerung und den Sensoren sowie der anderen Komponenten stimmen. Das beinhaltet die Auswertung der Emergency-Nachrichten auf dem Bus, welche kommunikationsbedingt oder sensorbedingt auftreten können. Für die Bewertung des sicheren Positionssignals kann auch das Geschwindigkeitssignal verwendet werden, um z.B. eine Bewegung zu detektieren.
Zum Beispiel ist es denkbar, dass neben dem Positionswert das Geschwindigkeits- und Beschleunigungssignal als sichere Werte ausgegeben wird, d.h. ein PFH-Wert für die Position, die Geschwindigkeit und die Beschleunigung.
Nachfolgend sind die Schritte nach dem Einschalten der Versorgungsspannung, der Parametrierung und dem Einschalten des Operational Modes für CANopen- und CANopenSafety-Teilnehmer beschrieben:
CANopen-Teilnehmer:
- Power Off/on
- Codierer liefert Boot-up-Message
- Codierer im Status Preoperational (Sensor kann parametriert werden)
- Codierer in Operational Mode schalten
- Positionswert des Sensors wird in Abhängigkeit vom Transmission Type gesendet
»CANopen Safety«-Teilnehmer (Tabelle 2):
- Power Off/on
- Codierer liefert Boot-up Message
- Codierer im Status Preoperational –Sensor kann parametriert werden
- Konfiguration einschalten (13FE/00 Configuration valid: 0xA5)
- Codierer in Operational Mode schalten
- Sicherer Positionswert wird vom Sensor zyklisch gesendet
| ID | DLC |
Byte | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 | Byte 7 | Byte 8 | Kommentar |
|---|---|---|---|---|---|---|---|---|---|---|
| 702 | 1 | 00 | Boot up | |||||||
| 602 | 8 | 2f | fe | 13 | 00 | a5 | 00 | 00 | 00 | Configuration Valid |
| 582 | 8 | 60 | fe | 13 | 00 | 00 | 00 | 00 | 00 | |
| 0 | 2 | 01 | 02 | Start Node - Operational Mode | ||||||
| 103 | 4 | xx | xx | xx | xx | Antwort des Codierers mit SRDOs (Position und Geschwindigkeit) | ||||
| 104 | 4 | xx | xx | xx | xx | Antwort des Codierers mit SRDOs (Position und Geschwindigkeit) |
Tabelle 2. Start-Prozedur für »CANopen Safety«-Teilnehmer
Bei CANopen-Teilnehmern kommt nach dem Power-on eine Boot-up-Message; der Sensor befindet sich im Preoperational Mode. Anschließend kann der Teilnehmer über den SDO-Verkehr applikationsspezifisch parametriert werden, bevor er in den Operational Mode geschaltet wird. Bei »CANopen Safety«-Teilnehmern ist zusätzlich die Configuration Valid (siehe Objekt 13FE) gültig zu schalten, bevor er in den Operational Mode übergehen kann.
Aufgrund umfangreicher »CANopen Safety«-Applikationen wurde das Handling der zwei Knoten vereinfacht. So meldet sich der Sensor nach dem Zuschalten der Versorgungsspannung mit einer Boot-up-Message unter der Basis-Adresse des Knotens 1; der Knoten 2 gibt keine Message aus. Nun kann der Anwender seine applikationsspezifischen Parametrierung vornehmen. Ändert man z.B. die Knotenadresse des Knoten 1, so wird automatisch der Knoten 2 mit der geänderten Adresse + 1 parametriert. Werden weitere Parameter des Knoten 1 geändert, erfolgt automatisch die Anpassung der Änderung beim Knoten 2. Zu beachten ist, dass bei Änderung der Save-Paramter die CRC-Berechnung neu zu erfolgen hat und diese dann über das Objekt 2010 Save Parameter abgespeichert werden müssen.
Über das Objekt 13FE wird die Konfiguration nach der Parametrierung gültig geschaltet. Im Operational Mode melden sich dann der Knoten 1 und der Knoten 2 auf dem Bus.
Fehlermeldungen des »CANopen Safety«-Teilnehmers
Es werden zwei verschiedene Fehlerarten unterschieden:
1. Kommunikationsfehler auf dem Bus (Fehlercode 0x81xx). Die Kommunikationsfehler beinhalten Fehler, die auf eine Bus-Störung hinweisen, wie z.B.
- Error Passiv Zustand (0x8120)
- Rückkehr vom Zustand Bus Off (0x8140)
- Overrun Error, es wurde eine Nachricht verloren (0x8110).
2. Sensorfehler (Fehler-Code: 0xFFFF)
- Sensorfehler
- Versorgungsspannung außerhalb des spezifizierten Bereiches
- CRC-Fehler EEPROM
- EEPROM-Fehler
- ROM/RAM-Fehler
Im Fehlerfall wird eine Emergency-Nachricht durch den Sensor gesendet und der Sensor geht vom Operational Mode in den Preoperational Mode über. Der Sensor-Fehlercode wird zusätzlich in das Objekt 1001 – Error Register und in das Objekt 6503 – Alarms eingetragen. Alle Sensorfehler sind als sicherheitsrelevante Fehler eingestuft.
Ist der Kommunikationsfehler verschwunden, wird eine Emergency-Nachricht mit gelöschten Fehlerbit generiert. Der Sensorfehler bleibt bis zum Power-off bzw. Power-on bestehen.
Die Inhibit Time EMCY > 0 ermöglicht die zeitversetzte Ausgabe der Emergency-Nachricht und der Kunde kann applikationsspezifische Belange berücksichtigen.
- Winkel- und Neigungssensoren als »CANopen Safety«-Teilnehmer
- Berechnung der Ausfallwerte - Proof Test Intervall
- Meldung des Sensors als »CANopen Safety«-Teilnehmer im CAN-Bus
- Bootloader
Lesen Sie mehr zum Thema
