Projekt 76: LIN Demonstrator: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
 
(139 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 8: Zeile 8:
'''Betreuer:''' [[Benutzer:Ulrich_Schneider| Prof. Schneider]]<br/>
'''Betreuer:''' [[Benutzer:Ulrich_Schneider| Prof. Schneider]]<br/>


[[Datei:Master Shield.png|rechts|mini|650px| Arduino mit LIN-Shield]]


== Aufgabe ==
== Aufgabe ==
Zeile 29: Zeile 30:
== Grundlagen LIN - Protokoll ==
== Grundlagen LIN - Protokoll ==


In diesem Kapitel werden einige Grundlagen zum Verständnis dieses Projektes erläutert. Für dieses Projekt muss die Funktionsweise und der Aufbau des LIN-Bus bekannt sein. Hinzu muss für diese Kommunikation die Zweidrahtkommunikation des Arduinos auf eine 1-Draht kommunikation umgewandelt werden, wofür der LIN-Transceiver benötigt wird.
In diesem Kapitel werden einige Grundlagen zum Verständnis dieses Projektes erläutert. Für dieses Projekt muss die Funktionsweise und der Aufbau des LIN-Busses bekannt sein. Hinzu muss für diese Kommunikation die Zweidrahtkommunikation des Arduinos auf eine 1-Draht Kommunikation umgewandelt werden, wofür der LIN-Transceiver benötigt wird.


=== Funktionsweise LIN-Bus ===
=== Funktionsweise LIN-Bus ===
LIN (Local Interconnect Network) ist ein junges Bussystem, das ende der 90er Jahre entwickelt wurde. Es wird für einfache Sensor-Aktor-Anwendungen mit relativ geringen Echtzeitanforderungen verwendet, wie zum Beispiel der Tür-, Sitz- oder Schiebedach-Elektronik oder der Ansteuerung des Scheinwerfers eines Autos. Der LIN-Bus ist die kostengünstige Alternative zu dem Low-Speed-CAN Bussystemen. Auf der Bitübertragungsschicht kommt eine UART-Übertragung(8 Datenbits, 1 Startbit, 1 Stoppbit) zum Einsatz. Mögliche Bitraten liegen im Bereich von 1 bis 20 kbit/s. Das LIN-Bussystem besteht aus einem Master-Knoten, der i.d.R gleichzeitig Gateway zu einem übergeordneten CAN-Netzwerk ist. Alle restlichen Knoten sind Slave-Knoten, die nach Anforderungen des Masters ihre Datenpakete verschicken können. Jeder LIN-Knoten beherbergt in der Software eine Slave Task und der Master Knoten besitzt ebenfalls eine Slave-Task und zusätzlich den Master-Task. Zusätzlich besitzt der Master-Knoten ein LIN-Schedule, was ein hinterlegter Zeitplan ist, in dem festgelegt ist, welcher Slave wann abgefragt werden soll, die sogenannten Frame Slots. Zu Beginn eines Frame Slots sendet der Master den Frame Header, der von dem passenden Slave Task zu einem LIN Frame komplettiert wird.
LIN (Local Interconnect Network) ist ein junges Bussystem, welches ende der 90er Jahre entwickelt wurde. Es wird für einfache Sensor-Aktor-Anwendungen mit relativ geringen Echtzeitanforderungen verwendet, wie zum Beispiel der Tür-, Sitz- oder Schiebedachelektronik oder der Ansteuerung des Scheinwerfers eines Autos. Der LIN-Bus ist die kostengünstige Alternative zu dem Low-Speed-CAN Bussystemen. Auf der Bitübertragungsschicht kommt eine UART-Übertragung (8 Datenbits, 1 Startbit, 1 Stoppbit) zum Einsatz. Mögliche Bitraten liegen im Bereich von 1 bis 20 kbit/s. Das LIN-Bussystem besteht aus einem Master-Knoten, der i. d. R gleichzeitig Gateway zu einem übergeordneten CAN-Netzwerk ist. Alle restlichen Knoten sind Slave-Knoten, die nach Anforderungen des Masters ihre Datenpakete verschicken können. Jeder LIN-Knoten beherbergt in der Software eine Slave Task, der Master Knoten besitzt ebenfalls eine Slave-Task und zusätzlich den Master-Task. Zusätzlich besitzt der Master-Knoten ein LIN-Schedule, was ein hinterlegter Zeitplan ist, in dem festgelegt ist, welcher Slave wann abgefragt werden soll, die sogenannten Frame Slots. Zu Beginn eines Frame Slots sendet der Master den Frame Header, der von dem passenden Slave Task zu einem LIN-Frame komplettiert wird.


In der Abbildung 1 ist das LIN-Kommunikationsprinzip dargestellt. Der Master-Knoten sendet den Header auf den Bus. Die Slaves hören den Bus ab und erkennen anhand des Headers, ob sie antowrten müssen oder nicht. Muss ein Slave antworten, fügt seine Response hinter den Header. Zwischen Header und Response befindet sich jeweils ein Response Space und zwischen einer Response und einem Header befindet sich ein Interframe Space. Das sind jeweils willkürliche Bits, die nicht direkt zum LIN-Protokoll gehören.
In der Abbildung 1 ist das LIN-Kommunikationsprinzip dargestellt. Der Master-Knoten sendet den Header auf den Bus. Die Slaves hören den Bus ab und erkennen anhand des Headers, ob sie antworten müssen oder nicht. Muss ein Slave antworten, fügt er seine Response hinter den Header. Zwischen Header und Response befindet sich jeweils ein Response Space und zwischen einer Response und einem Header befindet sich ein Interframe Space. Das sind jeweils willkürliche Bits, die nicht direkt zum LIN-Protokoll gehören.


Der Aufbau eines LIN-Frames ist in der Abbildung 2 dargestellt. Einzuteilen ist das Frame in einen Header und eine Response. Der Header wird von dem Master und die Response von dem Slave erstellt. Im Folgenden wird der genaue Aufbau des LIN-Frames dargestellt.  
Der Aufbau eines LIN-Frames ist in der Abbildung 2 dargestellt. Einzuteilen ist das Frame in einen Header und eine Response. Der Header wird von dem Master und die Response von dem Slave erstellt. Im Folgenden wird der genaue Aufbau des LIN-Frames dargestellt.  
Zeile 46: Zeile 47:


Der Header besteht aus dem Break-Field, dem SYNC-Field und dem Protected-Identifier-Field.
Der Header besteht aus dem Break-Field, dem SYNC-Field und dem Protected-Identifier-Field.
Break-Field besteht aus mindestens 13 Bits und signalisiert den Start des LIN-Frames. Es werden 13 dominante-Bits (logisch 0) und anschließen 1 Delimeter-Bit (logisch 1) gesendet.
Das Break-Field besteht aus mindestens 13 Bits und signalisiert den Start des LIN-Frames. Es werden 13 dominante Bits (logisch 0) und anschließend 1 Delimeter-Bit (logisch 1) gesendet.
Auf das Break-Field folgt das SYNC-Field. Sync wird definiert als das hexadezimale Zeichen x55. Das Sync-Feld ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren.
Auf das Break-Field folgt das SYNC-Field. Das SYNC-Field wird definiert als das hexadezimale Zeichen x55. Das Sync-Field ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren.
Das Protected-Identifier-Field ist das letzte, das vom Master-Task im Header übertragen wird. Es identifiziert jede Nachricht im Netzwerk und bestimmt letztendlich, welche Knoten im Netzwerk welche Übertragung empfangen und welche darauf antworten. Alle Slave-Tasks warten ständig auf Identifikatoren, verifizieren ihre Parität und stellen fest, ob sie diesen bestimmten Identifikator ausgeben oder abfragen.
Das Protected-Identifier-Field ist das letzte Datenpaket, das vom Master-Task im Header übertragen wird. Es identifiziert jede Nachricht im Netzwerk und bestimmt letztendlich, welche Knoten im Netzwerk welche Übertragung empfangen und welche darauf antworten. Alle Slave-Tasks warten ständig auf Identifikatoren, verifizieren ihre Parität und stellen fest, ob sie diesen bestimmten Identifikator ausgeben oder abfragen.


'''Response'''
'''Response'''


Die Response besteht aus dem Response Space, den data-fields und der checksum. Der Response Space ist wie oben erklärt eine zufällige Bitfolge, die aufgrund des zeitlichen versatzes zwischen dem Header und der Response befindet. Auf den Response Space folgt das data-field. Das Data field besteht aus einem Startbit, 8 Datenbits und einem Stoppbit. Die Übertagung des Datenbits erfolgt über das Little-Endian Prinzip, d.h das LSB(least significant Bit) wird als erstes eingefügt. Es könne bis zu 8 Nutzdatenbytes eingefügt werden. An letzter Stelle der Response befindet sich die Checksum. Die Checksum dient zur Überprüfung der erfolgreichen Übertragung. Mittels Modulo-256-arithmetik wird die Checksum gebildet. Die einzelnen Datenbytes werden per Modulo-256-Arithmetik addiert wobei jedes überlaufende Bit zum jeweiligen Zwischenergebnis addiert wird. Schließlich wird das Gesamtergebnis inverteirt und als Checksum in die Response eingefügt.
Die Response besteht aus dem Response Space, dem Data-Fields und der Checksum. Der Response Space ist wie oben erklärt eine zufällige Bitfolge, die aufgrund des zeitlichen Versatzes zwischen dem Header und der Response befindet. Auf den Response Space folgt das Data-Field. Das Data-Field besteht aus einem Startbit, 8 Datenbits und einem Stoppbit. Die Übertragung der Datenbytes erfolgt über das Little-Endian Prinzip, d. h das LSB (least significant Bit) wird als Erstes eingefügt. Es können bis zu 8 Nutzdatenbytes eingefügt werden. An letzter Stelle der Response befindet sich die Checksum. Die Checksum dient zur Überprüfung der erfolgreichen Übertragung. Mittels Modulo-256-Arithmetik wird die Checksum gebildet. Die einzelnen Datenbytes werden per Modulo-256-Arithmetik addiert, wobei jedes überlaufende Bit zum jeweiligen Zwischenergebnis addiert wird. Schließlich wird das Gesamtergebnis inverteirt und als Checksum in die Response eingefügt.
Ein Empfänger führt denselben Algorithmus bis auf die Invertierung mit den empfangenen Datenbytes durch. Falls die Summe aus den Datenbytes und der Checksum nicht 0xFF ist, hat ein Übertragungsfehler stattgefunden und die Kommunikation muss erneut durchgeführt werden.
Ein Empfänger führt denselben Algorithmus bis auf die Invertierung mit den empfangenen Datenbytes durch. Falls die Summe aus den Datenbytes und der Checksum nicht 0xFF ist, hat ein Übertragungsfehler stattgefunden und die Kommunikation muss erneut durchgeführt werden.


Zeile 74: Zeile 75:
Abb. 4: Blockschaltbild des LIN-Transceivers
Abb. 4: Blockschaltbild des LIN-Transceivers


Das Blockschaltbild visualisiert den inneren Aufbau des Transceivers. Dabei fällt auf, dass diverse Absicherungen, wie ein Kurzschluss-Schutz und ein Abschaltmechanismus, beim Erreichen von zu hohen Temperaturen, verbaut sind. Der LIN-Bus Pin ist gegen Kurzschlüsse und Verlust des Erdpotentials (Ground) gesichert. Intern ist dieser mit einer Diode und einem Pull-Up-Widerstand versehen. <br/>
Das Blockschaltbild visualisiert den inneren Aufbau des Transceivers. Dabei fällt auf, dass diverse Absicherungen, wie ein Kurzschlussschutz und ein Abschaltmechanismus, beim Erreichen von zu hohen Temperaturen, verbaut sind. Der LIN-Bus Pin ist gegen Kurzschlüsse und Verlust des Erdpotentials (Ground) gesichert. Intern ist dieser mit einer Diode und einem Pull-Up-Widerstand versehen. <br/>


Weiterführend zeigt die Abb. 5 die Belegung der Anschlusspins am PDIP-Gehäuse.
Weiterführend zeigt die Abb. 5 die Belegung der Anschlusspins am PDIP-Gehäuse.
Zeile 100: Zeile 101:
Abb. 6: Zustandsdiagramm der Betriebsarten
Abb. 6: Zustandsdiagramm der Betriebsarten


Damit der Transceiver Daten zwischen Mikrocontroller und dem LIN-Bus vermitteln kann, ist es notwendig den PIN 2 (Chip Select / CS) auf "High" zu setzen. Dafür kann ein digitaler Pin oder die 5V Spannung vom Arduino eingesetzt werden. Der Tranceiver bleibt dadurch im Modus "Operation Mode" und lässt den Transmitter durchgängig aktiv. Dieser Vorgang wird jedoch nur für dieses Projekt angewandt und sollte für andere Anwendungen entsprechend angepasst werden.
Damit der Transceiver Daten zwischen Mikrocontroller und dem LIN-Bus vermitteln kann, ist es notwendig den PIN 2 (Chip Select / CS) auf "High" zu setzen. Dafür kann ein digitaler Pin oder die 5V Spannung vom Arduino eingesetzt werden. Der Transceiver bleibt dadurch im Modus "Operation Mode" und lässt den Transmitter durchgängig aktiv. Dieser Vorgang wird jedoch nur für dieses Projekt angewandt und sollte für andere Anwendungen entsprechend angepasst werden.


''' Anwendung '''
''' Anwendung '''
Zeile 107: Zeile 108:
File:Lin transceiver lin bus konfiguration.PNG|Abb. 8: Aufbau eines LIN-Netzwerks
File:Lin transceiver lin bus konfiguration.PNG|Abb. 8: Aufbau eines LIN-Netzwerks
</gallery>
</gallery>
Um mit Hilfe des Transceivers Daten senden zu können, wird dieser wie in der Schaltung aus Abb. 7 mit einem Mikrocontroller verbunden. Die Abb. 8 zeigt das LIN-Netzwerk, welches einen Master und mehrere Slaves enthält. Dabei ist jedoch darauf zu achten, dass nach der LIN-Spezifikation 2.1 die Transceiver aller Geräte im Netzwerk durch den LIN-Pin und das Erdpotential (Ground) miteinander verbunden sind. Insgesamt sollte das Netzwerk einen maximalen Abschlusswiderstand zwischen Lin-Bus und Batteriespannungsversorgung von 510 Ohm aufweisen. Die 510 Ohm entsprechen einem Netzwerk von einem Master und 15 Slaves.
Um mithilfe des Transceivers Daten senden zu können, wird dieser wie in der Schaltung aus Abb. 7 mit einem Mikrocontroller verbunden. Die Abb. 8 zeigt das LIN-Netzwerk, welches einen Master und mehrere Slaves enthält. Dabei ist jedoch darauf zu achten, dass nach der LIN-Spezifikation 2.1 die Transceiver aller Geräte im Netzwerk durch den LIN-Pin und das Erdpotential (Ground) miteinander verbunden sind. Insgesamt sollte das Netzwerk einen maximalen Abschlusswiderstand zwischen Lin-Bus und Batteriespannungsversorgung von 510 Ohm aufweisen. Die 510 Ohm entsprechen einem Netzwerk von einem Master und 15 Slaves.


== Projektdurchführung ==
== Projektdurchführung ==
In diesem Kapitel wird die eigentliche Projektdurchführung des Projekts beschrieben. Nach und nach werden die einzelnen Testergebniss bis zum fertigen Endergebnis dargestellt.
In diesem Kapitel wird die eigentliche Projektdurchführung des Projekts beschrieben. Nach und nach werden die einzelnen Testergebnis bis zum fertigen Endergebnis dargestellt.


=== Projektplan ===
=== Projektplan ===
 
Der für unser Projekt verwendete Projektplan ist in der Abbildung 9 dargestellt und wird nun erläutert.
<gallery class="center" widths="800" heights="450">
<gallery class="center" widths="800" heights="450">
File:Projektplan 76 LIN Demonstrator.png|Abb. 9: Projektplan
File:Projektplan 76 LIN Demonstrator.png|Abb. 9: Projektplan
</gallery>
</gallery>
Der für unser Projekt verwendete Projektplan ist in der Abbildung 9 dargestellt und wird nun erläutert. Die als Raute dargestellten Ereignisse sind Meilensteine, wie zum Beispiel die Abschlussmesse oder
Die als Raute dargestellten Ereignisse sind Meilensteine, wie zum Beispiel die Abschlussmesse oder der Erhalt der Bauteile. Hinzu war es uns sehr wichtig während des gesamten Semesters kontinuierlich zu arbeiten, was zum Beispiel an der Dokumentation oder der Recherche zu sehen ist. Es kann gesagt werden, dass wir anhand des Projektplans unser Projekt zeitlich passend fertigstellen konnten. Unsere Einteilung des Projektes zu Beginn konnte kontinuierlich abgearbeitet werden.


=== Verwendete Bauteile ===
=== Verwendete Bauteile ===
Zeile 174: Zeile 175:


----
----
Im Folgendem Abschnitt wird ein Versuchsaufbau erläutert, um den Scheinwerfer für das Projekt als LIN fähigen Aktor verwenden zu können. Dafür wird zunächst der Aufbau des Scheinwerfers beschrieben und ein Versuch für die Ansteuerung erklärt.
Im folgendem Abschnitt wird ein Versuchsaufbau erläutert, um den Scheinwerfer für das Projekt als LIN fähigen Aktor verwenden zu können. Dafür wird zunächst der Aufbau des Scheinwerfers beschrieben, das benötigte Motortreiber-Shield erläutert und ein Versuch für die Ansteuerung erklärt.
==== Anschlussplan ====
==== Anschlussplan Scheinwerfer ====
In diesem Kapitel ist der Anschlussplan des Scheinwerfers dargestellt. Die verschiedenen Pins für die Spannungsversorgung sind in der Abbildung 10 und die Zuweisungen der verschiedenen Spulenpaare des Motortreibers zum Ansteuern der Schrittmotoren sind in der Abbildung 11 dargestellt.
<gallery class="center" widths="600" heights="350" caption="Anschlussplan des Scheinwerfers">
<gallery class="center" widths="600" heights="350" caption="Anschlussplan des Scheinwerfers">
File:Anschlusspins Schema Spannungsversorgung.png|Abb. 10: LIN Kommunikationsprinzip
File:Anschlusspins Schema Spannungsversorgung.png|Abb. 10: Buchse für Spannungsversorgung
File:Schema Pinbelegung Schrittmotor.png|Abb. 11: Stecker für die Schrittmotoren
File:Schema Pinbelegung Schrittmotor.png|Abb. 11: Stecker für die Schrittmotoren
</gallery>
==== Schrittmotortreiber-Shield ====
Da der Scheinwerfer wie bereits erwähnt, Schrittmotoren für die Bewegung des Kurvenlichts besitzt, können diese nicht ohne eine spezielle Ansteuerungseinheit betrieben werden. Damit die Motoren mit dem Arduino Uno verwendet werden können, kommt das "Schrittmotortreiber-Shield L293D" (s. Abb. 12) zum Einsatz.
Das Motortreiber-Shield kann bis zu zwei Schrittmotoren, vier Gleichstrommotoren und zwei Servomotoren ansteuern. Dafür sind auf dem Shield vier H-Brücken verbaut (s. Abb. 13). Jede H-Brücke liefert 0,6A Strom (1,2A Spitzenstrom) und arbeitet mit einer Spannung von 4,5V bis 36V DC. Für die Ansteuerung von Schrittmotoren existiert bereits eine fertige Bibliothek, welche für den Arduino Uno eingesetzt werden kann. Diese Bibliothek stellt diverse Funktionen zur Verfügung, sodass auch zwei Schrittmotoren unabhängig voneinander angesteuert werden können. Dafür müssen die Schrittmotoren an die Terminalblocks M1, M2, M3 und M4 des Shields angeschlossen werden. Die Anschlüsse M1 & M2 oder M3 & M4 sind als Paar jeweils für einen Schrittmotor vorgesehen. Da ein bipolarer Schrittmotor zwei verschiedene Spulenpaare besitzt (meist mit A, A/,B, B/ bezeichnet), sind jeweils passende Anschlüsse für eine Spule (bspw. M1) auf dem Shield montiert. Die Abbildung 11 zeigt die entsprechenden Spulen und deren Terminalblockbezeichner, sodass diese einfach an der angegebenen Klemme (s. Abb. 12) angeschlossen werden müssen.
<gallery class="center" widths="600" heights="350" caption="Anschlussplan des Motorshields L293D">
File:L293D Motorshield.jpg|Abb. 12: Motortreiber L293D und dessen Anschlüsse
File:L293D Schaltplan.png|Abb. 13: Schaltplan des Motortreiber-Shields L293D
</gallery>
</gallery>


==== Versuchsaufbau "Erste Inbetriebnahme" ====
==== Versuchsaufbau "Erste Inbetriebnahme" ====
In diesem Kapitel ist der Versuchsaufbau zum Ansteuern des Audi Q7 Scheinwerfers dargestellt. Die Abbildung 8 enthält hinzu die Beschriftung der einzelnen Bauteile.
In diesem Kapitel ist der Versuchsaufbau zum Ansteuern eines Audi Q7 Scheinwerfers dargestellt. Die Abbildung 14 enthält hinzu die Beschriftung der einzelnen Bauteile.
<gallery class="center" widths="600" heights="350" caption="Anschlussplan des Scheinwerfers">
<gallery class="center" widths="600" heights="350" caption="Anschlussplan des Scheinwerfers">
File:Versuchsaufbau Scheinwerfer Fehlerkorrektur.png|Abb. 12: Versuchsaufbau Scheinwerfer
File:Versuchsaufbau Scheinwerfer Fehlerkorrektur.png|Abb. 14: Versuchsaufbau Scheinwerfer
File:Scheinwerfer Schaltplan Betrieb.PNG|Abb. 13: Schaltplan Versuchsaufbau
File:Scheinwerfer Schaltplan Betrieb.PNG|Abb. 15: Schaltplan Versuchsaufbau
</gallery>
</gallery>
Damit der Scheinwerfer als Aktor eingesetzt werden kann, wurde dieser zunächst in Betrieb genommen. Dafür wurden die Anschlüsse (Abb. 6 u. 7) für die Spannungsversorgung und die Schrittmotoren identifiziert. Anschließend folgte der Aufbau der ersten Inbetriebnahme nach dem Schaltplan aus Abb. 9.
Damit der Scheinwerfer als Aktor eingesetzt werden kann, wurde dieser zunächst in Betrieb genommen. Dafür wurden die Anschlüsse (Abb. 10 u. 11) für die Spannungsversorgung und die Schrittmotoren identifiziert. Anschließend folgte der Aufbau der ersten Inbetriebnahme nach dem Schaltplan aus Abb. 15.


==== Versuchsdurchführung ====
==== Versuchsdurchführung ====
Zu Beginn des Versuchs wurde der Xenon-Brenner an die Spannungsversorgung angeschlossen. Damit der Xenon-Brenner jedoch korrekt betrieben werden kann, wird ein Netzteil mit 12 V DC und 10 A benötigt, da beim Einschaltvorgang eine höhere Stromaufnahme (etwa 8 A) vorliegt als im weiteren Betrieb (etwa 3,5 A). Nachdem die Funktionsfähigkeit des Xenon-Brenners bestätigt werden konnte, wurden die Anschlüsse für das Fernlicht und für den Blinker an die Spannungsversorgung angeschlossen. Auch hier konnte eine erfolgreiche Inbetriebnahme festgehalten werden. Im nächsten Schritt wurde die Verstellung des Kurvenlichts getestet. Dafür kam ein Arduino Uno mit Motor-Shield zum Einsatz, weil die Schrittmotoren für die vertikale und horizontale Verstellung angesteuert werden mussten. Das Motor-Shield hat die Möglichkeit zwei verschiedene Schrittmotoren anzusteuern und diese bei Bedarf mit einer externen Spannungsquelle zu versorgen. Der Schaltplann in Abb. 9 zeigt die Verkabelung für die jeweiligen Schrittmotoren.
Zu Beginn des Versuchs wurde der Xenon-Brenner an die Spannungsversorgung angeschlossen. Damit der Xenon-Brenner jedoch korrekt betrieben werden kann, wird ein Netzteil mit 12 V DC und 10 A benötigt, da beim Einschaltvorgang eine höhere Stromaufnahme (etwa 8 A) vorliegt als im weiteren Betrieb (etwa 3,5 A). Nachdem die Funktionsfähigkeit des Xenon-Brenners bestätigt werden konnte, wurden die Anschlüsse für das Fernlicht und für den Blinker an die Spannungsversorgung angeschlossen. Auch hier konnte eine erfolgreiche Inbetriebnahme festgehalten werden. Im nächsten Schritt wurde die Verstellung des Kurvenlichts getestet. Dafür kam ein Arduino Uno mit Motor-Shield zum Einsatz, weil die Schrittmotoren für die vertikale und horizontale Verstellung angesteuert werden mussten. Das Motor-Shield hat die Möglichkeit zwei verschiedene Schrittmotoren anzusteuern und diese bei Bedarf mit einer externen Spannungsquelle zu versorgen. Der Schaltplan in Abb. 15 zeigt die Verkabelung für die jeweiligen Schrittmotoren.


=== Kommunikation zweier Arduinos über LIN-Bus ===
=== Kommunikation zweier Arduinos über LIN-Bus ===
Zeile 196: Zeile 206:
----
----


In  diesem Kaptitel wird die Kommunikation über einen LIN-Bus mit 2 Arduinos (Master und Slave) getestet. Zu Beginn wird der Programmablaufplan mithilfe eines PAP-Designs grafisch dargestellt und anschließend wird dargestellt, wie die Kommunikation Programmtechnisch umgesetzt ist. Anschließend wird der Versuchsaufbau mit der Versuchsdurchführung erläutert. Abschließend werden zwei LIN-Shields entwickelt, auf denen die Schaltungen des Masters und des Slaves platziert werden sollen.
In  diesem Kaptitel wird die Kommunikation über einen LIN-Bus mit 2 Arduinos (Master und Slave) getestet. Zu Beginn wird der Versuchsaufbau mit der Versuchsdurchführung erläutert. Anschließend werden zwei LIN-Shields entwickelt, auf denen die Schaltungen des Masters und des Slaves platziert werden sollen.
Die Umsetzung der Schnittstelle, die in diesem Versuch eingesetzt wird, folgt im anschließenden Kapitel [http://193.175.248.52/wiki/index.php/Projekt_76:_LIN_Demonstrator#Ansteuerung_des_Kurvenlichts_.C3.BCber_LIN-Bus ''Ansteuerung des Kurvenlichts über LIN-Bus'']. Dabei werden mithilfe eines PAP-Designs die Programmabläufe grafisch dargestellt und weitere Erläuterungen gegeben.


==== Versuchsaufbau ====
==== Versuchsaufbau ====
In den Abbildungen 10 bis 12 sind der Versuchsaufbau für das Testen der Kommunikation zwischen dem Master und dem Slave dargestellt. In der Abbildung 11 ist die LIN-Nachricht mit einem Osilloskop aufgenommen worden.
In den Abbildungen 16 bis 18 sind der Versuchsaufbau für das Testen der Kommunikation zwischen dem Master und dem Slave dargestellt. In der Abbildung 17 ist die LIN-Nachricht mit einem Osilloskop aufgenommen worden.


<gallery class="center" widths="500" heights="350" caption="Versuchsaubau Test LIN-Nachricht">
<gallery class="center" widths="500" heights="350" caption="Versuchsaubau Test LIN-Nachricht">
File:Versuchsaufbau Kommunikation Schaltungsaufbau.png|Abb. 14: Versuchsaufbau Kommunikation Schaltungsaufbau
File:Versuchsaufbau Kommunikation Schaltungsaufbau.png|Abb. 16: Versuchsaufbau Kommunikation Schaltungsaufbau
File:Versuchsaufbau Kommunikation Oszilloskop.png|Abb. 15: Versuchsaufbau Kommunikation Oszilloskop
File:Versuchsaufbau Kommunikation Oszilloskop.png|Abb. 17: Versuchsaufbau Kommunikation Oszilloskop
File:Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt.png|Abb. 16: Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt
File:Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt.png|Abb. 18: Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt
</gallery>
</gallery>


==== Test der Kommunikation ====
==== Test der Kommunikation ====
Zuerst wurde lediglich der Master(Arduino in Abbildung 10) getestet. Von dem Master werden die Werte 99 und 123 mithilfe der ersten beiden Datenbytes auf den LIN Bus gelegt. Das Ergebnis lässt sich in der Abbildung 11 sehen. Das gemessene Signal am Oszilloskop zeigt das typische Muster eines LIN-Protokolls. Zuerst werden in unserem Beispiel 16 dominante Bits (logisch 0 - ca. 1V) gesendet. Die rezessiven Bits (1) entsprechen ca. 12V, die an dem Bord und somit an den LIN-Transceivern angelegt werden. Mithilfe des in der Abbildung 12 dargestellten Versuchsaufbaus ist es nun möglich ziwschen dem rechten Arduino (Master) und dem linken Arduino (Slave) zu kommunizieren. Der LIN-Bus ist das grüne Kabel. Mit diesem Ergebnis wird nun in dem nächsten Kapitel der Audi Q7 Scheinwerfer mithilfe des LIN Protokolls angesteuert.
Zuerst wurde lediglich der Master(Arduino in Abbildung 16) getestet. Von dem Master werden die Werte 99 und 123 mithilfe der ersten beiden Datenbytes auf den LIN-Bus gelegt. Das Ergebnis ist in der Abbildung 17 zu sehen. Das gemessene Signal am Oszilloskop zeigt das typische Muster eines LIN-Protokolls. Zuerst werden in unserem Beispiel 16 dominante Bits (logisch 0 - ca. 1V) gesendet. Die rezessiven Bits (1) entsprechen ca. 12V, die an dem Bord und somit an den LIN-Transceivern angelegt werden. Mithilfe des in der Abbildung 18 dargestellten Versuchsaufbaus ist es nun möglich zwischen dem rechten Arduino (Master) und dem linken Arduino (Slave) zu kommunizieren. Der LIN-Bus ist das grüne Kabel. Mit diesem Ergebnis wird nun in dem nächsten Kapitel der Audi Q7 Scheinwerfer mithilfe des LIN Protokolls angesteuert.


=== Ansteuerung des Kurvenlichts über LIN-Bus ===
=== Ansteuerung des Kurvenlichts über LIN-Bus ===
Zeile 218: Zeile 229:
==== Programmablaufplan Master und Slave ====
==== Programmablaufplan Master und Slave ====


In diesem Kapitel sind jeweils die beiden Programmablaufpläne des Masters und des Slaves dargestellt. Zuerst sendet der Master ein festgelegtes Datenpaket an den Slave. Der Slave überprüft das Datenpaket mithilfe der Checksumme auf Richtigkeit. War die Datenübertagung ohne Fehler, so steuert der Slave das Kurvenlicht des Scheinweifers in Abhängigkiet des gesendetem Datenpakets an. In unserem Beipiel wird der Scheinwerfer nacheinander um 100 Einhieten nach links, um 100 nach unten, um 100 einheiten nach rechts und um 100 einheiten nach oben angesteuert. Somit bewegt sich der Scheinwerfer in einem Quadrat.
In diesem Kapitel sind jeweils die beiden Programmablaufpläne des Masters und des Slaves dargestellt. Zuerst sendet der Master ein festgelegtes Datenpaket an den Slave. Der Slave überprüft das Datenpaket mithilfe der Checksumme auf Richtigkeit. War die Datenübertragung ohne Fehler, so steuert der Slave das Kurvenlicht des Scheinweifers in Abhängigkiet des gesendetem Datenpakets an. In unserem Beispiel wird der Scheinwerfer nacheinander um 100 Einheiten nach links, um 100 nach unten, um 100 Einheiten nach rechts und um 100 Einheiten nach oben angesteuert. Somit bewegt sich der Scheinwerfer in einem Quadrat.


<gallery class="center" widths="700" heights="400" caption="Programmablaufpläne">
<gallery class="center" widths="700" heights="400" caption="Programmablaufpläne">
File:Programmablauf master.PNG|Abb. 17: Programmablaufplan Master
File:Programmablauf master.PNG|Abb. 19: Programmablaufplan Master
File:Programmablaufplan slave.PNG|Abb. 18: Programmablaufplan Slave
File:Programmablaufplan slave.PNG|Abb. 20: Programmablaufplan Slave
</gallery>
</gallery>


==== Software Programm ====
==== Software Programm ====
Um Datenpakete über den LIN-Bus zu verschicken, wurde für den Arduino Uno eine Schnittstelle programmiert, die es dem Benutzer erlaubt, dem Master und dem Slave eigene Adressen zuzuweisen und mit einer gewünschten Baudrate zu kommunizieren. Diese Schnittstelle wurde als eigene Bibliothek in der Hochsprache C/C++ entwickelt und kann für jeglichen Arduino (z.B. Uno, Mega, Due) verwendet werden. Die Bibliothek stellt öffentliche Funktionen zum Lesen und Schreiben von Datenpaketen bereit und verwendet private Funktionen für interne Prozesse wie die Berechnung der Checksumme oder der Umsetzung von anderen Elementen des LIN-Protokolls.<br/>
Die Bibliothek wurde speziell für dieses Projekt bzw. Demonstration zugeschnitten, sodass nicht alle Möglichkeiten des LIN-Protokolls in Verbindung mit dem Transceiver im vollem Umfang ausgeschöpft wurden. Jedoch können die gewünschten Implementierungen für spätere Projektideen jederzeit in die Bibliothek mit integriert werden. Somit stellt diese Schnittstelle eine gute Basis für Erweiterungen dar. Um die Funktionen verwenden zu können, muss die Bibliothek einfach in ein Arduino-Sketch/-Projekt inkludiert werden. Daraufhin kann eine Instanz mit den gewünschten Parametern angelegt und dessen Funktionen im Programm an geforderter Stelle aufgerufen werden.


Das Programm, dass auf dem Master und auf dem Slave ausgeführt wird, kann unter dem nachfolgenden SVN-Link eingesehen werden:
Das Programm, dass auf dem Master und auf dem Slave ausgeführt wird, kann unter dem nachfolgenden SVN-Link eingesehen werden:
Zeile 231: Zeile 244:
[https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/76_LIN_Demonstrator/Umsetzung/Programm/LIN_Arduino/ SVN-LINK Arduino Programm]
[https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/76_LIN_Demonstrator/Umsetzung/Programm/LIN_Arduino/ SVN-LINK Arduino Programm]


==== Versuchsaufbau ====
==== Versuchsaufbau und Versuchsdurchführung ====


[[Datei:Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator.png| 600px | thumb | right | Abb. 19: Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator]]
[[Datei:Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator.png| 600px | thumb | right | Abb. 21: Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator]]
<br/>
Der Versuchsaufbau zum Ansteuern des Kurvenlichts wird in diesem Kapitel erklärt und ist in der Abbildung 21 zu sehen. An dem Scheinwerfer und an den Anschlüssen des Steckbretts werden 12V angelegt. Die Spannung von 12V wird an dem Steckbrett angelegt, da die LIN-Transceiver bzw. der LIN-Bus mit dieser Spannung betrieben werden muss. Die Arduinos erhalten die Betriebsspannung über den USB-Anschluss des angeschlossen PCs. Der Master-Arduino sendet die eingestellte Nachricht auf den LIN-Bus und der Slave setzt diese Nachricht um. Der Scheinwerfer wird nun über einen Motortreiber von dem Slave angesteuert. Als weiteres Vorgehen steht nur noch die Entwicklung der LIN-Shields aus. Nach Fertigung der Shields müssen sie nur noch final getestet werden.
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
Zeile 263: Zeile 272:
<br/>
<br/>


==== Versuchsdurchführung ====
==== Überwachen des Datenverkehrs mit CANoe ====
In diesem Kapitel ist die Inbetriebnahme der Vector Software zum Überwachen des Datenverkehrs dargestellt. Hierzu muss der LIN-Bus mithilfe des in der Abbildung 22 dargestellten Steckers an den PC mit der installierten Software angeschlossen werden. Die Pinbelegung des Steckers kann unter dem folgenden Link eingesehen werden:
https://assets.vector.com/cms/content/products/VN16xx/docs/VN1600_Interface_Family_Manual_DE.pdf
 
<gallery class="center" widths="500" heights="400" caption="CANoe">
File:Anschluss CANoe.jpg|Abb. 22: Anschlussstecker CANoe
File:Vektor CANoe.JPG|Abb. 23: Ergebnis Überwachung mit CANoe
</gallery>


==== Überwachen des Datenverkehrs mit CANoe ====
Die Datenverkehrsüberwachung konnte nicht vollständig durchgeführt werden, da wie in der Abbildung 23 dargestellt ein Fehler beim Auslesen auftrat. Der beschriebene Fehler besagt, dass das Delimeter Feld eine inkorrekte Länge hat. Da wir die Baudrate beim Arduino gesenkt haben, um mindestens 13 dominante Bits als Break zu senden, ist das Delimeter Feld folglich zwei rezessive Bits anstatt einem rezessiven Bit. Somit kann die Software keine zu 100% exakte LIN-Nachricht erkennen und zeigt deswegen Fehler an. Dieses Problem zu lösen erfordert weitere Änderungen an dem Protokoll, was den Aufwand überschreiten würde.


==== Entwicklung eines LIN-Shields ====
==== Entwicklung eines LIN-Shields ====
In diesem Kapitel werden 2 LIN-Shields entworfen, eins für den Master des Stechbretts aus der Abbildung 12 und eins für Slave aus der Abbildung 12. Zu Beginn wird der Versuchsaufbau dargestellt und der die Durchführung des Versuchs erläutert.
In diesem Kapitel werden die, für das Projekt geforderten, Platinen beschrieben. Eine Platine dient dabei als Arduino-Shield für den Master, welches der Schaltung auf dem Steckbrett aus der Abbildung 18 entspricht. Die andere Platine wird für den Slave verwendet und die entsprechende Schaltung kann aus der Abbildung 18 entnommen werden. Um das Vorgehen zu erläutern, wird zu Beginn der Versuchsaufbau dargestellt und die Durchführung des Versuchs erklärt.


===== Platinenlayout =====
===== Platinenlayout =====
<gallery class="center" widths="500" heights="400" caption="Master LIN-Shield">
<gallery class="center" widths="500" heights="400" caption="Master LIN-Shield">
File:Master1 Platinenlayout.png|Abb. 20: 3D-Ansicht Master Shield-Entwurf
File:Master1 Platinenlayout.png|Abb. 24: 3D-Ansicht Master Shield-Entwurf
File:Master2 Platinenlayout.png|Abb. 21: Master Shield-Entwurf Unterseite
File:Master2 Platinenlayout.png|Abb. 25: Master Shield-Entwurf Unterseite
File:Master Shield.png|Abb. 22: Fertig bestücktes Master Shield
File:Master Shield.png|Abb. 26: Fertig bestücktes Master Shield
</gallery>
</gallery>
*Beschreibung
Da eine Anforderung, die Entwicklung eines LIN-Shields für den Arduino, war, wurde für den "Arduino Uno Rev 3" ein passendes Shield mithilfe der Software "Ultiboard" entworfen und im Anschluss mittels Fräsmaschine die Platine gefertigt. Die Schaltung entspricht dabei der gleichen, wie aus der Abbildung 18, sodass sichergestellt werden konnte, dass die Schaltung funktionsfähig ist. Die Bauteile wurden vom Steckbrett auf die Platine gelötet und der Transceiver auf einen Sockel gesteckt. Dies hat den Vorteil, dass bei fehlerhafter Bedienung der Transceiver gewechselt werden kann. Außerdem wurden Stiftleisten verbaut, damit das Shield auf den Arduino gesteckt werden kann. Das Shield besitzt des Weiteren Pin-Anschlüsse für die externe Verkabelung (Spannungsversorgung, LIN-Bus).


<gallery class="center" widths="500" heights="400" caption="Slave LIN-Shield">
<gallery class="center" widths="500" heights="400" caption="Slave LIN-Shield">
File:Slave1 Platinenlayout.png|Abb. 23: 3D-Ansicht Slave Shield-Entwurf
File:Slave1 Platinenlayout.png|Abb. 27: 3D-Ansicht Slave Shield-Entwurf
File:Slave2 Platinenlayout.png|Abb. 24: Slave Shield-Entwurf Unterseite
File:Slave2 Platinenlayout.png|Abb. 28: Slave Shield-Entwurf Unterseite
File:Slave Shield.png|Abb. 25: Fertig bestücktes Slave Shield
File:Slave Shield.png|Abb. 29: Fertig bestücktes Slave Shield
</gallery>
</gallery>
*Beschreibung
Im Gegensatz zum Master konnte für den Slave jedoch kein Shield entworfen werden, da auf dem Arduino Uno bereits ein Shield für die Ansteuerung der Schrittmotoren befestigt ist. Um dennoch eine saubere Schaltung für das Projekt verwenden zu können, wurde stattdessen eine einfache Platine entworfen, welche alle notwendigen Pin-Anschlüsse für die entsprechenden Schnittstellen des Arduinos usw. aufweist. Ebenfalls wurde auch auf dieser Platine ein Sockel für den Transceiver verbaut, um diesen bei Beschädigungen wechseln zu können.
 
LINK: [https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/76_LIN_Demonstrator/Umsetzung/Shield Mithilfe dieses Links können die Schaltpläne der Platinen im SVN eingesehen werden]


===== Funktionstest der Platinen =====
===== Funktionstest der Platinen =====
*Beschreibung
Nachdem alle Platinen fertigt bestückt wurden, mussten diese schließlich in Betrieb genommen werden, um beispielsweise Beschädigungen durch den Lötvorgang festzustellen. Dafür wurden mit einem Durchgangsprüfer eines digitalen Multimeters zunächst alle Pins durchgetestet, ob diese eventuelle störende Masseverbindungen (außer Erdpotentialanschluss -> Ground) aufweisen. Nach der erfolgreichen Prüfung wurden die Platinen anschließend nach entsprechender Vorgabe an die Mikrocontroller usw. angeschlossen. Auch dieser Vorgang verlief fehlerfrei, sodass die Platinen mit dem LIN-Bus verbunden wurden. Nach dem Einschalten aller Geräte konnte der Funktionstest als erfolgreich festgehalten werden. Die Arduinos kommunizierten einwandfrei miteinander und das Kurvenlicht des Scheinwerfers bewegte sich wie gewünscht.
<gallery class="center" widths="600" heights="500">
File:Finaler Versuchsaufbau.png|Abb. 30: Funktionstest der Platinen
</gallery>


== Ergebnis ==
== Ergebnis ==
Unser Projektergebnis wird in diesem Kapitel dargestellt. Auf der linken Seite befindet sich der Master, der ein erstelltes Datenpaket auf den Bus legt. Das Signal auf dem LIN-Bus ist mit dem Oszilloskop dargestellt. In der Mitte befindet sich ein Netzteil, an dem wir 12V einstellen, um den Scheinwerfer anzusteuern und den LIN-Bus mit Spannung zu versorgen. Auf der rechten Seite befindet sich der Slave, der die gesendeten Daten auf dem LIN-Bus. Bei passender, gesendeter ID steuert der Slave den Motortreiber an, der den Schrittmotor nacheinander nach links, runter, rechts und hoch ansteuert (die Richtigen sind in Fahrtrichtung angegeben). 
<gallery class="center" widths="1000" heights="300">
File:Ergebnis LIN Bus.png|Abb. 31: Ergebnis LIN-Bus
</gallery>
Das Ergebnis ist am besten in dem [http://193.175.248.52/wiki/index.php/Projekt_76:_LIN_Demonstrator#YouTube_Video nachfolgenden Video] zu sehen


== Zusammenfassung ==
== Zusammenfassung ==
Als Abschluss zur Projektdokumentation wird im Folgendem eine Zusammenfassung in Form von gesammelten Erfahrungen während des Projektverlaufs und eines Ausblicks gegeben.


=== Lessons Learned ===
=== Lessons Learned ===
Rückblickend kann festgehalten werden, dass die Wahl der Arbeitsreihenfolge vorteilhaft für das Projekt war. Die Recherche half dabei, um sich zunächst einen Überblick über das gesamte Thema zu verschaffen. Auch das bestehende Wissen zu Bussystemen aus dem Bachelorstudium stellte eine gute Basis dar und konnte bei der Programmierung erstmals verwendet werden. Beim Sichten der benötigten Bauteile konnten weitere vertiefende Erfahrungen im Bereich der Elektrotechnik gesammelt werden und das Erstellen eines Anschlussplans für den Aktor stellte sich als Herausforderung dar, da keine öffentlichen zugänglichen Quellen zum Aufbau des Scheinwerfers existieren. Diese Herausforderung konnte aber durch bestehende Erfahrungen in der Elektrotechnik und in der Antriebstechnik schnell gelöst werden. Das Designen eines Schaltplans und Anfertigen der Platinen konnten jeweils als ergänzende Vertiefungen gesehen werden. Das Bestücken der Bauteile entsprach einer guten praxisnahen Übung im Bereich der Löttechnik. Weiterführend wurde beim Programmieren der Schnittstelle zwischen Mikrocontroller und LIN-Bus das Wissen im Bereich der hardwarenahen Programmierung in der Hochsprache C/C++ vertieft. Auch das unterschiedliche Wissens- und Erfahrungsniveau der Projekterschaffer war eine interessante Erfahrung, weil in Problemsituationen die jeweiligen Individuen ergänzende Wissenstände für eine schnelle Lösungsfindung aufwiesen und direkt einsetzen konnten.


=== Ausblick ===
=== Ausblick ===
Weiterführend gesehen sollte das LIN-Protokoll weiter angepasst werden, damit eine einwandfreie Überwachung mit CANoe sichergestellt werden kann. Außerdem könnten neue Platinen für neue Anwendungen angefertigt werden, da die im Projekt verwendeten Platinen nur für die beschriebene Demonstration angefertigt wurden. Vorstellbar wäre auch ein komplexeres LIN-Netzwerk aufzubauen, um damit verschiedene Sensoren und Aktoren anzusteuern.


== Projektunterlagen ==
== Projektunterlagen ==
Zeile 302: Zeile 331:


== YouTube Video ==
== YouTube Video ==
Das Ergebnis dieses Projekts kann unter folgendem YouTube Video entnommen werden:
[https://youtu.be/On8nwF8VFIw Projektvideo]


== Weblinks ==
== Weblinks ==
[http://ww1.microchip.com/downloads/en/devicedoc/20002230g.pdf Datenblatt LIN-Transceiver MCP2004]
[http://ww1.microchip.com/downloads/en/devicedoc/20002230g.pdf Datenblatt LIN-Transceiver MCP2004]
[https://store.arduino.cc/arduino-uno-rev3 Arduino Uno Rev3]


[http://www.ni.com/white-paper/9733/de/ Aufbau LIN Nachricht]
[http://www.ni.com/white-paper/9733/de/ Aufbau LIN Nachricht]
[https://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf LIN-Protokoll]
[https://www.vector.com/de/de/produkte/produkte-a-z/hardware/netzwerk-interfaces/vn16xx/ CANoe-Adapter]
[https://eckstein-shop.de/HIMALAYA-basic-L293D-Motor-Stepper-Servo-Schrittmotor-Arduino-Shield?curr=EUR&gclid=Cj0KCQiA7IDiBRCLARIsABIPohgP0o6TsmNRspXWv8fiBJZOxVEv2MUf7MzJXKaUi4l9DUTNP-PNyM0aAo1XEALw_wcB Motortreiber-Shield]
[https://rn-wissen.de/wiki/index.php/Schrittmotoren Infos zu Schrittmotoren]


== Literatur ==
== Literatur ==
[1] Reif, Konrad: ''Bosch Autoelektrik und Autoelektronik. Boardnetze, Sensoren und elektronische Systeme'', 6. Auflage, Vieweg+Teubner Verlag, Wiesbaden 2011


[2] Zimmermann, Werner; Schmidgall, Ralf: ''Bussysteme in der Fahrzeugtechnik. Protokolle, Standards und Softwarearchitektur'', 5., aktualisierte und erweiterte Auflage, Springer Vieweg Verlag, Wiesbaden 2014




<!-- Fügen Sie diesen Footer hinzu.  -->
<!-- Fügen Sie diesen Footer hinzu.  -->
→ zurück zum Inhaltsverzeichnis: [http://193.175.248.52/wiki/index.php/Projekt_76:_LIN_Demonstrator Inhaltsverzeichnis]


→ zurück zur Übersicht: [[:Kategorie:Projekte_AET_BSE_WS2018|WS 18/19: Fachpraktikum Elektrotechnik (BSE)]]
→ zurück zur Übersicht: [[:Kategorie:Projekte_AET_BSE_WS2018|WS 18/19: Fachpraktikum Elektrotechnik (BSE)]]

Aktuelle Version vom 17. Januar 2019, 23:12 Uhr


→ zurück zur Übersicht: WS 18/19: Fachpraktikum Elektrotechnik (BSE)

Autoren: Blunck, Schaffer
Betreuer: Prof. Schneider

Arduino mit LIN-Shield

Aufgabe

Sensoren und Aktoren eines Kfz sollen über einen LIN BUS angesteuert werden. Visualisieren Sie die Daten mit CANoe.

Erwartungen an die Projektlösung

  • Recherche zum LIN BUS
  • Beschaffen Sie kostenlos LIN fähige Sensoren und Aktoren aus dem Kraftfahrzeug (Sponsoring, Schrottplatz)
  • Ein Arduino mit LIN Shield soll einen Sensor auslesen und einen Aktor ansteuern.
  • Überwachen Sie den Datenverkehr mit CANoe.
  • Test und wiss. Dokumentation
  • Live Vorführung der Kommunikation

Hinweise:

  • Dieses Projekt ist nur mit viel Kreativität und Eigeninitiative zu lösen. Sie sollten Spaß an Bussystemen im Kraftfahrzeug haben.
  • Dieses Projekt wurde zweifach vergeben. Stimmen Sie sich mit dem anderen Team ab, damit zwei unterschiedliche Demonstratoren entstehen.

Einleitung

In diesem Projekt wird ein LIN - Demonstrator entwickelt und ein Aktor mithilfe des LIN-Protokolls angesteuert. Der LIN - Demonstrator wird mithilfe von ausgewählten Bauteilen aufgebaut. Die verwendeten Bauteile sind in einem nachfolgenden Kapitel dargestellt. Als Aktor wird ein Xenon Scheinwerfer eines Audi Q7 verwendet. Der Xenon Scheinwerfer kann über einen Schrittmotor in horizontaler und vertikaler Richtung verstellt werden. Als Kommunikationsprotokoll wird das LIN-Protokoll verwendet, um Nachrichten zwischen zwei Mikrocontroller zu versenden. Die Mikrocontroller (Arduino Uno) dienen dabei stellvertretend als Steuergeräte.

Grundlagen LIN - Protokoll

In diesem Kapitel werden einige Grundlagen zum Verständnis dieses Projektes erläutert. Für dieses Projekt muss die Funktionsweise und der Aufbau des LIN-Busses bekannt sein. Hinzu muss für diese Kommunikation die Zweidrahtkommunikation des Arduinos auf eine 1-Draht Kommunikation umgewandelt werden, wofür der LIN-Transceiver benötigt wird.

Funktionsweise LIN-Bus

LIN (Local Interconnect Network) ist ein junges Bussystem, welches ende der 90er Jahre entwickelt wurde. Es wird für einfache Sensor-Aktor-Anwendungen mit relativ geringen Echtzeitanforderungen verwendet, wie zum Beispiel der Tür-, Sitz- oder Schiebedachelektronik oder der Ansteuerung des Scheinwerfers eines Autos. Der LIN-Bus ist die kostengünstige Alternative zu dem Low-Speed-CAN Bussystemen. Auf der Bitübertragungsschicht kommt eine UART-Übertragung (8 Datenbits, 1 Startbit, 1 Stoppbit) zum Einsatz. Mögliche Bitraten liegen im Bereich von 1 bis 20 kbit/s. Das LIN-Bussystem besteht aus einem Master-Knoten, der i. d. R gleichzeitig Gateway zu einem übergeordneten CAN-Netzwerk ist. Alle restlichen Knoten sind Slave-Knoten, die nach Anforderungen des Masters ihre Datenpakete verschicken können. Jeder LIN-Knoten beherbergt in der Software eine Slave Task, der Master Knoten besitzt ebenfalls eine Slave-Task und zusätzlich den Master-Task. Zusätzlich besitzt der Master-Knoten ein LIN-Schedule, was ein hinterlegter Zeitplan ist, in dem festgelegt ist, welcher Slave wann abgefragt werden soll, die sogenannten Frame Slots. Zu Beginn eines Frame Slots sendet der Master den Frame Header, der von dem passenden Slave Task zu einem LIN-Frame komplettiert wird.

In der Abbildung 1 ist das LIN-Kommunikationsprinzip dargestellt. Der Master-Knoten sendet den Header auf den Bus. Die Slaves hören den Bus ab und erkennen anhand des Headers, ob sie antworten müssen oder nicht. Muss ein Slave antworten, fügt er seine Response hinter den Header. Zwischen Header und Response befindet sich jeweils ein Response Space und zwischen einer Response und einem Header befindet sich ein Interframe Space. Das sind jeweils willkürliche Bits, die nicht direkt zum LIN-Protokoll gehören.

Der Aufbau eines LIN-Frames ist in der Abbildung 2 dargestellt. Einzuteilen ist das Frame in einen Header und eine Response. Der Header wird von dem Master und die Response von dem Slave erstellt. Im Folgenden wird der genaue Aufbau des LIN-Frames dargestellt.

Header

Der Header besteht aus dem Break-Field, dem SYNC-Field und dem Protected-Identifier-Field. Das Break-Field besteht aus mindestens 13 Bits und signalisiert den Start des LIN-Frames. Es werden 13 dominante Bits (logisch 0) und anschließend 1 Delimeter-Bit (logisch 1) gesendet. Auf das Break-Field folgt das SYNC-Field. Das SYNC-Field wird definiert als das hexadezimale Zeichen x55. Das Sync-Field ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren. Das Protected-Identifier-Field ist das letzte Datenpaket, das vom Master-Task im Header übertragen wird. Es identifiziert jede Nachricht im Netzwerk und bestimmt letztendlich, welche Knoten im Netzwerk welche Übertragung empfangen und welche darauf antworten. Alle Slave-Tasks warten ständig auf Identifikatoren, verifizieren ihre Parität und stellen fest, ob sie diesen bestimmten Identifikator ausgeben oder abfragen.

Response

Die Response besteht aus dem Response Space, dem Data-Fields und der Checksum. Der Response Space ist wie oben erklärt eine zufällige Bitfolge, die aufgrund des zeitlichen Versatzes zwischen dem Header und der Response befindet. Auf den Response Space folgt das Data-Field. Das Data-Field besteht aus einem Startbit, 8 Datenbits und einem Stoppbit. Die Übertragung der Datenbytes erfolgt über das Little-Endian Prinzip, d. h das LSB (least significant Bit) wird als Erstes eingefügt. Es können bis zu 8 Nutzdatenbytes eingefügt werden. An letzter Stelle der Response befindet sich die Checksum. Die Checksum dient zur Überprüfung der erfolgreichen Übertragung. Mittels Modulo-256-Arithmetik wird die Checksum gebildet. Die einzelnen Datenbytes werden per Modulo-256-Arithmetik addiert, wobei jedes überlaufende Bit zum jeweiligen Zwischenergebnis addiert wird. Schließlich wird das Gesamtergebnis inverteirt und als Checksum in die Response eingefügt. Ein Empfänger führt denselben Algorithmus bis auf die Invertierung mit den empfangenen Datenbytes durch. Falls die Summe aus den Datenbytes und der Checksum nicht 0xFF ist, hat ein Übertragungsfehler stattgefunden und die Kommunikation muss erneut durchgeführt werden.

Funktionsweise LIN-Transceiver

Abb. 3: LIN-Transceiver MCP2004

Beschreibung

Für das Projekt wird der LIN-Transceiver MCP2004 der Firma Microchip verwendet. Dieser Transceiver stellt eine physikalische Schnittstelle zwischen einem Mikrocontroller und einem LIN-Bus dar. Dafür wandelt er die CMOS/TTL-Logik des Mikrocontrollers in die passende LIN-Bus-Logik um und umgekehrt. Für die Kommunikation zwischen Mikrocontroller und Transceiver wird die USART-Schnittstelle des Arduino Unos genutzt.

Der LIN-Transceiver MCP2004 hat folgende Eigenschaften:

  • Kompatibel mit LIN-Bus-Spezifikationen 1.3, 2.0, 2.1, SAE J2602
  • Unterstützung von Baudraten bis zu 20Kbaud
  • Schutz gegen 43V Spannungsspitzen (bspw. Lastabwurf bei der Lichtmaschine)
  • ESD & EMI geschützt
  • Versorgungsspannung: 6.0V bis 27.0V
  • Temperaturbereich: -40°C bis +125°C

Aufbau

Abb. 4: Blockschaltbild des LIN-Transceivers
Abb. 4: Blockschaltbild des LIN-Transceivers

Das Blockschaltbild visualisiert den inneren Aufbau des Transceivers. Dabei fällt auf, dass diverse Absicherungen, wie ein Kurzschlussschutz und ein Abschaltmechanismus, beim Erreichen von zu hohen Temperaturen, verbaut sind. Der LIN-Bus Pin ist gegen Kurzschlüsse und Verlust des Erdpotentials (Ground) gesichert. Intern ist dieser mit einer Diode und einem Pull-Up-Widerstand versehen.

Weiterführend zeigt die Abb. 5 die Belegung der Anschlusspins am PDIP-Gehäuse.

Abb. 5: Anschlusspins des LIN-Transceivers


  • Pin 1: Receive Data Output
  • Pin 2: Chip Select
  • Pin 3: Fault reporting/TXD Dominant Time-out
  • Pin 4: Transmit Data Input
  • Pin 5: Ground
  • Pin 6: LIN Bus
  • Pin 7: Battery Positive
  • Pin 8: Voltage Regulator Enable Output


Betriebsarten
Der LIN-Transceiver unterstützt folgende Betriebsarten:

  • POWER-DOWN MODE
  • READY MODE
  • OPERATION MODE
  • TRANSMITTER OFF MODE

Abb. 6: Zustandsdiagramm der Betriebsarten
Abb. 6: Zustandsdiagramm der Betriebsarten

Damit der Transceiver Daten zwischen Mikrocontroller und dem LIN-Bus vermitteln kann, ist es notwendig den PIN 2 (Chip Select / CS) auf "High" zu setzen. Dafür kann ein digitaler Pin oder die 5V Spannung vom Arduino eingesetzt werden. Der Transceiver bleibt dadurch im Modus "Operation Mode" und lässt den Transmitter durchgängig aktiv. Dieser Vorgang wird jedoch nur für dieses Projekt angewandt und sollte für andere Anwendungen entsprechend angepasst werden.

Anwendung

Um mithilfe des Transceivers Daten senden zu können, wird dieser wie in der Schaltung aus Abb. 7 mit einem Mikrocontroller verbunden. Die Abb. 8 zeigt das LIN-Netzwerk, welches einen Master und mehrere Slaves enthält. Dabei ist jedoch darauf zu achten, dass nach der LIN-Spezifikation 2.1 die Transceiver aller Geräte im Netzwerk durch den LIN-Pin und das Erdpotential (Ground) miteinander verbunden sind. Insgesamt sollte das Netzwerk einen maximalen Abschlusswiderstand zwischen Lin-Bus und Batteriespannungsversorgung von 510 Ohm aufweisen. Die 510 Ohm entsprechen einem Netzwerk von einem Master und 15 Slaves.

Projektdurchführung

In diesem Kapitel wird die eigentliche Projektdurchführung des Projekts beschrieben. Nach und nach werden die einzelnen Testergebnis bis zum fertigen Endergebnis dargestellt.

Projektplan

Der für unser Projekt verwendete Projektplan ist in der Abbildung 9 dargestellt und wird nun erläutert.

Die als Raute dargestellten Ereignisse sind Meilensteine, wie zum Beispiel die Abschlussmesse oder der Erhalt der Bauteile. Hinzu war es uns sehr wichtig während des gesamten Semesters kontinuierlich zu arbeiten, was zum Beispiel an der Dokumentation oder der Recherche zu sehen ist. Es kann gesagt werden, dass wir anhand des Projektplans unser Projekt zeitlich passend fertigstellen konnten. Unsere Einteilung des Projektes zu Beginn konnte kontinuierlich abgearbeitet werden.

Verwendete Bauteile

Anzahl Bauteil
2 12 V DC Netzteil
2 Arduino Uno
1 Audi Q7 Scheinwerfer
1 Steckbrett
1 Steckbrücken-Drahtbrücken Set
1 Motor Stepper Servo Shield
2 LIN-Transceiver
2 220 kOhm Widerstände
2 4.7 kOhm Widerstände
2 50 Ohm Widerstände
2 1 kOhm Widerstände
2 100 nF Kondensator
2 220 pF Kondensator
2 1 µF Kondensator
4 Standarddiode 1N4148

Scheinwerfer als LIN fähigen Aktor


Im folgendem Abschnitt wird ein Versuchsaufbau erläutert, um den Scheinwerfer für das Projekt als LIN fähigen Aktor verwenden zu können. Dafür wird zunächst der Aufbau des Scheinwerfers beschrieben, das benötigte Motortreiber-Shield erläutert und ein Versuch für die Ansteuerung erklärt.

Anschlussplan Scheinwerfer

In diesem Kapitel ist der Anschlussplan des Scheinwerfers dargestellt. Die verschiedenen Pins für die Spannungsversorgung sind in der Abbildung 10 und die Zuweisungen der verschiedenen Spulenpaare des Motortreibers zum Ansteuern der Schrittmotoren sind in der Abbildung 11 dargestellt.

Schrittmotortreiber-Shield

Da der Scheinwerfer wie bereits erwähnt, Schrittmotoren für die Bewegung des Kurvenlichts besitzt, können diese nicht ohne eine spezielle Ansteuerungseinheit betrieben werden. Damit die Motoren mit dem Arduino Uno verwendet werden können, kommt das "Schrittmotortreiber-Shield L293D" (s. Abb. 12) zum Einsatz. Das Motortreiber-Shield kann bis zu zwei Schrittmotoren, vier Gleichstrommotoren und zwei Servomotoren ansteuern. Dafür sind auf dem Shield vier H-Brücken verbaut (s. Abb. 13). Jede H-Brücke liefert 0,6A Strom (1,2A Spitzenstrom) und arbeitet mit einer Spannung von 4,5V bis 36V DC. Für die Ansteuerung von Schrittmotoren existiert bereits eine fertige Bibliothek, welche für den Arduino Uno eingesetzt werden kann. Diese Bibliothek stellt diverse Funktionen zur Verfügung, sodass auch zwei Schrittmotoren unabhängig voneinander angesteuert werden können. Dafür müssen die Schrittmotoren an die Terminalblocks M1, M2, M3 und M4 des Shields angeschlossen werden. Die Anschlüsse M1 & M2 oder M3 & M4 sind als Paar jeweils für einen Schrittmotor vorgesehen. Da ein bipolarer Schrittmotor zwei verschiedene Spulenpaare besitzt (meist mit A, A/,B, B/ bezeichnet), sind jeweils passende Anschlüsse für eine Spule (bspw. M1) auf dem Shield montiert. Die Abbildung 11 zeigt die entsprechenden Spulen und deren Terminalblockbezeichner, sodass diese einfach an der angegebenen Klemme (s. Abb. 12) angeschlossen werden müssen.

Versuchsaufbau "Erste Inbetriebnahme"

In diesem Kapitel ist der Versuchsaufbau zum Ansteuern eines Audi Q7 Scheinwerfers dargestellt. Die Abbildung 14 enthält hinzu die Beschriftung der einzelnen Bauteile.

Damit der Scheinwerfer als Aktor eingesetzt werden kann, wurde dieser zunächst in Betrieb genommen. Dafür wurden die Anschlüsse (Abb. 10 u. 11) für die Spannungsversorgung und die Schrittmotoren identifiziert. Anschließend folgte der Aufbau der ersten Inbetriebnahme nach dem Schaltplan aus Abb. 15.

Versuchsdurchführung

Zu Beginn des Versuchs wurde der Xenon-Brenner an die Spannungsversorgung angeschlossen. Damit der Xenon-Brenner jedoch korrekt betrieben werden kann, wird ein Netzteil mit 12 V DC und 10 A benötigt, da beim Einschaltvorgang eine höhere Stromaufnahme (etwa 8 A) vorliegt als im weiteren Betrieb (etwa 3,5 A). Nachdem die Funktionsfähigkeit des Xenon-Brenners bestätigt werden konnte, wurden die Anschlüsse für das Fernlicht und für den Blinker an die Spannungsversorgung angeschlossen. Auch hier konnte eine erfolgreiche Inbetriebnahme festgehalten werden. Im nächsten Schritt wurde die Verstellung des Kurvenlichts getestet. Dafür kam ein Arduino Uno mit Motor-Shield zum Einsatz, weil die Schrittmotoren für die vertikale und horizontale Verstellung angesteuert werden mussten. Das Motor-Shield hat die Möglichkeit zwei verschiedene Schrittmotoren anzusteuern und diese bei Bedarf mit einer externen Spannungsquelle zu versorgen. Der Schaltplan in Abb. 15 zeigt die Verkabelung für die jeweiligen Schrittmotoren.

Kommunikation zweier Arduinos über LIN-Bus


In diesem Kaptitel wird die Kommunikation über einen LIN-Bus mit 2 Arduinos (Master und Slave) getestet. Zu Beginn wird der Versuchsaufbau mit der Versuchsdurchführung erläutert. Anschließend werden zwei LIN-Shields entwickelt, auf denen die Schaltungen des Masters und des Slaves platziert werden sollen. Die Umsetzung der Schnittstelle, die in diesem Versuch eingesetzt wird, folgt im anschließenden Kapitel Ansteuerung des Kurvenlichts über LIN-Bus. Dabei werden mithilfe eines PAP-Designs die Programmabläufe grafisch dargestellt und weitere Erläuterungen gegeben.

Versuchsaufbau

In den Abbildungen 16 bis 18 sind der Versuchsaufbau für das Testen der Kommunikation zwischen dem Master und dem Slave dargestellt. In der Abbildung 17 ist die LIN-Nachricht mit einem Osilloskop aufgenommen worden.

Test der Kommunikation

Zuerst wurde lediglich der Master(Arduino in Abbildung 16) getestet. Von dem Master werden die Werte 99 und 123 mithilfe der ersten beiden Datenbytes auf den LIN-Bus gelegt. Das Ergebnis ist in der Abbildung 17 zu sehen. Das gemessene Signal am Oszilloskop zeigt das typische Muster eines LIN-Protokolls. Zuerst werden in unserem Beispiel 16 dominante Bits (logisch 0 - ca. 1V) gesendet. Die rezessiven Bits (1) entsprechen ca. 12V, die an dem Bord und somit an den LIN-Transceivern angelegt werden. Mithilfe des in der Abbildung 18 dargestellten Versuchsaufbaus ist es nun möglich zwischen dem rechten Arduino (Master) und dem linken Arduino (Slave) zu kommunizieren. Der LIN-Bus ist das grüne Kabel. Mit diesem Ergebnis wird nun in dem nächsten Kapitel der Audi Q7 Scheinwerfer mithilfe des LIN Protokolls angesteuert.

Ansteuerung des Kurvenlichts über LIN-Bus


In diesem Kapitel wird die eigentliche Aufgabe dieses Projektes durchgeführt. Mithilfe des LIN-Protokolls wird der Schrittmotor des Xenon Brenners angesteuert und die Kommunikation zwischen dem Master und Slave des LIN-Bus mithilfe von CANoe überwacht.

Programmablaufplan Master und Slave

In diesem Kapitel sind jeweils die beiden Programmablaufpläne des Masters und des Slaves dargestellt. Zuerst sendet der Master ein festgelegtes Datenpaket an den Slave. Der Slave überprüft das Datenpaket mithilfe der Checksumme auf Richtigkeit. War die Datenübertragung ohne Fehler, so steuert der Slave das Kurvenlicht des Scheinweifers in Abhängigkiet des gesendetem Datenpakets an. In unserem Beispiel wird der Scheinwerfer nacheinander um 100 Einheiten nach links, um 100 nach unten, um 100 Einheiten nach rechts und um 100 Einheiten nach oben angesteuert. Somit bewegt sich der Scheinwerfer in einem Quadrat.

Software Programm

Um Datenpakete über den LIN-Bus zu verschicken, wurde für den Arduino Uno eine Schnittstelle programmiert, die es dem Benutzer erlaubt, dem Master und dem Slave eigene Adressen zuzuweisen und mit einer gewünschten Baudrate zu kommunizieren. Diese Schnittstelle wurde als eigene Bibliothek in der Hochsprache C/C++ entwickelt und kann für jeglichen Arduino (z.B. Uno, Mega, Due) verwendet werden. Die Bibliothek stellt öffentliche Funktionen zum Lesen und Schreiben von Datenpaketen bereit und verwendet private Funktionen für interne Prozesse wie die Berechnung der Checksumme oder der Umsetzung von anderen Elementen des LIN-Protokolls.
Die Bibliothek wurde speziell für dieses Projekt bzw. Demonstration zugeschnitten, sodass nicht alle Möglichkeiten des LIN-Protokolls in Verbindung mit dem Transceiver im vollem Umfang ausgeschöpft wurden. Jedoch können die gewünschten Implementierungen für spätere Projektideen jederzeit in die Bibliothek mit integriert werden. Somit stellt diese Schnittstelle eine gute Basis für Erweiterungen dar. Um die Funktionen verwenden zu können, muss die Bibliothek einfach in ein Arduino-Sketch/-Projekt inkludiert werden. Daraufhin kann eine Instanz mit den gewünschten Parametern angelegt und dessen Funktionen im Programm an geforderter Stelle aufgerufen werden.

Das Programm, dass auf dem Master und auf dem Slave ausgeführt wird, kann unter dem nachfolgenden SVN-Link eingesehen werden:

SVN-LINK Arduino Programm

Versuchsaufbau und Versuchsdurchführung

Abb. 21: Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator

Der Versuchsaufbau zum Ansteuern des Kurvenlichts wird in diesem Kapitel erklärt und ist in der Abbildung 21 zu sehen. An dem Scheinwerfer und an den Anschlüssen des Steckbretts werden 12V angelegt. Die Spannung von 12V wird an dem Steckbrett angelegt, da die LIN-Transceiver bzw. der LIN-Bus mit dieser Spannung betrieben werden muss. Die Arduinos erhalten die Betriebsspannung über den USB-Anschluss des angeschlossen PCs. Der Master-Arduino sendet die eingestellte Nachricht auf den LIN-Bus und der Slave setzt diese Nachricht um. Der Scheinwerfer wird nun über einen Motortreiber von dem Slave angesteuert. Als weiteres Vorgehen steht nur noch die Entwicklung der LIN-Shields aus. Nach Fertigung der Shields müssen sie nur noch final getestet werden.






















Überwachen des Datenverkehrs mit CANoe

In diesem Kapitel ist die Inbetriebnahme der Vector Software zum Überwachen des Datenverkehrs dargestellt. Hierzu muss der LIN-Bus mithilfe des in der Abbildung 22 dargestellten Steckers an den PC mit der installierten Software angeschlossen werden. Die Pinbelegung des Steckers kann unter dem folgenden Link eingesehen werden: https://assets.vector.com/cms/content/products/VN16xx/docs/VN1600_Interface_Family_Manual_DE.pdf

Die Datenverkehrsüberwachung konnte nicht vollständig durchgeführt werden, da wie in der Abbildung 23 dargestellt ein Fehler beim Auslesen auftrat. Der beschriebene Fehler besagt, dass das Delimeter Feld eine inkorrekte Länge hat. Da wir die Baudrate beim Arduino gesenkt haben, um mindestens 13 dominante Bits als Break zu senden, ist das Delimeter Feld folglich zwei rezessive Bits anstatt einem rezessiven Bit. Somit kann die Software keine zu 100% exakte LIN-Nachricht erkennen und zeigt deswegen Fehler an. Dieses Problem zu lösen erfordert weitere Änderungen an dem Protokoll, was den Aufwand überschreiten würde.

Entwicklung eines LIN-Shields

In diesem Kapitel werden die, für das Projekt geforderten, Platinen beschrieben. Eine Platine dient dabei als Arduino-Shield für den Master, welches der Schaltung auf dem Steckbrett aus der Abbildung 18 entspricht. Die andere Platine wird für den Slave verwendet und die entsprechende Schaltung kann aus der Abbildung 18 entnommen werden. Um das Vorgehen zu erläutern, wird zu Beginn der Versuchsaufbau dargestellt und die Durchführung des Versuchs erklärt.

Platinenlayout

Da eine Anforderung, die Entwicklung eines LIN-Shields für den Arduino, war, wurde für den "Arduino Uno Rev 3" ein passendes Shield mithilfe der Software "Ultiboard" entworfen und im Anschluss mittels Fräsmaschine die Platine gefertigt. Die Schaltung entspricht dabei der gleichen, wie aus der Abbildung 18, sodass sichergestellt werden konnte, dass die Schaltung funktionsfähig ist. Die Bauteile wurden vom Steckbrett auf die Platine gelötet und der Transceiver auf einen Sockel gesteckt. Dies hat den Vorteil, dass bei fehlerhafter Bedienung der Transceiver gewechselt werden kann. Außerdem wurden Stiftleisten verbaut, damit das Shield auf den Arduino gesteckt werden kann. Das Shield besitzt des Weiteren Pin-Anschlüsse für die externe Verkabelung (Spannungsversorgung, LIN-Bus).

Im Gegensatz zum Master konnte für den Slave jedoch kein Shield entworfen werden, da auf dem Arduino Uno bereits ein Shield für die Ansteuerung der Schrittmotoren befestigt ist. Um dennoch eine saubere Schaltung für das Projekt verwenden zu können, wurde stattdessen eine einfache Platine entworfen, welche alle notwendigen Pin-Anschlüsse für die entsprechenden Schnittstellen des Arduinos usw. aufweist. Ebenfalls wurde auch auf dieser Platine ein Sockel für den Transceiver verbaut, um diesen bei Beschädigungen wechseln zu können.

LINK: Mithilfe dieses Links können die Schaltpläne der Platinen im SVN eingesehen werden

Funktionstest der Platinen

Nachdem alle Platinen fertigt bestückt wurden, mussten diese schließlich in Betrieb genommen werden, um beispielsweise Beschädigungen durch den Lötvorgang festzustellen. Dafür wurden mit einem Durchgangsprüfer eines digitalen Multimeters zunächst alle Pins durchgetestet, ob diese eventuelle störende Masseverbindungen (außer Erdpotentialanschluss -> Ground) aufweisen. Nach der erfolgreichen Prüfung wurden die Platinen anschließend nach entsprechender Vorgabe an die Mikrocontroller usw. angeschlossen. Auch dieser Vorgang verlief fehlerfrei, sodass die Platinen mit dem LIN-Bus verbunden wurden. Nach dem Einschalten aller Geräte konnte der Funktionstest als erfolgreich festgehalten werden. Die Arduinos kommunizierten einwandfrei miteinander und das Kurvenlicht des Scheinwerfers bewegte sich wie gewünscht.

Ergebnis

Unser Projektergebnis wird in diesem Kapitel dargestellt. Auf der linken Seite befindet sich der Master, der ein erstelltes Datenpaket auf den Bus legt. Das Signal auf dem LIN-Bus ist mit dem Oszilloskop dargestellt. In der Mitte befindet sich ein Netzteil, an dem wir 12V einstellen, um den Scheinwerfer anzusteuern und den LIN-Bus mit Spannung zu versorgen. Auf der rechten Seite befindet sich der Slave, der die gesendeten Daten auf dem LIN-Bus. Bei passender, gesendeter ID steuert der Slave den Motortreiber an, der den Schrittmotor nacheinander nach links, runter, rechts und hoch ansteuert (die Richtigen sind in Fahrtrichtung angegeben).

Das Ergebnis ist am besten in dem nachfolgenden Video zu sehen

Zusammenfassung

Als Abschluss zur Projektdokumentation wird im Folgendem eine Zusammenfassung in Form von gesammelten Erfahrungen während des Projektverlaufs und eines Ausblicks gegeben.

Lessons Learned

Rückblickend kann festgehalten werden, dass die Wahl der Arbeitsreihenfolge vorteilhaft für das Projekt war. Die Recherche half dabei, um sich zunächst einen Überblick über das gesamte Thema zu verschaffen. Auch das bestehende Wissen zu Bussystemen aus dem Bachelorstudium stellte eine gute Basis dar und konnte bei der Programmierung erstmals verwendet werden. Beim Sichten der benötigten Bauteile konnten weitere vertiefende Erfahrungen im Bereich der Elektrotechnik gesammelt werden und das Erstellen eines Anschlussplans für den Aktor stellte sich als Herausforderung dar, da keine öffentlichen zugänglichen Quellen zum Aufbau des Scheinwerfers existieren. Diese Herausforderung konnte aber durch bestehende Erfahrungen in der Elektrotechnik und in der Antriebstechnik schnell gelöst werden. Das Designen eines Schaltplans und Anfertigen der Platinen konnten jeweils als ergänzende Vertiefungen gesehen werden. Das Bestücken der Bauteile entsprach einer guten praxisnahen Übung im Bereich der Löttechnik. Weiterführend wurde beim Programmieren der Schnittstelle zwischen Mikrocontroller und LIN-Bus das Wissen im Bereich der hardwarenahen Programmierung in der Hochsprache C/C++ vertieft. Auch das unterschiedliche Wissens- und Erfahrungsniveau der Projekterschaffer war eine interessante Erfahrung, weil in Problemsituationen die jeweiligen Individuen ergänzende Wissenstände für eine schnelle Lösungsfindung aufwiesen und direkt einsetzen konnten.

Ausblick

Weiterführend gesehen sollte das LIN-Protokoll weiter angepasst werden, damit eine einwandfreie Überwachung mit CANoe sichergestellt werden kann. Außerdem könnten neue Platinen für neue Anwendungen angefertigt werden, da die im Projekt verwendeten Platinen nur für die beschriebene Demonstration angefertigt wurden. Vorstellbar wäre auch ein komplexeres LIN-Netzwerk aufzubauen, um damit verschiedene Sensoren und Aktoren anzusteuern.

Projektunterlagen

Sämtliche in diesem Projekt verwendeten Unterlagen und Dokumente sind im SVN unter dem nachfolgenden Link einzusehen:

SVN-Link LIN-Demonstrator

YouTube Video

Das Ergebnis dieses Projekts kann unter folgendem YouTube Video entnommen werden:

Projektvideo

Weblinks

Datenblatt LIN-Transceiver MCP2004

Arduino Uno Rev3

Aufbau LIN Nachricht

LIN-Protokoll

CANoe-Adapter

Motortreiber-Shield

Infos zu Schrittmotoren

Literatur

[1] Reif, Konrad: Bosch Autoelektrik und Autoelektronik. Boardnetze, Sensoren und elektronische Systeme, 6. Auflage, Vieweg+Teubner Verlag, Wiesbaden 2011

[2] Zimmermann, Werner; Schmidgall, Ralf: Bussysteme in der Fahrzeugtechnik. Protokolle, Standards und Softwarearchitektur, 5., aktualisierte und erweiterte Auflage, Springer Vieweg Verlag, Wiesbaden 2014


→ zurück zum Inhaltsverzeichnis: Inhaltsverzeichnis

→ zurück zur Übersicht: WS 18/19: Fachpraktikum Elektrotechnik (BSE)