Antriebscontroller mit CAN-Interface

Inhaltsverzeichnis

Verzeichnis der Abbildungen und Tabellen Verzeichnis verwendeter Abkürzungen

1. Aufgabenstellung
1.1. Eingrenzung des Aufgabenumfanges

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

3. Konzept des Antriebscontrollers
3.1. Hardware
3.2. Software

4. Hardwareumsetzung
4.1. Entwurf
4.1.1. Vorüberlegungen
4.1.1.1. Platine
4.1.1.2. Bauteile
4.1.1.3 Schnittstellen
4.1.2. Baugruppen
4.1.2.1. Netzteil
4.1.2.1.1. 5V-Versorgung
4.1.2.1.2. 12V-Versorgung
4.1.2.2. Mikrocontroller
4.1.2.2.1. Blockschaltbild
4.1.2.2.2. Takterzeugung
4.1.2.2.3. RESET-Logik
4.1.2.2.4. Programmier-Spannung
4.1.2.2.5. BDM-Interface
4.1.2.2.6. Digitale Ein-/ Ausgänge
4.1.2.3. CAN-Interface
4.1.2.4. RS232
4.1.2.5 Analogausgang
4.1.2.6. Externe Logik
4.1.2.6.1. Hardware
4.1.2.6.2. Software im EPLD
4.2. Realisierung
4.2.1. Bauteilbeschaffung
4.2.2. Platine
4.2.3. Bestückung
4.2.3.1. Durchkontaktierungen
4.2.3.2. SMD-Bauelemente
4.2.3.3. Konventionelle Bauelemente
4.2.4. Elektrische Prüfung
4.2.5. Funktionsprüfung

5. Softwareumsetzung
5.1. Architektur des Mikrocontrollers
5.1.1. CPU12
5.1.2. Digitale Portpins
5.1.3. Registerblock
5.1.4. Betriebsarten
5.1.5. Flash EEPROM
5.1.6. EEPROM
5.1.7. RAM
5.1.8. Interrupt- und RESET-Logik
5.1.9. Timer
5.1.10. PWM
5.1.11. Serielles Interface
5.1.12. CAN-Controller
5.1.13. A/D-Wandler
5.2. Software im Mikrocontroller
5.2.1. Protokolldefinition
5.2.1.1. Befehlsvorgabe
5.2.2. Deklarationen
5.2.3. Beschreibung der Unterprogramme
5.2.3.1. Unterprogramm ‘Absolut_Pos’
5.2.3.2. Unterprogramm ‘Regelung’
5.2.3.3. Unterprogramm ‘send0’
5.2.3.4. Unterprogramm ‘Start_Ini’
5.2.3.5. Unterprogramm ‘Abstand’
5.2.3.6. Unterprogramm ‘Test_CAN’
5.2.3.7. Unterprogramm ‘initall’
5.2.3.8. Unterprogramm ‘_hc12’/ Quelltext „hc12.s“
5.2.3.9. Unterprogramm ‘_inithc12’/ Quelltext „hc12.s“
5.2.4. Hauptprogramm
5.3. Software im EPLD
5.3.1. Richtungs-Diskriminator
5.3.2. 24Bit-Zähler
5.3.3. Register bzw. Adreßdekoder
5.3.4 Zusammenwirken der Teilkomponenten

6. Umsetzung in Praktikumsversuch
6.1. Konzept
6.1.1. Hardware
6.1.2. Software
6.1.2.1. Visualisierungssoftware
6.1.2.2. fuzzyTech®
6.1.2.3. Compiler
6.1.2.3.1. Batch-Datei
6.1.2.3.2. Link-Definition-File
6.1.2.3.3. Initialisierungsroutine „crts.s“
6.1.2.4. Debugger/ Downloader
6.2. Kurzbeschreibung des Praktikumsversuches
6.2.1. Versuchsvorbereitung
6.2.2. Generierung der Regeln
6.2.3. Übertragen des Regelwerkes
6.2.4. Evaluierung der Regelung

7. Ergebnis
7.1. Nebenentwicklung

8. Ausblick

Anhang A - Stromlaufpläne und Fertigungsunterlagen
A1. Stromlaufpläne
A1.1. Stromversorgung
A1.2. Mikrocontroller
A1.3. BDM-Interface/ RESET
A1.4. Schnittstelle CAN
A1.5. Digitale I/O
A1.6. Analogausgang
A1.7. Encoder-Auswertung
A1.8. Alternative Kommunikationskomponenten
A2. Fertigungsunterlagen
A2.1. Durchkontaktierungen
A2.2. Bestückungsplan
A2.3. Layout
A2.4. Stückliste

Anhang B - Software
B1. Mikrocontroller
B1.1. Programmablaufpläne
B1.1.1. Hauptprogramm
B.1.1.2. Unterroutine ‘_main’
B.1.1.3. Unterroutine ‘initall’
B.1.1.4. Unterroutine ‘_inithc12’
B.1.1.5. Unterroutine ‘Absolut_Pos’
B.1.1.6. Unterroutine ‘Test_CAN’
B.1.1.7. Unterroutine ‘Start_Ini’
B.1.1.5. Unterroutine ‘send0’
B.1.1.6. Unterroutine ‘Regelung’
B1.2. Quelltexte
B1.2.1. Quelltext von „iob32can.s“
B1.2.2. Quelltext des Hauptprogrammes
Unterroutine ‘Absolut_Pos ‘
Unterroutine ‘Regelung‘
Unterroutine ‘send0‘
Unterroutine ‘Start_Ini‘
Unterroutine ‘Abstand‘
Unterroutine ‘Test_CAN‘
Unterroutine ‘initall‘
B1.2.3. Quelltext von „hc12.s“
Unterroutine ‘_hc12’
Unterroutine ‘_inithc12’
B1.2.4. Quelltext von „crts.s“
B 2. EPLD
B2.1. Übersichtsbild
B2.2. Richtungsdiskriminator
B2.3. 24Bit-Zähler
B2.4. Register/ Adreßdekoder
B2.5. Projektdatei
B3. Software zur Programmierung (PC)
B 3.1. Quelltext von „f_prakt.bat“
B3.2. Quelltext von „linkdef.asm“

Anhang C - Versuchsanleitung für Praktikumsversuch
C1. Praktikumsanleitung
C2. Adressliste
C3. Kabelverbindungen und Jumper

Selbständigkeitserklärung

Danksagung

Literaturverzeichnis

Verzeichnis der Abbildungen und Tabellen

Abbildung 1 - Blockschaltbild des Gesamtsystems

Abbildung 2 - Oberfläche von EAGLE

Abbildung 3 - Blockschaltbild des Mikrocontrollers

Abbildung 4 - Oberfläche von MAX+plus II

Abbildung 5 - Photo des Antriebscontrollers

Abbildung 6 - Registerstruktur des Mikrocontrollers

Abbildung 7 - Visualisierungssoftware

Tabelle 1 - Telegrammstruktur

Tabelle 2 - Befehlsvorgabewerte

Verzeichnis verwendeter Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

1. Aufgabenstellung

Thema:

Antriebscontroller mit CAN-Interface

-Schaltungsentwurf 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¹ -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 Antriebscontrol- lers 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² 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 Peripherie- komponenten sowie Speicher (RAM/ Flash) vorhanden waren. Dies würde den Entwicklungs- aufwand 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³ -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 MC68HC912BC32 gab es ein günstiges Angebot von Cosmic Soft- ware Gmbh, welches sich um Größenordnungen von der Alternative Keil (für den C166) un- terschied. Dies bestätigte nochmals die Entscheidung, den Mikrocontroller von Motorola zu verwenden.

Zur Erstellung der Logik im EPLD⁴ wurde MAX+plus II von Altera verwendet, da im Labor ‘Digitale Schaltungstechnik’ vorhanden.

3. Konzept des Antriebscontrollers

3.1. Hardware

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Blockschaltbild des Gesamtsystems

Aus den in 2. angesprochenen Komponenten sollte das Antriebscontroller-System aufgebaut werden. Das Zusammenspiel der Komponenten läßt sich leicht aus Abbildung 1 erkennen. Kernstück ist der MC68HC912BC32 mit integriertem Speicher, Peripherieunterstützung und CAN-Interface. Da der Mikrocontroller keine direkten Analogausgänge aufweist, wurde ein vorhandener PWM⁵ -Ausgang mittels RC-Glied und Verstärker entsprechend aufbereitet, so daß am Ausgang +/- 10V zur Ansteuerung des Servoverstärkers zur Verfügung gestellt wer- den konnten.

Zur Positionsbestimmung wurde der an der Linearachse vorhandene inkrementelle Geber verwendet. Die abgegebenen TTL⁶ -Impulse wurden mittels externer Logik (EPLD) aufbereitet und direkt als Absolutposition dem Mikrocontroller zur Verfügung gestellt. Das CAN-Interface wurde mittels eines PCA82C250⁷ von Phillips nach außen geführt.

3.2. Software

Der Antriebscontroller arbeitet ähnlich einer klassischen SPS⁸. Der Mikrocontroller liest also zu Beginn jedes Programmzyklusses Vorgaben über das CAN-Interface sowie die digitalen und analogen Eingänge ein. Dann erfolgen die Behandlung der Sollvorgaben durch den Feld- bus und die Berechnung der Stellgrößen durch den Fuzzy-Algorithmus. Nach einer Prüfung der Grenzwerte erfolgt, so eine Stellwertausgabe erlaubt ist, das Setzen der Ausgangswerte. Letztlich werden die aktuellen Istwerte auf den Feldbus ausgegeben, bevor die Prozedur wie- der von vorn beginnt.

Dieses Konzept hat sich in der Praxis ausreichend bewährt, und die Leistungsfähigkeit des Mikrocontrollers in Verbindung mit der restlichen Peripherie erlaubten es, auf komplizierte Interrupt-Behandlungen und Multitasking zu verzichten.

Die geringe Komplexität des Projekts machte es unnötig, in einer Hochsprache zu programmieren. So wurden alle Routinen in Assembler geschrieben, was die Arbeit in hardwarenahen Anwendungen meines Erachtens sehr erleichtert.

4. Hardwareumsetzung

4.1. Entwurf

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Oberfläche von EAGLE

Das Board wurde konsequent mit dem Layout-Editor EAGLE⁹ (Abbildung 2) erstellt. Konse- quent bedeutet in diesem Fall, daß alle verwendeten Bauteile als Bibliothekselemente mit Symbol und Pad generiert wurden, wenn diese nicht als Standard-Bauelement zur Verfügung standen.

Vor dem Entwurf mußten allerdings einige Fragen (siehe 4.1.1) geklärt werden, um nicht am Ende eine Fehlentwicklung getätigt zu haben.

4.1.1. Vorüberlegungen

4.1.1.1. Platine

Von Beginn des Projektes an stand fest, daß der Antriebscontroller, da ein Einzelstück, im Hause von Hand gefertigt werden sollte.

Es bestand also nur die Wahlmöglichkeit zwischen ein- und zweiseitiger Bestückung. Nach Rücksprache mit dem Betreuer bezüglich der Größe - Maximum sollte Europaformat sein - und unter Berücksichtigung der Bauteilgeometrien war die Auswahl zu Gunsten der zweisei- tigen Platine gefallen. Eine einseitige Platine hätte einen hohen Prozentsatz an Brücken erfor- derlich gemacht, welche sich vom Arbeitsaufwand und der Zuverlässigkeit äußerst ungünstig gestalten.

Es sollte versucht werden, die Anzahl von Durchkontaktierungen zu minimieren, da sich diese von Hand immer aufwendig gestalten. Nach Möglichkeit sollten dafür vorhandene Bauteilanschlüsse verwendet werden.

Um EMV¹⁰ -Problemen vorzubeugen und weiterhin den Verbrauch an Ätzmittel zu minimie- ren, wurden freie Flächen auf beiden Layern mit Masse-Potential versehen. Letztlich blieb noch die Frage zu klären, ob die Platine geätzt oder gefräst werden sollte. Be- trachtungen vorliegender gefräster Muster favorisierten allerdings die geätzte Variante, da bei den gefrästen Modellen die Qualität (variierende Frästiefe, unscharfe Kanten) unzureichend

für die vorliegenden SMD-Bauelemte war. Weiterhin wäre es schwierig gewesen, eine exakte Deckung der Layer zu erreichen.

Die geätzte Variante würde eine ausreichend hohe Qualität liefern, jedoch auch einen zusätzlichen Fertigungsaufwand (Einbringen aller Bohrungen) bedeuten. Dies wurde jedoch auf Grund der überwiegenden Vorteile gern in Kauf genommen.

4.1.1.2. Bauteile

Aus den Überlegungen in 4.1.1.1. verbot es sich, die Schaltung komplett in SMD auszuführen. Es wurde also versucht, den kostengünstigsten Kompromiß zu finden.

Für die meisten aktiven Bauelemten war dies in der Ausführung SMD gegeben. Bei den pas- siven Bauelementen gestaltete es sich so, daß vor allem größere Kondensatoren als Normal- Bauelemente wesentlich kostengünstiger waren als ihr SMD-Äquivalent. Da es sich hierbei auch meistenteils um mehrfach verbundene Potentiale handelte, wurde der Einsatz von Nor- mal-Bauteilen bevorzugt.

4.1.1.3. Schnittstellen

Bei den Schnittstellen-Steckern gibt es neben dem Kostenaspekt noch einen anderen Punkt zu berücksichtigen: die mechanische Belastbarkeit. Aus diesem Grund wurden prinzipiell keine SMD-Verbinder eingesetzt.

Da in der Konzeptphase keine Festlegungen bezüglich Gehäuseaufbau bestanden, wurde für die meisten Verbinder der kostengünstige Pfostenstecker verwendet. Lediglich CAN, RS232¹¹ und Netzanschluß wurden robuster ausgeführt, um beim Prototyping nicht schon eine Zerstörung der Platine zu riskieren.

4.1.2. Baugruppen

4.1.2.1. Netzteil

Es ist Stand der Technik, ein externes Netzadapter bei Geräten kleiner Leistung zu verwenden. Deshalb wurde das Netzteil so konzipiert, daß es die Schaltung bei EingangsGleichspannungen zwischen 7V und 12V sicher versorgt und auf einen Transformator sowie Gleichrichtung verzichtet.

Um den Antriebscontroller vor Zerstörung zu schützen, wurde weiterhin ein Verpolschutz (V1, S. A-2) vorgesehen.

4.1.2.1.1. 5V-Versorgung

Dank dem heutigen Stand der Halbleiterentwicklung gestaltet sich die Bereitstellung einer Standardspannung recht einfach.

In unserem Fall mußten dazu nur ein LM7805 (U1) mit entsprechender Siebung eingesetzt werden. Diode V2 dient dem Schutz des IC¹² gegen Rückspannungen.

4.1.2.1.2. 12V-Versorgung

Hierzu wurde ein handelsüblicher Spannungswandler NMH0512 (U2) eingesetzt. Dieser vereint kleines Volumen mit stabilisierter Ausgangsspannung bei einem vernünftigen Preis. Es erübrigt sich der Einsatz von Induktivitäten (teuer, groß, schwer beschaffbar) als Alternative eines selbstgebauten Schaltnetzteils.

Bei Betrachtung des Stromlaufplanes im Anhang A kommt vielleicht die Frage auf, warum der DC/DC-Wandler mit aus den stabilisierten 5V versorgt wird (höhere Verlustleistung, ge- ringerer Wirkungsgrad). Dies hat zwei einfache Gründe: Erstens wird die Konstanz der 12V- Ausgangsspannung nur in einem engen Eingangsspannungsbereich gewährleistet, und zweitens wird mittels der vorgeschaltenen Induktivität und Ausregelung durch den LM7805 das Risiko einer EMV-Rückwirkung auf den Eingang reduziert.

4.1.2.2. Mikrocontroller

4.1.2.2.1. Blockschaltbild

Abbildung 3 - Blockschaltbild des Mikrocontrollers

Abbildung in dieser Leseprobe nicht enthalten

4.1.2.2.2. Takterzeugung

Für unser Anwendungsfeld war es nicht notwendig, hochgenaue Zeitreferenzen zur Verfügung zu haben. Aus diesem Grund wurde der MC68HC912BC32 mit einer StandardQuarzbeschaltung (Q1, C9, C10, R4, S. A-3) von 16MHz versehen.

4.1.2.2.3. RESET-Logik

Entgegen dem Beispiel des vorhandenen Entwicklungsboardes wurde auf den Einsatz externer Logik verzichtet. Diese ist nicht zwingend notwendig, da der Mikrocontroller intern alle notwendigen Timings selber erzeugt. Es wurden deshalb nur ein RESET-Taster und Pins (S1, X6, S. A-4) zum etwaigen externen Anschluß eines solchen vorgesehen.

4.1.2.2.4. Programmier-Spannung

Etwas verwundern mag vielleicht die aufwendige Erzeugung der Programmierspannung für den internen Flash.

Im Gegensatz zu mittlerweile verfügbaren Mikrocontrollern benötigt der MC68HC912BC32 noch 12V zum Programmieren des Flash. Nach Problemen mit der Fertigung hat Motorola kurzerhand die Spezifikation dieser Spannung geändert, so daß diese nur noch max. 11,4V betragen darf. Deshalb die zusätzliche Stabilisierung mit Z-Diode (R6, V7, S. A-3).

4.1.2.2.5. BDM-Interface

Die Architektur des Mikrocontrollers gestattet es leider nicht, im Fehlerfall (oder bei Inbe- triebnahme) ein Urladeprogramm über die serielle Schnittstelle auszuführen. Das bedeutet, daß ein entsprechendes Programm über das BDM¹³ -Interface mittels eines zweiten Mikrocon- trollers eingespielt werden muß, bevor der Mikrocontroller seine Programmabarbeitung auf- nehmen kann.

Das BDM-Interface (S. A-4) wurde entsprechend der Motorola-Spezifikation verschalten.

4.1.2.2.6. Digitale Ein-/ Ausgänge

Notwendige Eingänge, z.B. Absolut-Position vom inkrementellen Geber, wurden direkt auf die Pins des Mikrocontrollers geführt, u.U. nach einer Pegelanpassung mittels Spannungsteiler. Details hierzu finden sich auf S. A-6.

Sämtliche Kommunikationsschnittstellen bedienen sich der digitalen I/O¹⁴, damit konnten diese auch 1:1 verbunden werden.

Der einzige notwendige digitale Ausgang konnte dank ausreichender Strombelastbarkeit (20mA) direkt das entsprechende Relais (K1, S. A-7) ansteuern.

4.1.2.3. CAN-Interface

Dank der guten Anpassung an Standard-Treiber konnte der Mikrocontroller nahezu 1:1 mit dem PCA82C250 (U4, S. A-5) verdrahtet werden.

Um auch optisch eine Kontrolle über den Busverkehr zu haben, wurde eine Mehrfarb-LED (V8) mit den umgesetzten TTL-Pegeln des Busses beaufschlagt.

Um alle möglichen CAN-Konfigurationen abzudecken, gab es im Prototyp die Möglichkeit, einen Abschlußwiderstand von 120? mittels Jumper zuzuschalten (R15, X10, S. A-9) oder auch 5V auf den Bus zur Versorgung externer Geber zu legen (X9). Bei der Realisierung für den Praktikumsversuch wurde jedoch auf diese Erweiterungen verzichtet.

4.1.2.4. RS232

Im Entwurfsstadium war erwogen worden, zur Programmierung die serielle Schnittstelle zu nutzen. Deswegen wurde ein RS232-Interface (S. A-9) in den Prototyp eingebaut. Es besteht aus einem MC145407 mit den notwendigen Kondensatoren zur Spannnungserzeugung laut Applikationsschrift.

Auch hier wurden die TTL-Pegel mit einer Mehrfarb-LED visualisiert.

4.1.2.5. Analogausgang

Der MC68HC912BC32 stellt leider keine Analogausgänge zur Verfügung. Deshalb wurde ein PWM-Ausgang zuerst auf ein RC-Glied (R22, C24, S. A-7) geführt.

Damit lassen sich jedoch nur Spannungen zwischen 0V und 5V erzeugen. Um auf die Norm- spannung von +/- 10V zur Ansteuerung des Servoverstärkers zu kommen, mußte deshalb noch ein OPV¹⁵ (U5) gesetzt werden. Dieser arbeitet als invertierender integrierender Verstärker in Bezug auf die halbierte 5V-Spannung. Damit ergibt sich dann die gewünschte Ausgangsspan- nung.

Der Verstärkungsfaktor des OPV wurde größer als notwendig eingestellt. Damit werden Verluste im RC-Glied ausgeglichen.

Da durch Auflösung der PWM nie ein Wert von genau Null ausgegeben werden kann bzw. sich der Abgleich/ die Kompensation des OPV gegen Nullpunktdrift als zu aufwendig/ in- stabil erwiesen haben, wurde ein Relais (K1) vorgesehen, das bei Bedarf den (über Widerstand R25 geschützten) Ausgang des OPV kurzschließt. Dies hat sich im praktischen Versuch als äußerst komfortabel erwiesen, da dadurch auch eine Pseudo-Notabschaltung realisiert werden kann, die schneller reagiert als die Entladung des RC-Gliedes.

4.1.2.6. Externe Logik

Bei der Konzeption wurde mangels Erfahrung mit dem MC68HC912BC32 festgelegt, die Aufbereitung der Encoder-Impulse - dieses ist ein relativer Geber - in externer Logik auszu- führen.

Nun wurde jedoch nicht, wie vielleicht erwartet, nach einem handelsüblichen Schaltkreis gesucht oder die Logik mittels TTL etc. ausgeführt. Auf Grund im Hause vorhandener Technik wurde vielmehr beschlossen, einen EPLD vom Typ EPM7128 zu programmieren.

4.1.2.6.1. Hardware

Die Umsetzung in Hardware war relativ einfach. Der EPLD mußte nur mit den Stützkondensatoren, Masse- und Spannungsversorgungen laut Applikation versorgt werden; weiterhin wurden die Steuerleitungen 1:1 mit dem Mikrocontroller verdrahtet (U6, C30..38, S. A-8). Erste Voruntersuchungen am Encoder zeigten erhebliche EMV-Probleme, die durch diesen eingeschleust wurden (Quelle vermutlich Servoverstärker). Diese bestanden aus einer HFSchwingung mit überlagertem Rauschen. Auf Grund des hohen Störpegels war es unumgänglich, diese auszublenden. Dazu wurden Lastwiderstände eingebaut (allgemeine Pegelabsenkung) und mit noch je einem RC-Glied pro Signalleitung versehen (R26..29, C28..29). Diese Kombination hat sich als guter Kompromiß zwischen Störunterdrückung und erreichbarer meßbarer Verfahrgeschwindigkeit der Linearachse erwiesen.

4.1.2.6.2. Software im EPLD

Der EPLD wurde mittels MAX+plus-Software (Abbildung 4) programmiert.

Im wesentlichen wurde dazu das Ergebnis eines Praktika der Vertiefungsrichtung „Digitale Schaltungstechnik“ modifiziert.

Zur Erläuterung der Logik:

Die Logik ist streng synchron ausgeführt, was zwar einen höheren Aufwand an Logik erfordert, jedoch mehr Stabilität verspricht.

Zuerst werden die Eingangspulse nach Drehrichtung ausgewertet. Das Resultat wird auf einen Vor-/ Rückwärtszähler in 24Bit geführt. Das Zählergebnis wird bei externer Anforderung durch den Mikrocontroller in ein Register übernommen, welches dann sequentiell (je 8Bit) ausgelesen werden kann. Dies hat den Vorteil, daß der Zähler unabhängig vom Lesevorgang bleibt, weiterhin sind durch das sequentielle Auslesen weniger Busleitungen zum Mikrocon- troller notwendig.

Das Register wird erst wieder freigegeben, wenn es komplett ausgelesen wurde (beliebige Reihenfolge).

Es versteht sich von selbst, daß der Mikrocontroller Zähler und Register rücksetzen kann (und muß - bei Nullpunktinitialisierung).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 - Oberfläche von MAX+plus II

4.2. Realisierung

4.2.1. Bauteilbeschaffung

Wie schon erwähnt, sollten die Kosten für die Entwicklung möglichst minimiert werden.

Aus diesem Grund wurden für den Mikrocontroller vorhandene Muster verwendet bzw. weitere von Motorola kostenfrei angefordert.

Photobeschichtetes Basismaterial wurde der Leiterplatten-Werkstatt entnommen. Der EPLD war im Labor digitale Schaltungstechnik vorrätig.

So mußten nur die restlichen SMD-Bauelemente und spezielle Bauelemente, die nicht im Fundus der Elektronik-Werkstatt vorrätig waren, bei gebräuchlichen Lieferanten, wie z.B. RSComponents und Farnell, beschafft werden.

4.2.2. Platine

Die Platine wurde, nachdem mit EAGLE entworfen und manuell geroutet, mittels eines HP Laserjet auf Transparentpapier ausgedruckt, welches als Photopositiv dienen sollte (siehe auch A2.). Dieser Punkt machte vergleichsweise Schwierigkeiten, da es durch den kleinen Pin- Abstand des MC68HC912BC32 auf äußerste Maßhaltigkeit ankam. Es machte sich erforder- lich, mit einer Vielzahl von Druckern und einer Druck-Kopier-Kombination zu experimentie- ren, um zu befriedigenden Ergebnissen zu gelangen. Es sei in diesem Zusammenhang auf die Schrumpfung des Papiers in thermischen Druckern hingewiesen. Ein Photoplotter, welcher den Arbeitsaufwand an dieser Stelle um ca. 1 Woche verringert hätte, stand leider nicht zur Verfügung.

Das Basismaterial wurde anschließend mittels UV-Belichtungskasten und obiger Vorlagen für 2 Minuten belichtet und weiterhin nach Vorschrift behandelt (Entwickeln mit Natronlauge, Ätzen mit Ammoniumpersulfat). Nach Entfernen des Photolacks und Polieren der Oberfläche wurde beschlossen, zur Verbesserung der Optik und Lötbarkeit eine chemische Verzinnung vorzunehmen, die durch 10minütiges Verweilen der Platine in einer entsprechenden Lösung beendet war.

Nun wurde die Platine noch mit transparentem Lötlack versehen und alle Bohrungen einge- bracht.

4.2.3 Bestückung

4.2.3.1. Durchkontaktierungen

Bevor mit der eigentlichen Bestückung begonnen werden konnte, mußten erst sämtliche Durchkontaktierungen eingebracht werden. Dieser Punkt sollte immer zuerst erfolgen, da später u.U. nicht mehr die Zugänglichkeit gewährleistet ist, da vielleicht Bauelemente Boh- rungen verdecken.

Die Durchkontaktierungen wurden mit Draht vom Durchmesser 0.4mm und beidseitigem Verlöten von Hand vorgenommen.

4.2.3.2. SMD-Bauelemente

Die Bestückung von SMD-Bauelementen von Hand gestaltet sich oftmals nicht einfach. Aus diesem Grund wurden alle Bauelemente (außer dem Mikrocontroller) mit entsprechendem SMD-Klebstoff auf der Platine fixiert. Dies verhindert eine Deplazierung beim anschließenden Löten. Die Erfahrungen bei einem ersten Testmuster hatten gelehrt, daß das Löten mit der vorhandenen Heißluftanlage zwar möglich, aber nicht optimal war. Die thermische Beanspruchung der Bauelemente ist verhältnismäßig groß, weiterhin ist mit dem Auslöten von Durchkontaktierungen zu rechnen. Deshalb wurden die Bauelemente mit einem 20W-Lötkolben mit Nadelspitze und Lötzinn Durchmesser 0.5mm konventionell verlötet.

Kleinere Schwierigkeiten bereitete lediglich das Verlöten des Mikrocontrollers. Hier waren auf einer Länge von etwa einem Zentimeter 20 Verbindungen anzubringen, welches in Handarbeit keine einfache Aufgabe war.

4.2.3.3. Konventionelle Bauelemente

Nach dem Einbringen der SMD-Bauelemte gestaltete sich dieser Schritt als wahres Kinderspiel. Es wurden die selben Lötmittel wie unter 4.2.3.2 verwendet; dank des SMD-Lötzinnes erreichten auch diese Lötungen eine optisch ansprechende Qualität. Es versteht sich von selbst, daß vor dem Löten alle mechanischen Komponenten, wie z.B. Stecker-Befestigungen, eingebracht wurden, um Spannungen an der fertigen Platine zu vermeiden. Als Ergebnis stand die Platine wie in Abbildung 5 zur Verfügung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 - Photo des Antriebscontrollers

4.2.4. Elektrische Prüfung

Wie bei jeder Schaltung, welche als Hauptbestandteil programmierbare Schaltkreise beinhaltet, konnte die elektrische Prüfung nur wenige Grundfunktionen verifizieren. Im wesentlichen wurde die Bereitstellung der wichtigsten Potentiale (Betriebsspannungen, Masse) und Verbindungen überprüft. Dazu dienten gewöhnliche Digitalmultimeter und ein Oszilloskop zum Überprüfen der Takterzeugung.

4.2.5. Funktionsprüfung

Die Funktionsprüfung konnte erst erfolgen, nachdem alle programmierbaren Schaltkreise mit Grundfunktionen versehen waren. Dazu wurde der EPLD, wie unter 4.1.2.6. beschrieben, entworfen und ins System eingesetzt (Stecksockel). Eine einfache Ausleseroutine wurde programmiert (ähnlich Quelltext S. B-16, Zeile 97ff). Mittels Evaluation-Board und zugehörigem Debugger wurde die Funktionalität der externen Logik überprüft, welches erfreulicherweise (da wenig Erfahrung auf diesem Gebiet) keiner Nachbesserungen bedurfte.

Die Funktion der seriellen Schnittstelle wurde überprüft, indem der Debugger von Motorola in den Flash geladen wurde und anschließend das Antriebscontroller-Board als Debugger (Befehlsein- und Ausgabe zum PC über die RS232) für das Evaluation-Board fungierte. Die digitalen Eingänge wurden mittels Auslesen dieser bei verschiedenen angelegten Signalen überprüft.

Die Funktion des digitalen Ausgangs wurde durch Übermitteln der entsprechenden Schaltimpulse getestet.

Auch der Analogausgang konnte durch Vorgabe entsprechender Werte im Debugger und Messung der Pegel einfach überprüft werden.

Das CAN-Interface wurde mittels des CANalyzers von Vector Informatik getestet.

Die angerissenen Prüfungen brachten erfreulicherweise positive Ergebnisse, so daß nun der hauptsächlichen Entwicklungstätigkeit nichts mehr im Wege stand.

5. Softwareumsetzung

Bevor mit der Beschreibung der Programmstruktur begonnen werden kann, ist es unumgänglich, kurz die Teilkomponenten des Mikrocontrollers vorzustellen.

5.1. Architektur des Mikrocontrollers

Der MC68HC912BC32 vereinigt in sich fast alle Komponenten, die zur Entwicklung des An- triebscontrollers notwendig waren. Ein visueller Überblick dazu läßt sich unter 4.1.2.2.1. fin- den.

Bemerkenswert ist, daß sämtliche Spezialfunktionen unabhängig von der CPU¹⁶ arbeiten. Damit ist z.B. bei Kommunikationsarbeiten eine hohe Performance gewährleistet.

5.1.1. CPU12

Kern des Mikrocontrollers ist die CPU. Diese wird von Motorola gern als 16Bit-CPU darge- stellt; nun, angesichts der Registerbreite erscheint dies auch richtig. Allerdings lassen sich viele Befehle nur mit 8Bit Breite ausführen. Weiterhin existieren zwei 8Bit-Akkumulatoren, die nur bedingt als 16Bit-Doppelakkumulator zu verwenden sind. Deshalb erscheint die von Motorola gebrauchte Bezeichnung etwas irreführend, da weiterhin auch der lineare Adreß- raum nur 64kByte groß ist.

Wie erwähnt stehen zwei 8Bit-Akkumulatoren oder ein 16Bit-Akkumulator zur Verfügung. Weiterhin gibt es zwei 16Bit-Indexregister und ein 8Bit-CCR¹⁷ -Register, welches mit den üb- lichen Flags für Übertrag, Parität etc. belegt ist (Abbildung 6). Die geringe Anzahl von Regi- stern mag auf den ersten Blick enttäuschen, da jedoch die meisten Befehle auch direkt auf Speicher anwendbar sind, läßt es sich dennoch komfortabel programmieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 - Registerstruktur des Mikrocontrollers

5.1.2. Digitale Portpins

Der MC68HC912BC32 weist eine Vielzahl (genau 63) von Portpins auf, die im allgemeinen für beliebige Ein- und Ausgabeoperationen komfortabel genutzt werden können. Beim Ent- wurf ist jedoch zu beachten, daß für spezielle Funktionen (z.B. Timer, PWM, Kommunikati- on) nur die dafür vorgesehenen Pins verwendet werden können, so auf die interne Hardware- Unterstützung zurückgegriffen werden möchte. Ein Konzept der freien logischen Verdrahtung der Spezialfunktionen zu allen Portpins (wie z.B. bei EPLD) wäre hier in Zukunft wün- schenswert.

5.1.3. Registerblock

Entgegen der gebräuchlichen Syntax meint Motorola hiermit nicht die Register der CPU, sondern einen Teil des Speicherbereiches, auf den sämtliche Signale der Portpins als auch die Puffer für Spezialfunktionen, z.B. Sendepuffer für CAN, gemappt werden. Es ist dies der Speicherbereich von 0x0000 bis 0x017F. Sämtliche Ein- und Ausgaben der Portpins werden über diesen Registerblock ausgeführt, indem einfach mit der entsprechenden Speicherzelle gearbeitet wird.

5.1.4. Betriebsarten

Sollte der integrierte Speicher des Mikrocontrollers nicht ausreichen, kann selbstverständlich externer Speicher angeschlossen werden. Dies erfordert allerdings die entsprechende Anzahl freier Portpins. Um eine große Flexibilität sicherzustellen, hat Motorola verschiedene Betriebsarten implementiert, mit denen auf externen Speicher zugegriffen werden kann. Es sei hier auf S. 31 ff des Technical Summary verwiesen.

5.1.5. Flash-EEPROM

Der MC68HC912BC32 ist mit 32kByte Flash-EEPROM ausgestattet. Dieser benötigt, wie schon angesprochen, eine externe Programmierspannung von annähernd 12V, was nicht mehr Stand der Technik ist; Mikrocontroller der Mitbewerber arbeiten mittlerweile mit einer einfachen Betriebsspannung von 5V. Die Probleme bezüglich der Programmierspannung wurden bereits in 4.1.2.2.4. dargelegt.

Weiterhin ist es nicht ohne weiteres möglich, den gewünschten Speicher zu allokieren. Viel- mehr muß für jedes geschriebene Byte ein komplexer Programmierzyklus eingehalten werden (vgl. S. 50 des Technical Summary). Dies macht es schwierig, den Speicher für dynamische Aufgaben zu benutzen. Weiterhin ist jeder Programmiervorgang ein zeitintensiver Prozeß (ca. 50ms pro Speicherzelle), so daß sich die Nutzung wirklich auf Programmcode beschrän- ken sollte.

Der Flash-EEPROM kann komplett, in Blöcken zu 32Byte oder Byte- bzw. Wortweise gelöscht werden. Es ist jedoch zu beachten, daß Motorola nur 100 Löschzyklen garantiert, was auch um Größenordnungen unter dem von Mitbewerbern liegt.

5.1.6. EEPROM

Für geringe Datenmengen, die auch ohne Betriebsspannung erhalten bleiben sollen, hat Motorola 768 Byte EEPROM integriert. Dieser kann etwas einfacher als der Flash-EEPROM programmiert werden und hat eine Lebensdauer von 10000 Zyklen.

5.1.7. RAM

Für dynamische Daten stehen 1kByte RAM auf dem Chip zur Verfügung. Bei geschickter Programmierung kann weiterhin ein Teil des Registerblocks (siehe 5.1.3.) zur Speicherung von Variablen mit benutzt werden. Der Einsatz externen Speichers ist nicht zu empfehlen, da bei Zugriff auf diesen ein komplexes Bankswitching vorgenommen werden muß.

5.1.8. Interrupt- und RESET-Logik

Die meisten Spezialfunktionen erlauben, mittels Interrrupt in den Programmfluß einzugreifen. Allerdings muß dies erst mittels entsprechender Flags freigegeben werden. Ein Watchdog-Timer gestattet den Selbsttest des Mikrocontrollers.

Für externe Interrupts steht nur ein maskierbarer Interrupt zur Verfügung; es gibt keine Möglichkeit der Kaskadierung ohne zusätzlichen Interrupt-Controller.

Ein RESET führt auch zur Auslösung eines Interrupt, welcher wie gewohnt dann die RESETAdresse (hier 0xFF80) anspringt.

Alle Interrupts werden über einen Interrupt-Vektor (ab 0xFF80) gehandelt, der im geschützten Boot-Block des Flash-EEPROM liegt.

5.1.9. Timer

Der Mikrocontroller beinhaltet 8 Timer, die für entsprechende Aufgaben auch mittels Portpins genutzt werden können.

Für den Antriebscontroller wurde einer davon programmiert, um den 1MHz-Takt für den EPLD zu generieren.

5.1.10. PWM

Für den Nutzer stehen 4 PWM-Kanäle in 8Bit Auflösung zur Verfügung, die zu 2 Kanälen mit 16Bit kaskadiert werden können.

Zur Ansteuerung des Servoverstärkers wurde beim Antriebscontroller ein Kanal mit 16Bit verwendet, um eine feinfühlige Drehzahlwahl zu ermöglichen.

5.1.11. Serielles Interface

Der MC68HC912BC32 weist ein serielles Interface auf, welches synchronen und asynchronen Betrieb auf unabhängigen Kanälen erlaubt. Gerade das synchrone Interface bietet vielfältige Möglichkeiten zum Anschluß von Peripherie, z.B. seriellem Speicher.

Für den Antriebscontroller war nur das asynchrone Interface zum Aufbau der RS232 von In- teresse.

5.1.12. CAN-Controller

Der integrierte CAN-Controller unterstützt das Standard-Protokoll 2.0A/B.

Drei Sendepuffer erlauben das Bereitstellen von Telegrammen, die dann entsprechend vorgegebener Priorität vom CAN-Controller selbsttätig abgesetzt werden.

Die komplexe Filterstruktur gestattet, sehr variable Empfangsregeln aufzustellen und unterschiedliche Flags bzw. Interrupts auszuwerten.

Der vorhandene einfache Empfangspuffer wird nur in den Vordergrund-Puffer kopiert, wenn dieser vorher von der Software freigegeben wurde. Wurde der Puffer nicht rechtzeitig geleert, wird ein neues Telegramm direkt vom CAN-Controller zurückgewiesen. So kann der andere Busteilnehmer bei Bedarf reagieren und das Telegramm nochmals senden.

5.1.13. A/D-Wandler

Auf dem Chip sind auch 8 Analogeingänge aufgebracht. Diese besitzen jedoch nur eine Auflösung von 8Bit. Für einfache Anwendungen mag dies ausreichen, im Falle des Antriebscontrollers ist damit jedoch nur eine grobe Positioniergenauigkeit bei Nutzung des UltraschallAbstandssensors möglich. Einziger Trost bleibt die hohe Abtastrate - es werden nur 16 Takte bei 8MHz Abtastfrequenz benötigt.

5.2. Software im Mikrocontroller

Wie schon unter 3.2. angedeutet, erfolgt die Programmabarbeitung ähnlich einer klassischen SPS. Zum besseren Verständnis empfiehlt es sich, einen Blick in den Quelltext zu werfen. Dieser ist, wie schon erwähnt, in Assembler geschrieben. Es wurde versucht, ein einfaches Unterprogrammkonzept umzusetzen, um die Lesbarkeit und auch eine eventuelle Softwarewartung zu vereinfachen. Weiterhin wurden, wo möglich und sinnvoll, Konstanten, Variablen bzw. Verweise aus dem selben Grund verwendet.

Ausführliche Programmablaufpläne des Systems finden sich unter B.1.1., Quelltexte unter B.1.2.

5.2.1. Protokolldefinition

Um den Datenaustausch über den Feldbus nachvollziehen zu können, sind einige Anmerkungen über das verwendete Protokoll von Nöten.

Im Grundkonzept war geplant, den Antriebscontroller als einfachen CAN-Open-Slave mit Deviceprofil 301 zu betreiben. Dies hätte allerdings einen erheblichen Zusatzaufwand auf Seite der Visualisierung bedeutet. Da weiterhin die Zeit bis zur Vorstellung des Systems auf der Hannover Messe zu kurz war, wurde vorerst eine vereinfachte Protokollversion implementiert. Diese hält sich in Grundzügen an den Standard.

Als fester Empfangs-ID¹⁸ wurden 0x62A, als Sende-ID für das Gegensystem (Visualisierungssoftware) 0x5AA festgelegt. Index ist immer 0x2000, Subindex 0x00, andere Werte sollten abgewiesen werden.

Die acht Datenbyte des einfachen CAN-Frames wurden wie in Tabelle 1 dargestellt belegt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 - Telegrammstruktur

5.2.1.1. Befehlsvorgabe

Wie angesprochen, selektiert das Hauptprogramm den auszuführenden Befehl. Dieser ist in Datenbyte 5 des Telegramms enthalten.

Die möglichen Befehle und ihre korrespondierenden Werte:

Abbildung in dieser Leseprobe nicht enthalten¹⁹

Tabelle 2 - Befehlsvorgabewerte

[...]

---

¹ CAN (engl.) - Controller Area Network

² C166 - Mikrocontroller von Siemens

³ SMD (engl.) - Surface Mounted Device

⁴ QFP (engl.) - Quad Flat Pack

⁵ EPLD (engl.) - Erasable Programmable Logic Device

⁶ PWM (engl.) - Pulse Width Modulation

⁷ TTL (engl.) - Transistor Transistor Logic

⁸ PCA82C250 - CAN-Treiberschaltkreis

⁹ SPS - Speicherprogrammierbare Steuerung

¹⁰ EAGLE (engl.) - Easily Applicable Graphical Layout Editor

¹¹ EMV - Elektromagnetische Verträglichkeit

¹² RS232 - Standardisierte serielle Schnittstelle

¹³ IC (engl.) - Integrated Circuit

¹⁴ BDM (engl.) - Background Debug Mode

¹⁵ I/O (engl.) - Input/ Output

¹⁶ OPV - Operationsverstärker

¹⁷ CPU (engl.) - Central Processing Unit

¹⁸ CCR (engl.) - Condition Code Register

¹⁹ ID (engl.) - Identifier