Unterschiedliche Baudraten der Teilnehmer

Eigentlich kein ernstzunehmendes Problem – die Baudrate lässt sich auf den meisten Teilnehmern per DIP-Schalter oder Hex-Codierer einstellen. Bei unterschiedlichen Baudraten im gleichen Netz kommt es auch häufig zum “Stillstand” der Kommunikation. Das Problem tritt schnell auf und lässt sich einfach beheben.

Anders verhält es sich dann bei Teilnehmern, die nach dem Einschalten erstmal auf einer “Default Baudrate” hochkommen und erst 2..3 Sekunden später die eigentlich gewünschte Baudrate einnehmen. Dieses Verhalten konnte ich schon häufig bei Steuerungen (SPS) sehen, aber auch bei Modulen mit großer Rechenleistung wie Antrieben/Umrichtern. Hier scheint der CAN Controller erstmal auf irgendeiner Baudrate loszulaufen, wird dann aber später nach Initialisierung der Applikation wieder “eingefangen” und auf die richtige Baudrate eingestellt. Bei diesen Konstellationen sehen Sie nach dem Einschalten erstmal haufenweise Error-Frames und hoffentlich später dann alle Module im Pre-Operational Status – leider bleibt aber auch der Ein- oder Andere auf der Strecke (BusOff).

Falsches CAN Kabel

Der Einsatz des richtigen CAN Kabels ist von entscheidender Wichtigkeit bei der Vermeidung von Problemen im CAN Netzwerk. Das “richtige” Kabel ist in der ISO-11898 spezifiziert. Im folgenden Blockschaltbild ist das ideale CAN Netzwerk dargestellt:

Entscheidend ist die Impedanz Z0 die sich aus den Anteilen Widerstand, Kapazitiver Belag und Induktiver Belag zusammensetzt. Diese Anteile werden definiert über das Verhältnis von Verdrillungen per Meter, Isolation zu Kupferleitung, Abstand der Kupferleitungen etc. Erst wenn die Impedanz des Kabels im definierten Bereich liegt funktioniert auch die reflexionsfreie Terminierung einwandfrei (siehe auch:  http://www.microcontrol-blog.net/2012/12/fehlersuche-in-can-netzwerken/ ).

Aus diesen Rahmenparametern kann man also ganz klar erkennen, dass es “richtige” und “falsche” CAN Kabel gibt. Der CAN läuft auf den meisten verdrillten Kupferleitungen – die Frage ist immer ob er dauerhaft fehlerfrei läuft. Und wie verhält sich das Konstrukt, falls die Leitung um ein paar Meter verlängert wird oder weitere Teilnehmer hinzukommen. Setzen Sie also nicht irgendein “Datenkabel” ein, sondern CAN Kabel.

Der Innenausbau hat jetzt mit vereinten Kräften begonnen. Da alle Fenster geschlossen sind und das Dach auch in Position ist, sind wir natürlich nicht mehr von dem “Winterwetter” abhängig. Der Innenputzer hat bereits alle Wände fertiggestellt. Der Trockenbauer (oder heißt das Akkustikbau ?) hat alle Wände gesetzt. Der Elektriker und die Sanitärinstallateure haben zeitgleich mit der Rohinstallation begonnen. Falls weiterhin alle Gewerke im Zeitplan bleiben, wird in ca. 2 Wochen der Fußboden (inkl. Heizung) gelegt.

Der Bau nähert sich also in großen Schritten der Fertigstellung. Demnächst soll dann auch das Außengelände in Angriff genommen werden … dazu muss aber erstmal der Boden auftauen

Anbei ein paar Impressionen aus dem Chaos des Innenausbaus:

Eingangsbereich

Fertigung

Sekretariat

• beim Remote Frame ist das RTR Bit nach dem Identifier immer rezessiv
• der Remote Frame hat kein Datenfeld

CAN Remote Frame

Unterschiedliche Implementierungen

Für den Empfang von CAN Remote Frames existieren unterschiedliche Ansätze. Zum einen gibt es CAN Controller, die eine CAN Nachricht über ein RTR Bit kennzeichnen, wenn es in den Empfangspuffer geschrieben wird. Dieses muss dann per Software ausgewertet werden. Ein anderer Ansatz ist die Markierung eines CAN Message Buffers im CAN Chip mit einem Flag, der dann bei Eintreffen des Remote Frames automatisch den Data Frame sendet. Ob dieser CAN Message Buffer für Empfang oder Senden konfiguriert sein muss hängt von der Philosophie des Halbleiterherstellers ab, hier gibt es leider keinen Standard. Problematisch an der automatischen Aussendung des Data Frames ist aber, dass die Applikation erst nach der erfolgreichen Übertragung der Daten davon erfährt und somit den Inhalt des CAN Data Frames nicht mehr aktualisieren kann.

Prinzipielles Problem

Die Verwendung von CAN Controllern mit autonomer Reaktion auf CAN Remote Frames birgt ein potenzielles Risiko. Solange die Protocol Engine des Controllers unter Spannung steht und getaktet wird, erfolgt auch eine Antwort auf Remote Frames, selbst wenn der Rest des Microcontrollers bildlich gesprochen “in Flammen steht”. Man muss also schon tief in die Trickkiste greifen (wie beim CANopen Node-Guarding) um überhaupt sicher zu stellen, dass bei der Kommunikation über Remote Frames valide Daten von der Applikation gesendet werden.

Fehlerhafte Implementierungen

Leider existieren immer noch fehlerhafte Implementierungen des CAN Remote Frames auf dem Markt. Dies fängt damit an, dass der DLC in einem Remote Frame nicht korrekt ausgewertet wird und endet mit Chips, die bei Eintreffen eines Remote Frames mit einem Error Frame antworten. Für den Anwender, der überhaupt nicht weiß, welche CAN Controller in dem Gerät verbaut sind, wird damit die Fehlersuche zu einer echten Herausforderung. Daher kann meine Empfehlung nur lauten: “Finger weg von CAN Remote Frames!”

Vermeidung in CANopen

In /2/ ist die Problematik von CAN Remote Frames ausführlich erläutert und es wird erklärt, wie man auch CANopen Netzwerke ohne RTR betreiben kann. Die betroffenen CANopen Dienste sind zum einen das Node-Guarding und zum anderen PDO Nachrichten.

Das Node-Guarding wird einfach durch den Heartbeat ersetzt, was zudem den Vorteil hat, dass CANopen NMT Slave Geräte sich gegenseitig überwachen können (Node-Guarding kann nur vom NMT Master durchgeführt werden). In CoDeSys ist zur Überwachung der CANopen Teilnehmer immer noch Node-Guarding als Standard eingestellt, hier muss man den Haken einfach nur bei Heartbeat setzen.

Für das Anfordern von PDO Nachrichten besteht die Alternative, dies über eine SYNC Botschaft zu erreichen.

Referenzen

/1/ ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
/2/ CiA Application Note AN802 – CAN remote frames: Avoiding of usage, CiA specifications

Bauleiter Peschke in Zimmermannskluft

Unser Bauleiter Herr Mathias Peschke (Fa. borgers) hatte sich extra für diesen Anlass in seine Zimmermannskluft geworfen. Herr Peschke hatte vor seinem Studium den Beruf des Zimmermanns erlernt.

v.l. die Herren Krahl, Wielpütz und Koppe beim Kranzeinhängen

Nachdem die Herren Koppe, Krahl und Wielpütz den Richtkranz eingehängt hatten, begab sich unser Bauleiter auf die höchste Stelle des Baus um den Richtspruch zu verlesen.

Verlesen des Richtspruchs

Das Schnapsglas wurde hiernach fachgerecht zerlegt – und die Gäste konnten sich dem gemütlichen Teil des Festes widmen. Trotz aufgestellter Heizstrahler war es nicht wirklich warm und die heiße Gulaschsuppe fand regen Absatz.

Richtfest mit Gulaschsuppe

Unser Generalunternehmer Firma borgers hat bis jetzt saubere Arbeit geleistet und wir sind alle zuversichtlich, unseren geplanten Umzugstermin einhalten zu können. Nun beginnt die Zeit des Innenausbaus und die Baufortschritte werden nicht mehr so offensichtlich sein.

Wie beim letzen Eintrag erwähnt, schreiten die Arbeiten zügig voran – und das Wetter hat “mitgespielt”. Da der Winter (zumindest bei uns) bisher ausgeblieben ist, konnte bereits das Erdgeschoss fertiggestellt werden.

Bild 1: Fundamente werden erstellt

Auf dem folgenden Bild sind die fast fertiggestellten Mauerarbeiten im Erdgeschoss zu sehen.

Bild 2: Mauerarbeiten am Erdgeschoss

Wenn in diesem Umfeld technischer Support geliefert wird, erhalten wir immer eine Reihe von Fehlerbeschreibungen wie folgt:

• CAN Netzwerk läuft gar nicht
• Bei einem „hot-plug“ eines neuen Teilnehmers bleibt das CAN Netzwerk stehen
• Das CAN Netzwerk läuft, bleibt aber sporadisch stehen (Teilnehmer senden nicht mehr)
• Mit Hilfe eines CAN Tools werden Error-Frames im Netzwerk festgestellt

Nach unserer Erfahrung gibt es einige (wenige) Hauptfehlerursachen in CAN Netzwerken. Nachdem einfache Tests und Überprüfungen des Netzwerks stattgefunden haben sind mehr als 90% der Probleme behoben. Die aus unserer Erfahrung häufigsten Fehlerursachen sind:

• Fehlende oder falsche Terminierung
• Unterschiedliche Baudraten der Teilnehmer
• Falsches CAN Kabel
• Bustopologie fehlerhaft

In loser Folge werden wir in diesem Blog auf die einzelnen Fehlerursachen, deren Analyse und Behebung eingehen. Nach Abarbeiten dieser Punkte sollten die meisten Fehler behoben sein. Sollten dann immer noch unklare Vorkommnisse vorliegen, sollten Sie sich an unseren fachmännischen Support wenden.

Im ersten Teil starten wir mit der “Terminierung von CAN Netzwerken”.

Fehlende oder falsche Terminierung

Mit Terminierung bezeichnet man den reflexionsfreien Abschluss eines Netzwerkes mit dem jeweiligen Wellenwiderstand. Das hört sich jetzt komplizierter an, als es in der Praxis ist. Das CAN Netzwerk muss nur am Anfang und am Ende mit einem Widerstand von 120 Ohm zwischen der CAN-High und der CAN-Low Leitung versehen werden.

Am besten messen Sie den Gleichstromwiderstand mit einem Multimeter im spannungslosen Zustand des Netzwerkes.  Der Messwert sollte ca. 60 Ohm betragen.

Das CAN Netzwerk ist an beiden Enden mit 120 Ohm richtig terminiert

Hierbei ist es entscheidend, die Widerstände am physikalischen Ende der Leitungen zu setzen. Im elektrischen Sinne (Gleichstromtechnik) würden Sie den gleichen Effekt erreichen, wenn die beiden Widerstände „irgendwo“ im Netzwerk angebracht werden. Dieser Aufbau ist fehlerhaft und wird in der Praxis nicht zuverlässig funktionieren.

Die Terminierung wurde an den falschen Positionen gesetzt

Ebenso kommt es häufig vor, dass zu viele oder zu wenige Terminierungen verwendet werden. Dieses Fehlerbild kann sehr einfach analysiert werden, indem Sie mit einem Multimeter den Widerstand im spannungslosen Zustand des Netzwerkes messen.

Hier wurden zu viele Terminierungen im CAN Netzwerk gesetzt

Bei zu vielen Terminierungen ergibt sich ein Widerstandswert, der geringer als die erwarteten 60 Ohm ist.

Hier wurden zu wenige Terminierungen im CAN Netzwerk gesetzt

Zu wenige Terminierungen (hier nur eine) ergeben einen Widerstandswert von 120 Ohm. Falls gar keine Terminierung gesetzt wurde, werden nur die Impedanzen der Treiber im spannungslosen Zustand gemessen. Dieser Wert befindet sich im 2-stelligen kOhm-Bereich (z.B. 20..40 kOhm).

Der Erstbezug des neuen repräsentativen Gebäudes ist für Mitte 2013 geplant, mit ca. 600 qm Gebäudefläche verteilt auf zwei Etagen werden die bisherigen Flächen für Entwicklung, Produktion und Vertrieb mehr als verdoppelt.

Mit derzeit 12 Mitarbeitern ist MicroControl ein innovatives Technologie-Unternehmen im Bereich der industriellen Messtechnik. Seit mehr als 15 Jahren erfolgt die Entwicklung und Produktion der hochwertigen Messtechnik hier am Standort Troisdorf.

Die weltweit ansässigen Kunden von MicroControl gehören in ihren jeweiligen Bereichen zu den Technologieführern und kommen aus den Branchen des Maschinenbaus, der Medizintechnik, der Fahrzeugtechnik und der erneuerbaren Energien.

Ziel der drei Geschäftsführer, Uwe Koppe, Torsten Krahl und Frank Wielpütz ist die weitere Expansion des Unternehmens in den nächsten Jahren. Hierzu gehört natürlich auch die Schaffung neuer, qualifizierter Arbeitsplätze. Mit der Investition in den Standort Troisdorf unterstreicht die Firma ihre Verbundenheit mit der Stadt sowie das Bekenntnis zu der Produktion „Made in Germany“.

Bild 1: NMT State Machine

Die CANopen NMT Slave Geräte können die folgenden Zustände annehmen:

• Initialisierung
• Pre-Operational
• Operational
• Stopped

Nach dem Einschalten oder einem Reset durchläuft jedes Slave Gerät den Zustand Initialisierung und sendet mit Eintreten in den Zustand Pre-Operational die Bootup-Nachricht /1/.

NMT Zustand überwachen

Der NMT-Zustand von CANopen Geräten kann durch das Heartbeat-Protokoll überwacht werden. Hierzu wird ein Timer in dem Gerät auf dem Index 1017h parametriert, der bei Ablauf die Aussendung der Heartbeat-Nachricht veranlasst. Die Zeit wird in Milli-Sekunden angegeben. Das folgende Beispiel zeigt die Einstellung des Heartbeat-Timers auf den Wert 1000 ms bei einem Gerät mit der Adresse 127 (7Fh).

Bild 2: Einstellung Heartbeat

Wo sind meine Prozessdaten?

Um von einem CANopen Gerät Prozessdaten in Form von PDO Nachrichten zu erhalten, muss dieses in den Zustand Operational geschaltet werden. Dies erfolgt typischerweise durch den NMT Master, indem eine Botschaft in der folgenden Form versendet wird:

ID DLC Data
000 2 01 03 ; start node with node-ID 3
000 2 01 00 ; start all remote nodes

Der folgende CAN-Trace zeigt den Start eines Teilnehmers mit der Adresse 3 und das ereignis-gesteuerte Senden einer PDO.

Bild 3: Start eines Teilnehmers mit der Adresse 3

Zu schnelle NMT Master

Durch die Aussendung der Bootup-Nachricht wird die Betriebsbereitschaft des CANopen Teilnehmers signalisiert (siehe Bild 1). Eine Kommunikation mit dem Teilnehmer im Zustand Initialisierung ist nicht möglich. Leider ist in letzter Zeit ein Anstieg von Master Implementierungen auf dem Markt zu beobachten, die sich darum wenig kümmern. Das typische Fehlverhalten ist in Bild 4 dargestellt.

Bild 4: NMT Master wartet nicht auf Bootup-Nachricht

Der NMT Master sendet einen NMT Reset Node Kommando, direkt gefolgt von einem SDO Request. Nachdem dieser Request nicht beantwortet wird und die folgende Bootup-Nachricht einfach ignoriert wird, beginnt der Zyklus erneut. Für den Anwender stellt sich das Problem als “der CANopen Teilnehmer funktioniert nicht” dar.

Die NMT Botschaft wird immer von allen CANopen Geräten im Netzwerk ausgewertet, unabhängig von Nachrichteninhalt! Bei einer Bitrate von 1 MBit/s beträgt die Länge der Nachricht ca. 65 Mikrosekunden. Diese Zeit hat das CANopen Gerät zur Verfügung, um die Nachricht auszuwerten, bis die nächste Nachricht diesen Typs einläuft. Dies ist nicht bei allen auf dem Markt verfügbaren CANopen Geräten möglich, zumal wenn die Hardware schon etwas älter ist.

Daher müssen sogenannte NMT Bursts durch den NMT Master auf jeden Fall vermieden werden. Für diesen Zweck wurde das Objekt 102Ah (NMT Inhibit time) in /2/ definiert, um eine Verzögerung zwischen den CANopen NMT Nachrichten zu gewährleisten. Im CANopen Master Stack kann dies zusätzlich durch die Funktion ComNmtSetInhibit() erreicht werden.

Automatisch starten

CANopen Teilnehmer müssen nicht zwingend durch einen NMT Master gestartet werden. Über das optionale Objekt 1F80h (NMT Startup, definiert in /2/) kann ein Teilnehmer autonom in den Zustand Operational wechseln. Eine Anleitung hierzu findet sich hier in der Application Note AN1203.

Referenzen

/1/ CiA 301 V4.2.0 – CANopen application layer and communication profile
/2/ CiA 302 DSP V4.1.0 – CANopen additional application layer functions

Die Realisierung dieser Idee heißt CANpie, was für CAN Programming Interface Environment steht. Das API des Treibers ist in C geschrieben und ist an die Funktionsweise eines virtuellen CAN Controllers angepasst (siehe Abb. 1).

Abb. 1: Struktur CANpie Treiber

Der Treiber unterstützt sowohl den Empfang und das Versenden von CAN-Botschaften über FIFOs als auch die Verwendung von Mailboxen. Insbesondere der Zugriff auf den CAN-Bus über Mailboxen ist die ideale Basis für die Implementierung von CANopen oder DeviceNet Protokollstacks. In Abhängigkeit von den Möglichkeiten des CAN-Controllers ist die Mailbox Funktionalität ohne Laufzeit-Overhead (durch Hardware-Filterung) möglich. Das API unterstützt bis zu 255 CAN Kanäle, was in der Praxis mehr als ausreichend ist sowie den Zugriff auf die Error State Machine des CAN Controllers.

Die komplette CANpie Projekt ist auf SourceForge gehostet. Die HTML Dokumentation ist unter http://canpie.sourceforge.net/ aufrufbar.

Das CANpie Projekt ist unter der LGPL Lizenz veröffentlicht, was für “Lesser GNU Public License” steht. Damit ist es dem Nutzer möglich den Quellcode zu modifizieren und in eigenen kommerziellen Produkten zu verwenden, ohne diese Änderungen zu veröffentlichen.

 
Für den Einsatz mit CAN HLPs (CANopen, SAE J1939, DeviceNet) stehen CANpie Treiber für über 40 Microcontroller zur Verfügung, darunter auch für diverse Cortex-M3 Derivate.