Fachhochschule Jena
Fachbereich Elektrotechnik

Diplomarbeit

Antriebscontroller mit CAN-Interface

eingereicht von Jörg Böttge

Themenausgabe: 18.01.2000
Abgabedatum 17.04.2000

Inhaltsverzeichnis

Verzeichnis der Abbildungen und Tabellen
Verzeichnis verwendeter Abkürzungen

1. Aufgabenstellung 1

1.1. Eingrenzung des Aufgabenumfanges 1

2. Voruntersuchungen 2

2.1. Linearachse 2
2.2. Servoverstärker 2
2.3. Feldbussystem 3
2.4. Mikrocontroller 3
2.5. Software 4

3. Konzept des Antriebscontrollers

3.1. Hardware 5
3.2. Software 6

4. Hardwareumsetzung

4.1. Entwurf 7
4.1.1. Vorüberlegungen
4.1.1.1. Platine 8
4.1.1.2. Bauteile 9
4.1.1.3 Schnittstellen 9
4.1.2. Baugruppen
4.1.2.1. Netzteil 10
4.1.2.1.1. 5V-Versorgung 10
4.1.2.1.2. 12V-Versorgung 10
4.1.2.2. Mikrocontroller
4.1.2.2.1. Blockschaltbild 12
4.1.2.2.2. Takterzeugung 13
4.1.2.2.3. RESET-Logik 13
4.1.2.2.4. Programmier-Spannung 13
4.1.2.2.5. BDM-Interface 14
4.1.2.2.6. Digitale Ein-/ Ausgänge 14
4.1.2.3. CAN-Interface 14
4.1.2.4. RS232 15
4.1.2.5 Analogausgang 15
4.1.2.6. Externe Logik 16
4.1.2.6.1. Hardware 16
4.1.2.6.2. Software im EPLD 17

4.2. Realisierung
4.2.1. Bauteilbeschaffung 18
4.2.2. Platine 18
4.2.3. Bestückung
4.2.3.1. Durchkontaktierungen 19
4.2.3.2. SMD-Bauelemente 19
4.2.3.3. Konventionelle Bauelemente 20
4.2.4. Elektrische Prüfung 21
4.2.5. Funktionsprüfung 21

5. Softwareumsetzung 22

5.1. Architektur des Mikrocontrollers 22
5.1.1. CPU12 22
5.1.2. Digitale Portpins 23
5.1.3. Registerblock 24
5.1.4. Betriebsarten 24
5.1.5. Flash EEPROM 24
5.1.6. EEPROM 25
5.1.7. RAM 25
5.1.8. Interrupt- und RESET-Logik 25
5.1.9. Timer 26
5.1.10. PWM 26
5.1.11. Serielles Interface 27
5.1.12. CAN-Controller 27
5.1.13. A/D-Wandler 27

5.2. Software im Mikrocontroller 28
5.2.1. Protokolldefinition 28
5.2.1.1. Befehlsvorgabe 29
5.2.2. Deklarationen 30
5.2.3. Beschreibung der Unterprogramme 30
5.2.3.1. Unterprogramm ‘Absolut_Pos’ 30
5.2.3.2. Unterprogramm ‘Regelung’ 31
5.2.3.3. Unterprogramm ‘send0’ 31
5.2.3.4. Unterprogramm ‘Start_Ini’ 32
5.2.3.5. Unterprogramm ‘Abstand’ 32
5.2.3.6. Unterprogramm ‘Test_CAN’ 32
5.2.3.7. Unterprogramm ‘initall’ 33
5.2.3.8. Unterprogramm ‘_hc12’/ Quelltext „hc12.s“ 33
5.2.3.9. Unterprogramm ‘_inithc12’/ Quelltext „hc12.s“ 33
5.2.4. Hauptprogramm 34

5.3. Software im EPLD 34
5.3.1. Richtungs-Diskriminator 35
5.3.2. 24Bit-Zähler 35
5.3.3. Register bzw. Adreßdekoder 35
5.3.4 Zusammenwirken der Teilkomponenten 36

6. Umsetzung in Praktikumsversuch

6.1. Konzept
6.1.1. Hardware 36
6.1.2. Software
6.1.2.1. Visualisierungssoftware 37
6.1.2.2. fuzzyTech® 38
6.1.2.3. Compiler 39
6.1.2.3.1. Batch-Datei 39
6.1.2.3.2. Link-Definition-File 40
6.1.2.3.3. Initialisierungsroutine „crts.s“ 40
6.1.2.4. Debugger/ Downloader 41

6.2. Kurzbeschreibung des Praktikumsversuches 41
6.2.1. Versuchsvorbereitung 41
6.2.2. Generierung der Regeln 42
6.2.3. Übertragen des Regelwerkes 42
6.2.4. Evaluierung der Regelung 42

7. Ergebnis 43

7.1. Nebenentwicklung 43

8. Ausblick 44

Anhang A - Stromlaufpläne und Fertigungsunterlagen

A1. Stromlaufpläne
A1.1. Stromversorgung A-2
A1.2. Mikrocontroller A-3
A1.3. BDM-Interface/ RESET A-4
A1.4. Schnittstelle CAN A-5
A1.5. Digitale I/O A-6
A1.6. Analogausgang A-7
A1.7. Encoder-Auswertung A-8
A1.8. Alternative Kommunikationskomponenten A-9

A2. Fertigungsunterlagen
A2.1. Durchkontaktierungen A-10
A2.2. Bestückungsplan A-11
A2.3. Layout A-12
A2.4. Stückliste A-13

Anhang B - Software

B1. Mikrocontroller
B1.1. Programmablaufpläne
B1.1.1. Hauptprogramm B-3
B.1.1.2. Unterroutine ‘_main’ B-4
B.1.1.3. Unterroutine ‘initall’ B-8
B.1.1.4. Unterroutine ‘_inithc12’ B-9
B.1.1.5. Unterroutine ‘Absolut_Pos’ B-10
B.1.1.6. Unterroutine ‘Test_CAN’ B-11
B.1.1.7. Unterroutine ‘Start_Ini’ B-12
B.1.1.5. Unterroutine ‘send0’ B-13
B.1.1.6. Unterroutine ‘Regelung’ B-14
B1.2. Quelltexte
B1.2.1. Quelltext von „iob32can.s“ B-15
B1.2.2. Quelltext des Hauptprogrammes B-19
Unterroutine ‘Absolut_Pos ‘ B-20
Unterroutine ‘Regelung‘ B-21
Unterroutine ‘send0‘ B-21
Unterroutine ‘Start_Ini‘ B-21
Unterroutine ‘Abstand‘ B-22
Unterroutine ‘Test_CAN‘ B-22
Unterroutine ‘initall‘ B-22
B1.2.3. Quelltext von „hc12.s“ B-24
Unterroutine ‘_hc12’ B-25
Unterroutine ‘_inithc12’ B-25
B1.2.4. Quelltext von „crts.s“ B-26

B 2. EPLD
B2.1. Übersichtsbild B-27
B2.2. Richtungsdiskriminator B-28
B2.3. 24Bit-Zähler B-29
B2.4. Register/ Adreßdekoder B-30
B2.5. Projektdatei B-31

B3. Software zur Programmierung (PC)
B 3.1. Quelltext von „f_prakt.bat“ B-52
B3.2. Quelltext von „linkdef.asm“ B-53

Anhang C - Versuchsanleitung für Praktikumsversuch

C1. Praktikumsanleitung C-2
C2. Adressliste C-7
C3. Kabelverbindungen und Jumper C-8

Selbständigkeitserklärung
Danksagung
Literaturverzeichnis

Verzeichnis der Abbildungen und Tabellen

Abbildung 1 - Blockschaltbild des Gesamtsystems 5
Abbildung 2 - Oberfläche von EAGLE 7
Abbildung 3 - Blockschaltbild des Mikrocontrollers 12
Abbildung 4 - Oberfläche von MAX+plus II 17
Abbildung 5 - Photo des Antriebscontrollers 20
Abbildung 6 - Registerstruktur des Mikrocontrollers 23
Abbildung 7 - Visualisierungssoftware 38
Tabelle 1 - Telegrammstruktur 29
Tabelle 2 - Befehlsvorgabewerte 29

Verzeichnis verwendeter Abkürzungen

[...]

1. Aufgabenstellung

Thema: Antriebscontroller mit CAN-Interface

• chaltungsentwurf für das Antriebscontroller-Board
• Aufbau und Test des Boards
• Entwicklung Treibersoftware
• Umsetzung in einen Praktikumsversuch

1.1. Eingrenzung des Aufgabenumfanges

Ziel der Entwicklungsarbeit sollte es sein, einen Antriebscontroller zu designen. Dieser sollte als Basis für einen Praktikumsversuch zum Thema „Fuzzy-Regelung“ dienen. Die Studenten sollten dabei die Möglichkeit haben, eigene Regelungen zu erstellen und in einer realen Hardware-Plattform auszutesten. Eine (Echtzeit-)Visualisierung sollte weiterhin ermöglichen, direkte Rückschlüsse auf die Qualität der erstellten Regelung zu ziehen.

Als zusätzliche Forderungen standen:

• = Zusammenarbeit mit den vorhandenen CAN [1]-Komponenten,
• = Nutzung von fuzzyTech® zur Implementierung veränderlicher Fuzzy-Regeln,
• = Ansteuerung der vorhandenen Linearachse unter Beibehaltung des Servoverstärkers und
• = effiziente Nutzung der gerätetechnischen Ressourcen beim Entwurf der Platine.

2. Voruntersuchungen

Um die gestellten Forderungen effizient umsetzen zu können, war es sinnvoll, im Vorfeld abzuklären, welche Lösungsansätze zum gewünschten Resultat führen würden. Das wohl wichtigste Kriterium war dabei, schon vorhandene Hard- als auch Software optimal einzusetzen, um bei geringem Kostenaufwand ein gutes Ergebnis zu erzielen. Es versteht sich von selbst, daß dies nicht zu Lasten der Qualität erfolgen durfte.

2.1. Linearachse

Die Linearachse als Element der Aktorik war durch Nutzung in vorhergehenden Praktikumsversuchen ausreichend evaluiert. Es bot sich deshalb an, auf ein vorhandenes Exemplar zurückzugreifen. Damit waren in diesem Bereich keine Investitionen zu tätigen, und durch die Resonanz der Studenten bei vorhergehenden Praktikumsversuchen war die Anschaulichkeit des Demonstrationsobjekts bestätigt. Da der Antriebscontroller universell konzipiert werden sollte, wurden keine Anstrengungen zur Optimierung der aktorischen Seite unternommen. Es war lediglich sicherzustellen, daß beim letztendlichen Versuchsaufbau alle Komponenten harmonisch zusammen arbeiten. Es sprach also nichts dagegen, die vorhandene Linearachse zu verwenden.

2.2. Servoverstärker

Ähnlich Punkt 2.1. verhielt es sich auch mit dieser Baugruppe. Es gab keinen Grund, der den zusätzlichen Aufwand zur Anschaffung eines neuen Gerätes gerechtfertigt hätte. Der vorhandene Servoverstärker war auf die Linearachse abgestimmt. Freilich hätte ein neues Modell bei entsprechender Auswahl die zu entwerfende Ausgangsstufe des Antriebscontrollers vereinfacht, wenn nicht der Norm-Spannungsbereich von +/- 10V eingesetzt worden wäre. Allerdings stünde dies im Gegensatz zum universellen Konzept des Antriebscontrollers, so daß letztlich zu Gunsten des vorhandenen Servoverstärkers entschieden wurde. 

2.3. Feldbussystem

Im Fachbereich Elektrotechnik bestanden zum Zeitpunkt des praktischen Teils dieser Arbeit erhebliche Erfahrungen im Umgang mit dem CAN-System. Anhand dessen und der nur für dieses Bussystem vorhandenen kostenintensiven Gerätetechnik für Test und Inbetriebnahme verbot es sich von vornherein, auf ein anderes System umzusteigen. Die Entscheidung für eine Verwendung des CAN-Busses stand somit fest.

2.4. Mikrocontroller

Eine kurze Betrachtung des Marktes zeigte, daß es nur wenige Mikrocontroller gab, die entweder ein CAN-Interface hardwareseitig aufwiesen oder sich dieses einfach (hard- und softwareseitig) anschließen ließ.
Weiterhin sollte der Mikrocontroller hardwareseitig Fuzzy-Befehle unterstützen (nicht durch Software-Emulation) und angesichts des Standes der Technik mit mindestens 16Bit arbeiten. Ein eventuell notwendiger Compiler durfte nicht den begrenzten Kostenrahmen sprengen. Angesichts letzter Überlegung schied vorerst  der C166[2] aus.
Dem Projekt vorangegangene Untersuchungen hatten gezeigt, daß der MC68HC912BC32 von Motorola mittelfristig mit CAN-Interface verfügbar sein würde (Markteinführung noch nicht erfolgt) und schon Musterexemplare vorrätig waren. Dieser Mikrocontroller zeichnete sich dadurch aus, daß er ein CAN-Interface besaß und weiterhin on Board nützliche Peripheriekomponenten sowie Speicher (RAM/ Flash) vorhanden waren. Dies würde den Entwicklungsaufwand der Hardwareseite minimieren, und die gut überschaubare Architektur sollte sich auch beim Softwareentwurf als nützlich erweisen.

Geräteseitig gibt es an der Fachhochschule Jena die notwendige Technik (z.B. Lötstation), um auch SMD [3]-Bauelemente manuell verarbeiten zu können. Da der MC68HC912BC32 in der Bauform QFP280 geliefert wird, war dies Vorausetzung. Aus diesen Überlegungen resultierte der Entschluß, auf Basis der vorhandenen Musterexemplare das Antriebscontrollerboard aufzubauen.

2.5. Software

Wie schon in 1.1 erwähnt, sollte letztendlich fuzzyTech® zum Einsatz kommen. Die Recherche ergab, daß zu vorteilhaften Konditionen eine Update der vorhandenen Version zur Controller- Edition möglich war.
Zur Programmierung des MC68HC912BC3 [4] gab es ein günstiges Angebot von Cosmic Software GmbH, welches sich um Größenordnungen von der Alternative Keil (für den C166) unterschied. Dies bestätigte nochmals die Entscheidung, den Mikrocontroller von Motorola zu verwenden. Zur Erstellung der Logik im EPLD [5] wurde MAX+plus II von Altera verwendet, da im Labor ‘Digitale Schaltungstechnik’ vorhanden.

3. Konzept des Antriebscontrollers
3.1. Hardware

[...]

1 CAN (engl.) - Controller Area Network
2 C166 - Mikrocontroller von Siemens
3 SMD (engl.) - Surface Mounted Device
4 QFP (engl.) - Quad Flat Pack
5 EPLD (engl.) - Erasable Programmable Logic Device