Ansteuerung einer Schrittmotor-Achse mit PHOENIXCONTACT AXC 1050: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(295 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Datei:SPS von Phoenix Contact.JPG|450px|thumb|right|Abb.1:Phoenix Contact AXC 1050 mit dem Kommunikationsmodul]]
[[Kategorie:Automatisierungstechnik]]  
[[Kategorie:Automatisierungstechnik]]  
[[Kategorie:2019/ 2020_WS_MTR7_Praktikum_GPE]]
[[Kategorie:2019/ 2020_WS_MTR7_Praktikum_GPE]]
Zeile 8: Zeile 9:
→ zurück zur Übersicht: [[3-D-Bearbeitungsmaschine (Projekt des Schwerpunkts GPE im Studiengang MTR)]]
→ zurück zur Übersicht: [[3-D-Bearbeitungsmaschine (Projekt des Schwerpunkts GPE im Studiengang MTR)]]


= Einleitung =
Im Studiengang Mechatronik der Hochschule Hamm-Lippstadt findet im 7. Semester im Studienschwerpunkt „Global Production Engineering“ das Modul „Global Production Engineering III“ statt. Einen Teil dieses Moduls bildet das Praktikum Produktionstechnik. Im Praktikum sollen die Achsen einer [[3D-CNC-Bearbeitungsmaschine|3D-CNC-Bearbeitungsmaschine]] mit unterschiedlichen Automationshardwares angesteuert werden.
Der folgende Artikel beschäftigt sich mit der Ansteuerung der Achsen mittels einer [[Speicherprogrammierbare Steuerungen (SPS)|SPS]] von Phoenix Contact, nämlich der [[Phoenix Contact AXC Trainer 1050 PN|Phoenix Contact AXC 1050]] (vgl. Abb.1<ref name="[Abb1]"> Abbildung 1: ''eigene Quelle'' </ref>). Das Thema wurde im Wintersemester 2019/2020 erstmalig von Niklas Rohlfs und Connor Royle bearbeitet.


== Einleitung ==
= Aufgabenstellung =
Im Studiengang Mechatronik der Hochschule Hamm-Lippstadt findet im 7. Semester im Studienschwerpunkt „Global Production Engineering“ das Modul „Global Production Engineering III“ statt. Einen Teil dieses Moduls bildet das Praktikum Produktionstechnik. Im Praktikum sollen die Achsen einer 3D-CNC-Bearbeitungsmaschine mit unterschiedlichen Automationshardwares angesteuert werden (vgl. Hauptartikel).
Der folgende Artikel beschäftigt sich mit der Ansteuerung der Achsen mittels einer SPS von Phoenix Contact, nämlich der Phoenix Contact AXC 1050. Das Thema wurde im Wintersemester 2019/2020 erstmalig von Niklas Rohlfs und Connor Royle bearbeitet.


 
Die Aufgabe des Projektes war es, die Achsen der 3D-CNC-Bearbeitungsmaschine mit der Phoenix Contact AXC 1050 anzusteuern. Hierzu sollten von einer anderen Gruppe Koordinaten durch einen [[Zentraler Steuerungsalgorithmus für ein 3-Achs-CNC-Bearbeitungszentrum|zentralen Steuerungsalgorithmus in Matlab]]  als String per [[Broadcast mit RS232|RS232]] an die AXC 1050 gesendet werden. Die Verarbeitung der Koordinaten mitsamt der Berechnung der Verfahrwege sollte dann durch die AXC 1050 geschehen, welche dann zudem die entsprechenden Ausgangssignale an die Schrittmotortreiber der 3D-CNC-Bearbeitungsmaschine weitergeben sollte.
== Aufgabenstellung ==
 
Die Aufgabe des Projektes war es, die Achsen der 3D-CNC-Bearbeitungsmaschine mit der Phoenix Contact AXC 1050 anzusteuern. Hierzu sollten von einer anderen Gruppe Koordinaten durch einen zentralen Steuerungsalgorithmus in Matlab als String per RS232 an die AXC 1050 gesendet werden. Die Verarbeitung der Koordinaten mitsamt der Berechnung der Verfahrwege sollte dann durch die AXC 1050 geschehen, welche dann zudem die entsprechenden Ausgangssignale an die Schrittmotortreiber der 3D-CNC-Bearbeitungsmaschine weitergeben sollte.
Die Aufgabenstellung gliederte sich in diverse Teilaufgaben:
Die Aufgabenstellung gliederte sich in diverse Teilaufgaben:


Zeile 25: Zeile 24:
** Bearbeitung der Aufgaben nach dem V-Modell
** Bearbeitung der Aufgaben nach dem V-Modell


*oder
* Aufbau
** Horizontaler Messbereich: 180°
** Hardwareaufbau mit Kommunikationsmodul erstellen
** Rotationswinkelmessung mit eine Auflösung 1°
** Aufbau der Optokopplerschaltung zur Umwandlung von 24V auf 5V
** Messfrequenz: max.
** Beschriften aller Kabel
** Rotationsfrequenz: maximal für 1° Auflösung
 
** Reichweite: 2cm - 3m
* Datenübertragung
** Winkelrückmeldung über Drehencoder
** RS232-Datenübertragung herstellen
* Beschaffung der Bauteile
** Strings über RS232 empfangen und einlesen
* Schaltungsentwicklung zur Ansteuerung von Sensor und Motor
 
* Modellbasierte Programmierung der Hardware via Simulink
* Programmierung
** Entwicklung der Sensorblöcke in Simulink
** Einlesen der Koordinaten aus dem empfangenen String
** Entwicklung des Motorblocks in Simulink
** String zerlegen (Trennung von Soll- und Ist-Position sowie Vorschub)
** Koordinatentransformation der gemessenen Polarkoordinaten (Winkel, Entfernung) in karthesische Koordinaten
** Berechnung der Schritt- und Richtungswerte aus der Differenz von Ist zu Soll
** Darstellung der Messwerte in karthesische Koordinaten
** Schalten der digitalen Ausgänge
* Bewertung der Ergebnisse mit geeigneter Referenz
** Diagonalfahrten ermöglichen (x und y sollen auch bei unterschiedlicher Fahrstrecke gleichzeitig ankommen)
* Softwareentwicklung nach HSHL Standard in SVN
 
* Darstellung der Funktion in einem YouTube Video
* Dokumentation
* Test und wissenschaftliche Dokumentation
** Dokumentation des eigenen Projektfortschritts in [https://wiki.hshl.de/wiki/index.php/Software_Versionsverwaltung_mit_SVN SVN] (Anforderungsliste, Funktionaler Systementwurf, etc.)
* Live Vorführung während der Abschlusspräsentation
** HSHL-Wiki-Eintrag erstellen
 
= Versuchsdurchführung =
 
Das Vorgehen des Projekts hat sich am [https://de.wikipedia.org/wiki/V-Modell V-Modell]orientiert. Dementsprechend sollten, nachdem die Anforderungen und Teilaufgaben definiert wurden, Systementwürfe erstellt werden. Erst dann folgte die Entwicklungsphase und nach dieser sollten Tests der Komponenten und des Systems anstehen. Mit dieser Vorgehensweise wird verhindert, dass zu Beginn bereits voreilig entwickelt wird, weshalb viele vermeidbare Fehler gar nicht erst enstehen. <br>
 
== Funktionaler Systementwurf ==
 
 


== Aufgabe ==
Beim funktionalen Systementwurf (vgl. Abb.2<ref name="[Abb2]"> Abbildung 2: ''eigene Quelle'' </ref>)soll das Gesamtsystem lösungs- und hardwareneutral dargestellt werden. Somit erhält man eine gute erste Übersicht über die Zusammenhänge der einzelnen Komponenten im Gesamtsystem. In diesem Fall wird ein erstelltes CAD-Modell in eine CAM-Software geladen, welche G-Code Befehle erzeugt. Mit dem jeweiligen Steuerungsprogramm, in diesem Fall der Phoenix Contact SPS, werden die übergebenen Strings dann eingelesen und geben die notwendigen Informationen über die zu tätigen Verfahrwege und Geschwindigkeiten dann an die Schrittmotortreiber weiter, welche die Schrittmotoren der jeweiligen Achsen ansteuern.
Das Wort Sonar ist ein Akronym von „sound navigation and ranging“, dies lässt sich mit Schall-Navigation und -Entfernungsbestimmung übersetzen. Im Projekt soll also eine Sonarstation gebaut werden, die Objekte in ihrer Umgebung wahrnimmt und ortet.
{| class="wikitable"
Zur Umsetzung wird neben dem Mikrocontroller Arduino Uno ein Ultraschallsensor zur Ortung der Objekte verwendet. Dieser Ultraschallsensor ist mit einem Servomotor verbinden, wodurch sich der Sensor um 180° drehen lässt. Der Servomotor wird ebenfalls über den Mikrocontroller angesteuert. Zusätzlich wird ein Bildschirm benötigt, der den Standort der erkannten Objekte sowie deren Entfernung zur Sonarstation ausgibt.
| [[Datei:Funktionaler_Systementwurf.png|800px|thumb|left|Abb. 2: Funktionaler Systementwurf]]
|}


Originaldatei: [[Datei:Funktionaler_Systementwurf_Phoenix_Original.pptx]]


== Planung ==
== Technischer Systementwurf ==
[[Datei:Projektplan_Sonarstation.png|600px|thumb|right|Abb.2:Projektablaufplan]]
Bei der Planung wurde beachtet, dass zu Beginn des Semesters eher weniger Zeit in das Projekt fließt, da parallel noch die Versuche des GET-Praktikums laufen und die Vorbereitung dort zeitintensiv war, weshalb anfangs längere Zeiträume für die Bearbeitung des Projekts berücksichtigt wurden.
Der erste Schritt in der Projektplanung war es Ideen zu sammeln, welches Projekt bearbeitet werden soll. Da am 28.09.2018 die Einführungsveranstaltung stattgefunden hat, wollten wir zu diesem Zeitpunkt bereits ein Projekt ausgewählt haben, um es Prof. Schneider dort kurz vorstellen zu können. Danach wurde sich über Bauteile informiert, die beschafft werden sollen. Hierbei wurde nach einem passenden Ultraschallsensor und einem Servomotor gesucht. <br> Das von der Hochschule vorgegebene Budget für das Projekt betrug ca. 20€. Mit diesem Budget war es möglich die notwendigen Bauteile für die Sonarstation zu beschaffen, allerdings mussten dabei Anpassungen bei den Erwartungen an die Projektlösung vorgenommen werden. So wurde beispielsweise der horizontale Messbereich von 360° auf 180° angepasst, da mit dem Budget kein passender Servo gefunden wurde und zusätzlich dazu noch ein Slip Ring benötigt worden wäre. Außerdem wurde die Reichweite des Ultraschallsensors von 8m auf 3m angepasst, da auch hier kein passender Sensor im vorgegebenen Preisrahmen gefunden wurde, der die 8m erfüllen könnte. Diese Änderungen wurden alle im Vorfeld mit Prof. Schneider abgestimmt.
Die Bauteile wurden auf die BOM geschrieben und von der Hochschule beschafft.
Nach Abgabe der BOM wurde mit der Durchführung begonnen. Hierzu wurden alle Teilaufgaben, die zu bearbeiten waren notiert und ein Ablaufplan erstellt. Die geplanten Zeiträume für die Aufgaben wurden so gut wie möglich abgeschätzt und es wurde versucht, die Fristen möglichst einzuhalten. Durch den erstellten Projektplan sollte sichergestellt werden, dass das Projekt zum Termin der Abschlusspräsentation funktionsfähig vorgestellt werden kann. Die Zeiträume wurden so gewählt, dass das Projekt auch bei ungeplanten Verzögerungen noch fertiggestellt werden kann.


<br/>


==== Verwendete Materialien ====
Nach dem funktionalen Systementwurf wird zudem ein technischer Systementwurf (vgl. Abb.3<ref name="[Abb3]"> Abbildung 3: ''eigene Quelle'' </ref>) erstellt. Bei diesem werden die Schnittstellen zwischen den Systemen konkretisiert.
{| class="mw-datatable"
{| class="wikitable"
! style="font-weight: bold;" | Pos.
| [[Datei:Technischer_Systementwurf_Phoenix.png|800px|thumb|left|Abb. 3: Technischer Systementwurf]]
! style="font-weight: bold;" | Anzahl
! style="font-weight: bold;" | Bezeichnung
! style="font-weight: bold;" | Preis
|-
| 1.
| 1
| HC-SR04 Ultraschall Sensor
| 2,95 €
|-
| 2.
| 1
| Mini Analog Servo SM-S2309S
| 4,95€
|-
| 3.
| 1
| Arduino Uno
| 20,00 €
|-
| 4.
| 1
| USB-A auf USB-B Kabel
| 1,59 €
|-
| 5.
| div.
| Schrauben, Muttern, Kabel ...
|--
|--
|}
|}
<br/>


== Konstruktion der Sonarstation ==
Originaldatei: [[Datei:Technischer_Systementwurf_Phoenix_Original.pptx]]
[[Datei:Grundplatte_Sonarstation.png|450px|thumb|left|Abb.3:Grundplatte der Sonarstation in CAD]]
 
== Einarbeitung in Hard- und Software ==
 
Um den funktionalen und technischen Systementwurf erstellen zu können und die Entwicklung zu starten, war es zu Beginn des Projekts wichtig, sich mit der verwendeten Hardware und Software vertraut zu machen. Die Einarbeitung erfolgte hierbei zu einem großen Teil über die vorhandenen Datenblätter und Beispielprogramme in [https://wiki.hshl.de/wiki/index.php/Software_Versionsverwaltung_mit_SVN SVN], in denen Informationen über die SPS und deren Module sowie über PCWorx zu finden waren. Die wichtigsten Dokumente sind in folgendem SVN-Ordner zu finden:<br/>
*[https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Allgemein/Literatur/PHOENIX_CONTACT/Starterkit_AXC1050/ Literatur PhoenixContact]
 
=== Hardware ===
Im Produktionstechnik-Labor war zu Beginn des Praktikums bereits eine funktionsfähige SPS-Station vorhanden. Eine genauere Beschreibung der Station zeigt der Artikel [[Phoenix Contact AXC Trainer 1050 PN|Phoenix Contact AXC Trainer 1050 PN]]. Dort finden sich zudem die Datenblätter der Steuerung sowie des Digitaleingabe- und Digitalausgabemoduls. <br/>
Mit dem vorhandenen Aufbau konnte das Projekt allerdings nicht vollständig realisiert werden, sondern es mussten noch einige wenige Teile zusätzlich beschafft werden. Hierbei handelte es sich zum einen um ein Kommunikationsmodul der Firma Phoenix Contact. Dieses Modul soll die Kommunikation über RS232 mit anderen Geräten ermöglichen. Zum anderen handelte es sich um Optokoppler, mit denen eine Optokopplerschaltung gebaut werden kann. Diese Schaltung wird benötigt, um die Schrittmotorentreiber anzusteuern. Sie dient dazu, die Ausgangssignale richtig zu dimensionieren, da die Ausgänge der SPS 24V betragen, die Schrittmotortreiber jedoch mit einer Spannung von 3,3V-5V arbeiten.<br/>
Nähere Informationen zum Kommunikationsmodul und den Optokopplern lassen sich in den folgenden Datenblättern finden:<br/>
*[https://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=2688666&library=dede&tab=1/ Kommunikationsmodul]
*[https://asset.conrad.com/media10/add/160267/c1/-/en/000153396DS01/datenblatt-153396-vishay-optokoppler-phototransistor-cny17-3-dip-6-transistor-mit-basis-dc.pdf/ Optokoppler]
 
=== Software ===
Zur Programmierung der AXC 1050 wird das Software-Tool PCWorx genutzt. PCWorx ist die durchgängige Engineering-Software für alle Steuerungen von Phoenix Contact. Sie vereint die Programmierung nach [https://de.m.wikipedia.org/wiki/EN_61131 IEC 61131] mit der Feldbuskonfiguration sowie der Anlagendiagnose. <br>
 
Weil es zu Projektbeginn einige Schwierigkeiten bei der Verbindungsherstellung zwischen PCWorx und der SPS gab, erfolgt hier ein Tipp: <br>
Wir empfehlen bei der Einarbeitung nicht das Dokument [https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Allgemein/Literatur/PHOENIX_CONTACT/Starterkit_AXC1050/Quickstart_PN.zwt PC_WORX_Quickstart.pdf] zu verwenden, da dieses sehr ausführlich ist und viele für das Projekt nicht benötigte Informationen beinhaltet. Stattdessen empfehlen wir die Einarbeitung mit dem Artikel [[Erstellen eines Projektes in PC Worx|Erstellen eines Projektes in PC Worx]]. Im Artikel wird ein schneller und verständlicher erster Einblick in die Arbeit mit der Software PCWorx gegeben.<br>
 
''Hilfestellung für Studenten die sich gar nicht mit einer SPS auskennen: <br>
''Erstellt zunächst ein Projekt in PCWorx und geht dort die alten Digitaltechnik-Aufgaben oder das Quickstart_Lauflicht bzw. Quickstart_Moving_Light ([https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Allgemein/Literatur/PHOENIX_CONTACT/PCWORX_Beispiele/Moving_Light/ SVN Link]) von Phoenix Contact durch, um ein Gefühl für PCWorx und die SPS zu entwickeln.''
''
 
==== Aufbau von PCWorx ====  
PCWorx ist in fünf Arbeitsbereiche (vgl. Abb.4<ref name="[Abb4]"> Abbildung 4: ''eigene Quelle'' </ref>)aufgeteilt:
 
[[Datei:Arbeitsbereiche PCWorx.JPG|325px|thumb|left|Abb.4: Arbeitsbereiche in PCWorx]]  <br>
 
 
 
 
 
 
 
 
 
''(Von links nach rechts) <br>
 
1.  Arbeitsbereich IEC-Programmierung, <br>
2.  Arbeitsbereich Buskonfiguration, <br>
3.  Arbeitsbereich Prozessdatenzuordnung, <br>
4.  Arbeitsbereich Projektvergleich und <br>
5.  Arbeitsbereich FDT (Field Device Tool). <br>'' <br>
Die drei wichtigen Arbeitsbereiche hierbei sind: <br>
* Die IEC-Programmierung zum Programmieren, Funktionen erstellen, etc. <br>
* Die Buskonfiguration für die Kommunikation mit der SPS und den angeschlossenen Modulen <br>
* Die Prozessdatenzuordnung für das Zuweisen der vorher definierten Variablen an die Steckplätze der Module <br>
 
==== HTerm ====
Mit der kostenfreien Software [https://de.m.wikipedia.org/wiki/HyperTerminal HTerm] wird eine serielle Kommunikation über die RS232-Schnittstelle ermöglicht. Die Software hilft beim Einrichten und Prüfen der Schnittstelle.
 
== Entwicklung ==
 
==== Hardwareaufbau ====
[[Datei:Pinbelegung für RS232.png|250px|thumb|right|Abb.5:Pinbelegung am Kommunikationsmodul]]


Während der Planungsphase wurde sich dafür entschieden, eine Grundplatte zu erstellen, auf welcher der Arduino befestigt wird. Zusätzlich soll auf dieser Grundplatte der Servomotor fixiert werden. Außerdem wurde beschlossen, die Grundplatte über das additive Fertigungsverfahren 3D-Druck zu fertigen. Hierzu ist die Grundplatte im 3D-CAD-Programm SolidWorks erstellt worden.<br>
Anschließend galt es, den Hardwareaufbau fertig zu stellen und das beschaffte Kommunikationsmodul in das Board zu integrieren und anzuschließen, um eine RS232-Kommunikation zu ermöglichen. Das Kommunikationsmodul und das zugehörige Bussockelmodul, mit welchem die interne Busverbindung aufgebaut wird, konnten mittels eines Push-In-Anschlusses in das Board integriert werden. Mit Hilfe der im Datenblatt vorgegebenen Pinbelegung (vgl. Abb.5<ref name="[Abb5]"> Abbildung 5: ''https://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=2688666&library=dede&tab=1 (Screenshot vom Datenblatt des Kommunikationsmoduls AXL F RS UNI 1H - 2688666 (S.4))'' </ref>)konnten die benötigten Datenleitungen zur RS232-Kommunikation (RxD, TxD, CTS, DTR, GND) in die jeweiligen Pins im Kommunikationsmodul platziert werden (Originaldatei: [[Datei:Pinbelegung am Kommunikationsmodul_Original.pptx]]). Mit einem Nullmodelkabel konnte dann der Anschluss an den PC hergestellt werden, sodass der Hardwareaufbau komplett war (vgl. Abb.6<ref name="[Abb6]"> Abbildung 6: ''eigene Quelle'' </ref>).
Vor Beginn der Konstruktion wurden zuerst die Maße des Arduinos und des Servomotors benötigt. Diese sind zum einen in den jeweiligen Datenblättern zu finden, sicherheitshalber wurden sie auch nochmal von Hand aus vermessen. Neben den Maßen der beiden Bauteile sind auch die Abstände der beiden zueinander sowie zum Grundplattenrand relevant. Zwischen den beiden Bauteilen wurde sich für einen Abstand von 2,5 cm entschieden, damit der Servomotor problemlos mit dem Arduino verbunden werden kann. Des Weiteren wurde der Abstand vom Arduino zum Grundplattenrand mit 5cm beziffert, damit der Arduino angeschlossen werden kann, ohne das Anschlusskabel zu sehr zu verdrehen und somit unnötig zu belasten. Der Abstand vom Servomotor zum Ende der Grundplatte wurde auf 0,5cm festgelegt, um den Servomotor problemlos verschrauben zu können.<br>
In SolidWorks wurde zuerst eine sogenannte Skizze erstellt, bei der schon alle Bemaßungen und Bohrungen enthalten sind. Bei der Größe der Bohrungen wurde sich beim Arduino am vorhandenen Datenblatt orientiert, beim Datenblatt des Servomotors war die Größe der Befestigungslöcher nicht bemaßt. Das Ausmessen gestaltete sich als schwierig, da es sich um sehr kleine Löcher handelt, diese wurden mit Durchmesser 2mm angenommen.<br>
Nachdem die Skizze vollständig definiert ist, kann man in SolidWorks unter „Features“ die Auswahl „Linear ausgetragener Aufsatz“ wählen, um aus der Skizze einen 3D-Körper zu erstellen. Als Aufsatz, also die Höhe der Grundplatte wurden 8mm gewählt, um bei der Fixierung von Servomotor und Arduino eine ausreichende Bohrungstiefe zu gewährleisten.
<br/>


[[Datei:Halterung_Ultraschallsensor.png|350px|thumb|right|Abb.4:Halterung für den Ultraschallsensor in CAD]]
{| class="wikitable"
<br/>
| [[Datei:Anordnung der Komponenten auf dem Board.png|650px|thumb|right|Abb.6:Anordnung der Komponenten auf dem Board]]
Neben der Grundplatte wurde auch die Halterung für den Ultraschallsensor mit SolidWorks konstruiert. An dieser soll der Ultraschallsensor angebracht werden und zusätzlich die Verbindung zum Arduino über eine Verschraubung hergestellt werden. Diese Konstruktion gestaltete sich etwas schwieriger als die der Grundplatte. Die Halterung sollte grob so gestaltet werden, dass sie aus drei Bereichen besteht. Im oberen Bereich soll der Ultraschallsensor angebracht werden, der mittlere Bereich gilt nur als Übergangsbereich und der untere Bereich soll die Verbindung an den Servomotor über eine Verschraubung darstellen.<br>
|}
Zuerst wurden wieder die Maße des Ultraschallsensors benötigt, welche im Datenblatt zu finden waren. Da der Ultraschallsensor im oberen Bereich der Halterung angebracht wird, entsprechen die Maße der Halterung im oberen Bereich in etwa denen des Ultraschallsensors. Um Material einzusparen wurde sich dazu entschieden, die Halterung im mittleren Bereich schmaler zu gestalten, da dieser nur als Übergang dient. Im unteren Bereich wird die Halterung um 90° gebogen, um den Servomotor daran verschrauben zu können. Der gebogene Bereich wird mit 10mm bemaßt, um genug Platz für die Bohrung und ein einfaches Verschrauben zu gewährleisten.<br>
Die Originaldatei findet sich in der gleichen Datei wie der technische Systementwurf: [[Datei:Technischer_Systementwurf_Phoenix_Original.pptx]]
Außerdem muss beachtet werden, dass die Pins des Ultraschallsensors zugänglich sind. Hierzu wird im Bereich der Pins eine 20x20mm Öffnung eingebracht. Des Weiteren müssen Bohrungslöcher eingefügt werden. Hierbei werden vier für die Befestigung des Sensors an den Ecken des oberen Bereichs vorgesehen und fünf im unteren Bereich, zur Verschraubung des Servomotors. Es werden unten fünf Löcher gewählt, um bei der Verschraubung flexibel zu sein und die passende Position wählen zu können. Alle Löcher werden mit 2mm bemessen. Dieser Wert wurde selbstständig ausgemessen, da in den Datenblättern keine Angaben dazu zu finden sind.<br>
Nach Fertigstellung der Skizze wird auch hier wie bei der Grundplatte ein linear ausgetragener Aufsatz gewählt, um einen 3D-Körper zu erstellen. Als Wandstärke werden hier nur 5mm gewählt, da keine großen Lasten getragen werden müssen.
Zum Schluss werden diese beiden CAD-Dateien in ein STL-Format übertragen und mit einem in der Hochschule vorhandenen 3D-Drucker gedruckt.


== Hardwareaufbau ==
<br>
[[Datei:Hardwareaufbau_Fritzing.png|500px|thumb|right|Abb.5:Hardwareaufbau als Fritzing Skizze]]
Nach der Fertigstellung des Aufbaus ist es zu einem internen Kommunikationsfehler (Busfail) innerhalb der SPS gekommen. Es bestand laut Fehlermeldung keine Kommunikationsverbindung der Module untereinander. Als erste Maßnahme wurde das komplette Board nochmals auseinandergebaut und die internen Verbindungen der Bussockelmodule überprüft. Nach dem erneuten Zusammenbau trat das Problem allerdings weiterhin auf. Als nächste Maßnahme wurde die SPS mittels des Reset-Buttons auf Werkseinstellungen zurückgesetzt. Somit konnte das Problem gelöst werden.
Der Hardwareaufbau der Sonarstation besteht aus dem Anschluss des Ultrasschallsensors und dem Anschluss des Servomotors. Der Servomotor benötigt drei Anschlüsse. Zwei Anschlüsse des Servomotors werden für die Versorgungsspannung, Vcc und Gnd benötigt. Der dritte Anschluss ist der analoge Anschluss des Servomotors um ihn an eine beliebige Position zu verfahren. Es ist wichtig, dass dieser Anschluss mit einem PWM-Pin (Pin 9) verbunden wird.<br>
Der Ultrasschallsensor hat vier Anschlüsse, von denen zwei für die Versorgungsspannung (Vcc und GND). Die anderen zwei Anschlüsse sind der Trigger-Pin und der Echo-Pin. Der Echo-Pin liefert das Messergebnis des Ultraschallsensors und muss deshalb als Input geschaltet werden (Pin 7). Der Trigger-Pin muss als Output geschaltet werden da über ihn die der Messprozess gestartet wird (Pin 6).


=== Prinziperklärung Ultraschallmessung ===
Zudem sollte wie bereits erwähnt eine Optokopplerschaltung entworfen und gebaut werden, um die Schrittmotortreiber ansteuern zu können. Die Planung hierzu erfolgte gemeinsam mit der Gruppe [[Ansteuerung einer Schrittmotor-Achse mit Siemens SIMATIC S7-300 SPS|Ansteuerung einer Schrittmotor-Achse mit Siemens SIMATIC S7-300 SPS]], da diese eine solche Schaltung ebenfalls benötigt. Der Aufbau und Test der Schaltung erfolgte durch die Siemens-Gruppe, da diese im Projekt bereits weiter fortgeschritten war. Ein Bild der Schaltung ist im [[Ansteuerung einer Schrittmotor-Achse mit Siemens SIMATIC S7-300 SPS|Artikel dieser Gruppe]] zu finden.
[[Datei:Messablauf.png|thumb|rechts|500px|Abb.6:Messablauf des HC-SC04 Abstandssensor]]
Das Messprinzip des Ultraschallsensormoduls ist ein Laufzeitverfahren. Der Ultraschallsensor strahlt zyklisch einen kurzen, hochfrequenten Schallimpuls aus. Diese Schallwellen pflanzen sich mit Schallgeschwindigkeit in der Luft fort. Wenn nun die Schallwelle auf ein Objekt, im Messfeld des Sensors trifft, wird diese reflektiert.  Die wieder beim Sensor eintreffende Schallwelle wird detektiert und die Zeit zwischen dem Aussenden und dem Wiedereintreffen gemessen. Aus der Zeit und der Schallgeschwindigkeit in einem bestimmten Medium (Luft) kann die Distanz zum detektierten Objekt errechnet werden. <br/>
<math>Strecke = v_{Luft} \cdot \dfrac {t_{mess}}{2}</math><br/>


=== Messablauf HC-SC04 Abstandssensor ===  
==== Programmablaufplan ====
Der Messzyklus des Ultraschallmoduls wird durch eine fallende Flanke am Trigger-Pin ausgelöst. Bevor die fallende flanke detektiert werden kann, muss am Trigger-Pin zuvor erst mindestens für  10 μs ein High-Pegel anliegen.
Bevor mit der Programmierung begonnen wurde, wurde ein Programmablaufplan (vgl. Abb.7<ref name="[Abb7]"> Abbildung 7: ''eigene Quelle'' </ref>) erstellt. Hier wurden erste Ideen zur Gestaltung und Ablauf des Programms zusammengefasst . <br>
Im Anschluss auf die detektierte fallende Flanke, sendet das Modul 8 aufeinander folgende Ultraschallsignale, mit einer Frequenz von 40 kHz aus (Burst-Siganle). Diese Phase dauert 200 μs.
Zunächst wird eine RS232-Verbindung  benötigt, um den benötigten G-Code zu erhalten. Danach soll der G-Code in Soll- und Istpostion unterschieden werden, um die Referenzen für den Verfahrweg der Fräse zu berechnen. Anschließend sollen diese weiter an die einzelnen Motortreiber der Achsen weitergeleitet werden.
Nachdem die Siganle ausgesendet wurden, wird der Echo-Pin sofort auf einen High-Pegel gesetzt und das Modul wartet auf die Rückkehr des Echos der Burst-Siganle. Wenn das Echo eintrifft, wird der Echo-Pin wieder auf einen Low-Pegel gesetzt.
Die Triggerung des Trigger-Pins kann alle 20 ms erfolgen.
Wenn kein Echo detektiert werden konnte, weil die Schallwelle zu großen teilen Absorbiert wurde, oder kein Hindernis in der nähe ist, so wartet das Modul 200 ms und zeigt die Erfolglose Messung somit an. Die Messung kann danach mit der fallenden Flanke am Trigger-Pin erneut gestartet werden.


=== Messgenauigkeit HC-SC04 Abstandssensor ===
{| class="wikitable"
| [[Datei:PhoenixContact Programmablaufplan.JPG|450px|thumb|right|Abb.7:Programmablaufplan]]
|}
[https://wiki.hshl.de/wiki/index.php/Datei:Programmablaufplan_PCWorx.JPG Orginaldatei in PAP]


Die Modulabhänige Messgenauigkeit, die mit 3 mm angegeben ist hängt mit der Abtastrate des Moduls zusammen. Des Weiteren ist bei Ultraschallmessverfahren die Temperatur der Umgebungsluft ein nicht unwesentlicher Faktor. Die Schallgeschwindigkeit in Luft bei 20 °C beträgt ''343,5 m/s''. Die Schallgeschwindigkeit lässt sich mit Hilfe der Formel:
==== Funktionsbausteine zur seriellen Datenübertragung ====
[[Datei:Funktionsbaustein RS-232.JPG|700px|thumb|right|Abb.8:Programm zur RS232-Kommunikation]]


<math>v_{Luft} = (331.5 + 0.6 \cdot T) \dfrac{m}{s}</math><br/> <br/>
Da beim Projekt eine Datenübertragung per RS-232 gewünscht wurde, musste zuerst rausgefunden werden, wie dies in PCWorx zu realisieren ist. Leider war hierzu nur sehr wenig Literatur vorhanden, glücklicherweise konnte Prof. Göbel im Laufe des Projekts ein Beispielprogramm von Phoenix Contact erhalten, welches nun auch in SVN zur Verfügung steht ([https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Allgemein/Literatur/PHOENIX_CONTACT/PCWORX_Beispiele/ PCWORX_Beispiell]). <br>
Näherungsweise bestimmen, für den Temperaturbereich -20 °C bis 40 °C. <br/>
Mit Hilfe dieses Programms konnte das in Abbildung 8 <ref name="[Abb8]"> Abbildung 8: ''eigene Quelle'' </ref> zu sehende Programm zur geplanten RS232-Kommunikation erstellt werden.
Es ist zu empfehlen, wenn größere Abstände genau ermittelt werden sollen, den HC-SR04 Ultraschallsensor mit einem Umgebungstemperatursensor zu koppeln und so die Schallgeschwindigkeit genauer bestimmen zu können.
<br>


=== Servomotor ===
Das Programm enthält jeweils einen Block zum Senden (RS232_SEND), Empfangen (RS232_RECEIVE) und zum Initiieren (RS232_INIT) der Daten (Infos zu den Blöcken sind über den Hilfe-Reiter in PCWorx zu finden). <br>
Für dieses Projekt wurde der Servomotor SM-S2309S gewählt, da er mit der kleinen Bauform und geringen Stromaufnahme optimal die Bedingungen erfüllt um direkt vom Arduino Uno angesteuert zu werden. Des Weiteren verfügt der Servomotor über einen analogen Eingang mit dem man ihn an eine bestimmte Position verfahren kann. Der Servomotor kann in einem Bereich von 0 - 180° in 1° Schritten bewegt werden. Die Umdrehungen des Servomotors wird über ein kleines integriertes Getriebe auf eine Narbe übertragen, an dieser Narbe wird für das Projekt die Ultraschallsensorhalterung angebracht.
Außerdem gibt es noch das Parameterungs-Einstellungsfeld (oben rechts), um die Daten in dem gewünschten Format zu senden, werden die Werte in der Bibliothek rs232-types [https://wiki.hshl.de/wiki/index.php/Datei:Rs232types.JPG rs232types] verändert. <br>


== Programmierung ==
'''Probleme:''' <br>
[[Datei:Programmablaufplan_Sonarstation.png|thumb|rechts|500px|Abb.7:Programmablaufplan der Sonarstation]]
Die Idee war, dem SEND- und RECEIVE-Block über den ONBOARD_INPUT_BIT0 (Schalter) ein HIGH zu geben, um die Daten zu initiieren und dann per HTerm eine Nachricht zu senden, welche auf dem gleichen Weg wieder empfangen wird. Dies funktionierte nicht. <br>
Die Umsetzung der Ansteuerung des Ultraschallsensors und des Servomotors sowie die Darstellung der Messergebnisse wird in zwei Teile unterteilt.<br>
Als nächste Idee wurde dann versucht, jeweils nur den RS232_SEND und den RS232_RECEIVE Block zu betrachten. Indem man den jeweiligen DATA_COUNT auf einen beliebigen digitalen Ausgang der SPS setzt,sollte kontrolliert werden, ob eine Nachricht auch wirklich versendet bzw. empfangen wird. Dies klappte nur bedingt. Bei dem SEND-Block wurde die Nachricht laut HTerm mit dem gewünschten Feedback gesendet und teilweise war dies auch auf der entsprechenden LED des Kommunikationsmoduls (03) zu sehen. Diese LED blinkt auf, sobald Daten gesendet werden. Beim RECEIVE-Block funktionierte dies nicht. <br>
1. Ansteuerung des Servomotors und Ultraschallsensor mit Arduino IDE<br>
2. Plot der Messergebnisse in Matlab <br>
Die Kommunikation zwischen den beiden Programmteilen findet über die serielle Schnittstelle des Arduinos statt.<br><br>


Für die Ansteuerung des Servos muss zunächst die Library "servo.h" eingebunden werden, um den Servo über die darin enthaltenen Funktionen ansteuern zu können. Danach muss ein Servo-Objekt erzeugt werden um im nachhinein den Servo über dieses Objekt anzusteuern. In der  Setupfunktion des Arduinoprogramms wird die Baudrate für die serielle Buskommunikation auf 9600 Bd gesetzt. Im Anschluss daran werden die Anschlüsse für den Ultraschallsesor (Trigger = Output, Echo = Input) gesetzt. Ebenso wird mit der Funktion DrehServo.attach(9) der Pin für den Anschluss des Servomotors festgelegt. Der Anschluss muss auf einen PWM-Pin gelegt werde, da die Kommunikation mit dem Servo analog erfolgt. <br>
= Zusammenfassung und Ausblick =
Die Loop Finktion verfügt über zwei for-Schleifen, die ein Positionsvariable zwischen 0 - 180 inkrementieren und im Anschluss daran dekrementieren. Diese Positionsvariable wird mit der Funktion DrehServo.write() an den Servomotr zu übergeben. Der Servomotor richtet sich so aus, bis er die angegebenen Position erreicht hat. Die Stellung des Servomotors wird mit der Funktion DrehServo.read() ermittelt und an die serielle Schnittstelle übergeben, sowie ein Tennzeichen (Delimiter "/") übertragen.<br> Der nächste Schritt ist die Erittlung der Distanzerkennung, mit Hilfe des Ultraschallsensors. Dafür wurde eine Funktion selbst erstellt GetUSRuntime(), welche die Laufzeit des Ultraschallsignals in Mikrosekunden zurück gibt. In der Funktion wird der Messablauf, wie oben beschrieben (Messablauf HC-SR04 Abstandssensor), angesteuert und die Signallaufzeit über die pulseIn(echo,HIGH) Funktion ermittelt. Wenn die steigende Flanke erkannt wird, wird die Laufzeit als Returnvariable zurück gegeben. Wie auch der Positionswikel wird auch die Siganllaufzeit an die serielle Schnittstelle übergeben, um von dem Matlab-Script ausgewertet werden zu können. Zum Ende der Loop Funktion wird ein Delay angestoßen, welches die Geschwindigkeit den Start des nächsten Loops verzögert um für den Ultraschallsensor den passenden Dutycycle zu gewährleisten.<br><br>


Der zweite Teil der Programmierung findet in Matlab 2018b statt. In diesem Programmteil geht es hauptsächlich um die Darstellung der vom Arduino übermittelten Daten. Zu Beginn des Programms werden Variablen deklariert, die für den weiteren Programmablauf benötigt werden, beispielsweise die maximale Reichweite, die dargestellt werden soll oder der verwendete COM-Port. Es wird draufhin überprüft, ob ein serielles Objekt angeschlossen ist, welches Daten übermittelt. Wenn dies der Fall ist, wird ein serielles Objekt erzeugt, welches alle wichtigen Einstellungen für die serielle Kommunikation enthält. Wichtig ist, dass die Baudrate auf die im Arduinoprogramm eingestellte Baudrate angepasst wird, in diesem Fall 9600 Bd, 8 Data-Bits, kein Parity-Bit und ein Stop-Bit. Nachdem alle Einstellungen getätigt wurden wird mit fopen() die serielle Kommunikation gestartet. <br>
Insgesamt lässt sich festhalten, dass das Projekt eine interessante und sehr herausfordernde Aufgabe war für uns war. Da das Projekt erstmals durchgeführt wurde, gab es keine Vorarbeiten vorheriger Jahrgänge, weshalb eine lange und intensive Einarbeitungsphase benötigt wurde, um die Phoenix Contact AXC 1050 SPS und ihre dazugehörigen notwendigen Module zu verstehen.<br>
Für die Darstellung der Messergebnisse wird eine Dauerschleife gestartet, in welcher zunächst der seriell übermittelte Datenstring in ein Variable geschrieben wird. Der Datenstring wird nun mit Hife eines Trennzeichens "/", welches im Arduinoprogramm zwischen den Winkelwert und den Laufzzeitwert eingesetzt wurde, in zwei Teile zerlegt. Diese beiden Teile befinden sich in einem Rohdaten-Array, indem an der ersten Stelle der Winkel und an der zweiten Stelle die entsprechende Laufzeit der Ultraschallmessung zu dem Winkel steht. Der Winkel wird an ein Winkel-Array übergeben, welches in jedem Schleifendurchlauf inkrementiert wird. Ebenfalls gibt es ein Distanz-Array, welches von der "ObjektEntfernung-Funktion" gefüllt wird.<br>
Diese Funktion bekommt eine Laufzeit, eine Umgebungstemperatur und einen maximal zulässigen  Abstand übergeben. Die Laufzeit wird in jedem Schleifenduchlauf aus dem Rohdaten-Array neu extrahiert. Die Umgebungstemperatur und der maximal zulässige Abstand sind konstanten, die für die Berechnung der Distanz vonnöten sind. In der Funktion wird zuerst die Schallgeschwindigkeit der Luft bei der angegebenen Temperatur berechnet, nach der Formel aus Abschnitt "Messungenauigkeiten HC-SR04 Abstandssensor" und im Anschluss daran findet die Distanzberechnung, nach der Formel aus Abschnitt "Prinziperklärung Ultraschallmessung" statt. Soll bei der Distanzmessung ein Distanzwert errechnet werden, der größer ist als der maximal zulässige Abstand wird der Distanzwert auf "NaN = Not a Number" gesetzt. Das resultiert im Plot später darin das kein Wert dargestellt wird. <br>
Wenn nun die Daten für Winkel und Distanz beide vorliegen, wird die Funktion RadarPlot aufgerufen. Die Funktion bekommt das Laufzeit- und Winkel-Array, maximalen Abstand und einige Parameter die für die Darstellung der Grafik benötigt werden übergeben. Um den aufgenommenen Bereich der darzustellen, wird ein Polarplot gewählt. Diese Plotfunktion von Matlab benötigt einen Winkel Theta im Bogenmaß und ein Rho, welches in diesem Fall der Ultraschallmessabstand ist. Danach werden noch Ploteinstellungen für die Darstellung getätigt. Zum Abschluss der Funktion wird der Befehl "drawnow" aufgerufen, der dafür zuständig ist den Plot zur Laufzeit darzustellen. <br>
Dadurch erhält man ein Matlab-Plot der zur Laufzeit die Werte die vom Arduino übermittelt werden darstellt.


== Ergebnis ==
Die größte Herausforderung stellte für uns der Kommunikationsaufbau über RS232 dar, hier konnte wie beschrieben keine fehlerfreie Kommunikation aufgebaut werden. Die Aufgabenstellung des Projekts konnte somit nicht vollständig erfüllt werden, nachfolgende Gruppen finden allerdings einen fertigen Hardwareaufbau sowie eine angefangene Programmierung und einen Programmablaufplan vor.<br>
Das Ergebnis des Projekts ist eine funktionsfähige Sonarstation. Der Ultraschallsensor kann durch den Servomotor um 180° gedreht werden und erkennt zuverlässig die Objekte in der Umgebung. Diese Objekte sind auch im erstellten MATLAB-Plot erkennbar. Der berechnete und zusätzlich im Plot dargestellte Abstand zwischen den Objekten und der Sonarstation konnte durch mehrere Messungen verifiziert werden. Bei großen Abständen, die die Reichweite des Ultraschallsensors ausreizen, sind die Ergebnisse allerdings bauteilbedingt teilweise fehlerbehaftet. Deshalb wurde sich im Projekt eher auf kleine Distanzen von unter einem Meter konzentriert, in diesem Messbereich arbeitet die Sonarstation zuverlässig.
Erweiterungsmöglichkeiten wären die Verwendung eines höher auflösenden Ultraschallsensor oder die Verwendung eines anderen Messsystems (LiDAR) für zuverlässigere Messwerte bei größeren Abständen. Außerdem gäbe es die Option, den Ultraschallsensor mit einem Temperatursensor zu koppeln, um die Umgebungstemperatur zu erfassen. Dies kann für die temperaturabhänige Schallgeschwindigkeitberechnung genutzt werden, um akkuratere Distanzberechnungen durchführen zu können. Diese Option bietet die Matlab-Funktion für die Distanzberechnung bereits an. Die Umsetztung war allerdings nicht Teil der Anforderungen und daher in dem begrenzten Zeitrahmen des Projektes nicht mehr möglich zu implementieren.


== Zusammenfassung ==
Das Projekt kann von nachfolgenden Gruppen insofern fortgeführt werden, dass eine funktionsfähige RS232 Kommunikation aufgebaut wird, sodass Strings fehlerfrei eingelesen und verarbeitet werden können. Zudem steht noch die Berechnung der Verfahrwege sowie das entsprechende Schalten der Ausgänge und die abschließenden Tests aus.<br>
Insgesamt lässt sich festhalten, dass ein sehr zufriedenstellendes Ergebnis erreicht wurde, welches auf der Messe präsentiert werden kann. Im Verlauf des Projekts waren die im Studium erlernten Projektmanagementkenntnisse sehr hilfreich und durch den aufgestellten Projektplan konnte immer erkannt werden, was bis zu einem festgelegten Datum noch zu tun ist. Auch wenn der Projektplan durch einige Verzögerungen nicht immer vollständig eingehalten werden konnte, war die Planung vorab ein wichtiger Grundstein des erfolgreichen Projekts.
Außerdem konnten im Projekt durch die Planung und Konstruktion der Bauteile, den Hardwareaufbau und die Programmierung die Kenntnisse in diesen Bereichen ausgebaut werden und ein eigenes, funktionsfähiges Projekt erstellt werden, das alle Facetten des Studiengangs Mechatronik abdeckt.
== Lessons Learned ==
Während des Projekts konnte die Erkenntnis gewonnen werden, dass während der Projektplanung immer Verzögerungen einkalkuliert werden sollten. Bei der Planung des Projekts wurde nicht berücksichtigt, dass Bauteile erst spät eintreffen könnten. Dadurch, dass die benötigten Teile erst Mitte Dezember ankamen, haben sich der Bau der Station sowie die ersten Tests verzögert. Somit musste der geplante Ablauf des Projekts ein wenig umstrukturiert werden, was aufgrund des noch vorhandenen Zeitfensters von fünf Wochen allerdings noch ein lösbares Problem war. Trotzdem konnte daraus gelernt werden, in der Zukunft solche Verzögerungen einzurechnen und sich möglicherweise einen „Plan B“ aufzustellen.<br/>
Außerdem kann aus dem Projekt mitgenommen werden, dass sich vorher ausgiebig über Verfahren informiert werden sollte, die während des Projekts benutzt werden. So wurde im Projekt das 3D-Druck Verfahren angewendet, über welches nur wenige Vorkenntnisse vorhanden waren. Dadurch kam es zu Schwierigkeiten, da die Genauigkeit des 3D-Druckers falsch eingeschätzt wurde, weshalb viele Konstruktionslöcher zu klein waren und nachbearbeitet werden mussten.<br>
Außerdem wurde in dem Projekt festgestellt, dass für eine Kommunikation mit dem Arduino über einen COM-Port dieser im Vorhinein freigegeben werden muss. Dies führte bei der Programmierung zu erheblichen Problem, bei denen die Fehlerursache darin lag, dass der selbe COM-Port von der Arduino IDE und dem Matlab-Script verwendet wurde. Dieses Problem ließ sich durch explizietes Freigeben des COM-Ports nach dem Aufspielen des Arduinoprogramms lösen.<br>
Bei der ersten Umsetzung der Anforderungen wurde, der Aufgabenstellung entsprechend, versucht die Ansteuerung von Sensor und Motor in MATLAB Simulink umzusetzen. Die Implementierung in Simulink führte aber zu keinem zufriedenstellenden Ergebnis. Da es in der Arduino IDE für den Servomotor bereits vorgefertigte Bibliotheken gibt, wurde sich für eine Umsetztung mit dieser Software entschieden. Hier wäre im Vorfeld eine ausgiebigere Einarbeitungsphase nötig gewesen, welche durch das verspätete Eintreffen der Bauteile nicht mehr umsetzbar war.


== Projektunterlagen ==
Trotz des nicht fertigen Arbeitsergebnisses konnten einige Lernerfolge verbucht werden. Insbesondere sind hierbei die Erfahrungen im Umgang mit einer SPS zu nennen, welche vorher nicht vorhanden waren. Zudem konnte die Arbeit mit dem V-Modell erlernt werden und es wurde der Umgang mit SVN aufgefrischt und verbessert.


Direktlink zum SVN-Ordner: [https://svn.hshl.de/svn/Elektrotechnik_Fachpraktikum/trunk/Projekte/89_Sonarstation/ Projekt 89: Sonarstation]
= Weblinks und Literatur =
*zip-Ordner mit nützlichen Dateien: [[Medium:Phoenix_zip-Ordner.zip]]
*zip-Ordner mit Programmen: [[Medium:Phoenix_Beispielprogramme.zip]]


== YouTube Video ==
===== SVN Links =====
YouTube Video des Projektes --> https://www.youtube.com/watch?v=He7enaojmcg
*[https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Allgemein/Literatur/PHOENIX_CONTACT/ PhoenixContact Literatur]
*[https://svn.hshl.de/svn/MTR_GPE_Praktikum/trunk/Fachthemen/3D_Bearbeitungsmaschine/Automatisierung_SPS_phoenix/ Link zum Gruppenordner]
===== HSHL-Wiki =====
*[[3D-CNC-Bearbeitungsmaschine|3D-CNC-Bearbeitungsmaschine]] <br>
*[[Speicherprogrammierbare Steuerungen (SPS)|SPS]] <br>
*[[Phoenix Contact AXC Trainer 1050 PN|Phoenix Contact AXC 1050]] <br>
*[[Zentraler Steuerungsalgorithmus für ein 3-Achs-CNC-Bearbeitungszentrum|Zentraler Steuerungsalgorithmus für ein 3-Achs-CNC-Bearbeitungszentrum]] <br>
*[[Broadcast mit RS232|Broadcast mit RS232]] <br>
*[[Erstellen eines Projektes in PC Worx|Erstellen eines Projektes in PC Worx]] <br>


== Quellenverzeichnis ==
=Quellen=
https://www.mikrocontroller.net/attachment/218122/HC-SR04_ultraschallmodul_beschreibung_3.pdf <br>
http://www.pcserviceselectronics.co.uk/arduino/Ultrasonic/electronics.php <br>
http://www.pcserviceselectronics.co.uk/arduino/Ultrasonic/HC-SR04-cct.pdf <br>


<references />
<br/>





Aktuelle Version vom 6. Februar 2020, 11:22 Uhr

Abb.1:Phoenix Contact AXC 1050 mit dem Kommunikationsmodul

Autoren: Niklas Rohlfs; Connor Royle

→ zurück zur Übersicht: 3-D-Bearbeitungsmaschine (Projekt des Schwerpunkts GPE im Studiengang MTR)

Einleitung

Im Studiengang Mechatronik der Hochschule Hamm-Lippstadt findet im 7. Semester im Studienschwerpunkt „Global Production Engineering“ das Modul „Global Production Engineering III“ statt. Einen Teil dieses Moduls bildet das Praktikum Produktionstechnik. Im Praktikum sollen die Achsen einer 3D-CNC-Bearbeitungsmaschine mit unterschiedlichen Automationshardwares angesteuert werden. Der folgende Artikel beschäftigt sich mit der Ansteuerung der Achsen mittels einer SPS von Phoenix Contact, nämlich der Phoenix Contact AXC 1050 (vgl. Abb.1[1]). Das Thema wurde im Wintersemester 2019/2020 erstmalig von Niklas Rohlfs und Connor Royle bearbeitet.

Aufgabenstellung

Die Aufgabe des Projektes war es, die Achsen der 3D-CNC-Bearbeitungsmaschine mit der Phoenix Contact AXC 1050 anzusteuern. Hierzu sollten von einer anderen Gruppe Koordinaten durch einen zentralen Steuerungsalgorithmus in Matlab als String per RS232 an die AXC 1050 gesendet werden. Die Verarbeitung der Koordinaten mitsamt der Berechnung der Verfahrwege sollte dann durch die AXC 1050 geschehen, welche dann zudem die entsprechenden Ausgangssignale an die Schrittmotortreiber der 3D-CNC-Bearbeitungsmaschine weitergeben sollte. Die Aufgabenstellung gliederte sich in diverse Teilaufgaben:

  • Allgemeines
    • Einarbeitung in das Projekt (Datenblätter lesen etc.)
    • Umsetzbarkeit mit vorhandenem Material prüfen
    • Benötigte Materialien bestellen
    • Bearbeitung der Aufgaben nach dem V-Modell
  • Aufbau
    • Hardwareaufbau mit Kommunikationsmodul erstellen
    • Aufbau der Optokopplerschaltung zur Umwandlung von 24V auf 5V
    • Beschriften aller Kabel
  • Datenübertragung
    • RS232-Datenübertragung herstellen
    • Strings über RS232 empfangen und einlesen
  • Programmierung
    • Einlesen der Koordinaten aus dem empfangenen String
    • String zerlegen (Trennung von Soll- und Ist-Position sowie Vorschub)
    • Berechnung der Schritt- und Richtungswerte aus der Differenz von Ist zu Soll
    • Schalten der digitalen Ausgänge
    • Diagonalfahrten ermöglichen (x und y sollen auch bei unterschiedlicher Fahrstrecke gleichzeitig ankommen)
  • Dokumentation
    • Dokumentation des eigenen Projektfortschritts in SVN (Anforderungsliste, Funktionaler Systementwurf, etc.)
    • HSHL-Wiki-Eintrag erstellen

Versuchsdurchführung

Das Vorgehen des Projekts hat sich am V-Modellorientiert. Dementsprechend sollten, nachdem die Anforderungen und Teilaufgaben definiert wurden, Systementwürfe erstellt werden. Erst dann folgte die Entwicklungsphase und nach dieser sollten Tests der Komponenten und des Systems anstehen. Mit dieser Vorgehensweise wird verhindert, dass zu Beginn bereits voreilig entwickelt wird, weshalb viele vermeidbare Fehler gar nicht erst enstehen.

Funktionaler Systementwurf

Beim funktionalen Systementwurf (vgl. Abb.2[2])soll das Gesamtsystem lösungs- und hardwareneutral dargestellt werden. Somit erhält man eine gute erste Übersicht über die Zusammenhänge der einzelnen Komponenten im Gesamtsystem. In diesem Fall wird ein erstelltes CAD-Modell in eine CAM-Software geladen, welche G-Code Befehle erzeugt. Mit dem jeweiligen Steuerungsprogramm, in diesem Fall der Phoenix Contact SPS, werden die übergebenen Strings dann eingelesen und geben die notwendigen Informationen über die zu tätigen Verfahrwege und Geschwindigkeiten dann an die Schrittmotortreiber weiter, welche die Schrittmotoren der jeweiligen Achsen ansteuern.

Abb. 2: Funktionaler Systementwurf

Originaldatei: Datei:Funktionaler Systementwurf Phoenix Original.pptx

Technischer Systementwurf

Nach dem funktionalen Systementwurf wird zudem ein technischer Systementwurf (vgl. Abb.3[3]) erstellt. Bei diesem werden die Schnittstellen zwischen den Systemen konkretisiert.

Abb. 3: Technischer Systementwurf

Originaldatei: Datei:Technischer Systementwurf Phoenix Original.pptx

Einarbeitung in Hard- und Software

Um den funktionalen und technischen Systementwurf erstellen zu können und die Entwicklung zu starten, war es zu Beginn des Projekts wichtig, sich mit der verwendeten Hardware und Software vertraut zu machen. Die Einarbeitung erfolgte hierbei zu einem großen Teil über die vorhandenen Datenblätter und Beispielprogramme in SVN, in denen Informationen über die SPS und deren Module sowie über PCWorx zu finden waren. Die wichtigsten Dokumente sind in folgendem SVN-Ordner zu finden:

Hardware

Im Produktionstechnik-Labor war zu Beginn des Praktikums bereits eine funktionsfähige SPS-Station vorhanden. Eine genauere Beschreibung der Station zeigt der Artikel Phoenix Contact AXC Trainer 1050 PN. Dort finden sich zudem die Datenblätter der Steuerung sowie des Digitaleingabe- und Digitalausgabemoduls.
Mit dem vorhandenen Aufbau konnte das Projekt allerdings nicht vollständig realisiert werden, sondern es mussten noch einige wenige Teile zusätzlich beschafft werden. Hierbei handelte es sich zum einen um ein Kommunikationsmodul der Firma Phoenix Contact. Dieses Modul soll die Kommunikation über RS232 mit anderen Geräten ermöglichen. Zum anderen handelte es sich um Optokoppler, mit denen eine Optokopplerschaltung gebaut werden kann. Diese Schaltung wird benötigt, um die Schrittmotorentreiber anzusteuern. Sie dient dazu, die Ausgangssignale richtig zu dimensionieren, da die Ausgänge der SPS 24V betragen, die Schrittmotortreiber jedoch mit einer Spannung von 3,3V-5V arbeiten.
Nähere Informationen zum Kommunikationsmodul und den Optokopplern lassen sich in den folgenden Datenblättern finden:

Software

Zur Programmierung der AXC 1050 wird das Software-Tool PCWorx genutzt. PCWorx ist die durchgängige Engineering-Software für alle Steuerungen von Phoenix Contact. Sie vereint die Programmierung nach IEC 61131 mit der Feldbuskonfiguration sowie der Anlagendiagnose.

Weil es zu Projektbeginn einige Schwierigkeiten bei der Verbindungsherstellung zwischen PCWorx und der SPS gab, erfolgt hier ein Tipp:
Wir empfehlen bei der Einarbeitung nicht das Dokument PC_WORX_Quickstart.pdf zu verwenden, da dieses sehr ausführlich ist und viele für das Projekt nicht benötigte Informationen beinhaltet. Stattdessen empfehlen wir die Einarbeitung mit dem Artikel Erstellen eines Projektes in PC Worx. Im Artikel wird ein schneller und verständlicher erster Einblick in die Arbeit mit der Software PCWorx gegeben.

Hilfestellung für Studenten die sich gar nicht mit einer SPS auskennen:
Erstellt zunächst ein Projekt in PCWorx und geht dort die alten Digitaltechnik-Aufgaben oder das Quickstart_Lauflicht bzw. Quickstart_Moving_Light (SVN Link) von Phoenix Contact durch, um ein Gefühl für PCWorx und die SPS zu entwickeln.

Aufbau von PCWorx

PCWorx ist in fünf Arbeitsbereiche (vgl. Abb.4[4])aufgeteilt:

Abb.4: Arbeitsbereiche in PCWorx






(Von links nach rechts)

1. Arbeitsbereich IEC-Programmierung,
2. Arbeitsbereich Buskonfiguration,
3. Arbeitsbereich Prozessdatenzuordnung,
4. Arbeitsbereich Projektvergleich und
5. Arbeitsbereich FDT (Field Device Tool).

Die drei wichtigen Arbeitsbereiche hierbei sind:

  • Die IEC-Programmierung zum Programmieren, Funktionen erstellen, etc.
  • Die Buskonfiguration für die Kommunikation mit der SPS und den angeschlossenen Modulen
  • Die Prozessdatenzuordnung für das Zuweisen der vorher definierten Variablen an die Steckplätze der Module

HTerm

Mit der kostenfreien Software HTerm wird eine serielle Kommunikation über die RS232-Schnittstelle ermöglicht. Die Software hilft beim Einrichten und Prüfen der Schnittstelle.

Entwicklung

Hardwareaufbau

Abb.5:Pinbelegung am Kommunikationsmodul

Anschließend galt es, den Hardwareaufbau fertig zu stellen und das beschaffte Kommunikationsmodul in das Board zu integrieren und anzuschließen, um eine RS232-Kommunikation zu ermöglichen. Das Kommunikationsmodul und das zugehörige Bussockelmodul, mit welchem die interne Busverbindung aufgebaut wird, konnten mittels eines Push-In-Anschlusses in das Board integriert werden. Mit Hilfe der im Datenblatt vorgegebenen Pinbelegung (vgl. Abb.5[5])konnten die benötigten Datenleitungen zur RS232-Kommunikation (RxD, TxD, CTS, DTR, GND) in die jeweiligen Pins im Kommunikationsmodul platziert werden (Originaldatei: Datei:Pinbelegung am Kommunikationsmodul Original.pptx). Mit einem Nullmodelkabel konnte dann der Anschluss an den PC hergestellt werden, sodass der Hardwareaufbau komplett war (vgl. Abb.6[6]).

Abb.6:Anordnung der Komponenten auf dem Board

Die Originaldatei findet sich in der gleichen Datei wie der technische Systementwurf: Datei:Technischer Systementwurf Phoenix Original.pptx


Nach der Fertigstellung des Aufbaus ist es zu einem internen Kommunikationsfehler (Busfail) innerhalb der SPS gekommen. Es bestand laut Fehlermeldung keine Kommunikationsverbindung der Module untereinander. Als erste Maßnahme wurde das komplette Board nochmals auseinandergebaut und die internen Verbindungen der Bussockelmodule überprüft. Nach dem erneuten Zusammenbau trat das Problem allerdings weiterhin auf. Als nächste Maßnahme wurde die SPS mittels des Reset-Buttons auf Werkseinstellungen zurückgesetzt. Somit konnte das Problem gelöst werden.

Zudem sollte wie bereits erwähnt eine Optokopplerschaltung entworfen und gebaut werden, um die Schrittmotortreiber ansteuern zu können. Die Planung hierzu erfolgte gemeinsam mit der Gruppe Ansteuerung einer Schrittmotor-Achse mit Siemens SIMATIC S7-300 SPS, da diese eine solche Schaltung ebenfalls benötigt. Der Aufbau und Test der Schaltung erfolgte durch die Siemens-Gruppe, da diese im Projekt bereits weiter fortgeschritten war. Ein Bild der Schaltung ist im Artikel dieser Gruppe zu finden.

Programmablaufplan

Bevor mit der Programmierung begonnen wurde, wurde ein Programmablaufplan (vgl. Abb.7[7]) erstellt. Hier wurden erste Ideen zur Gestaltung und Ablauf des Programms zusammengefasst .
Zunächst wird eine RS232-Verbindung benötigt, um den benötigten G-Code zu erhalten. Danach soll der G-Code in Soll- und Istpostion unterschieden werden, um die Referenzen für den Verfahrweg der Fräse zu berechnen. Anschließend sollen diese weiter an die einzelnen Motortreiber der Achsen weitergeleitet werden.

Abb.7:Programmablaufplan

Orginaldatei in PAP

Funktionsbausteine zur seriellen Datenübertragung

Abb.8:Programm zur RS232-Kommunikation

Da beim Projekt eine Datenübertragung per RS-232 gewünscht wurde, musste zuerst rausgefunden werden, wie dies in PCWorx zu realisieren ist. Leider war hierzu nur sehr wenig Literatur vorhanden, glücklicherweise konnte Prof. Göbel im Laufe des Projekts ein Beispielprogramm von Phoenix Contact erhalten, welches nun auch in SVN zur Verfügung steht (PCWORX_Beispiell).
Mit Hilfe dieses Programms konnte das in Abbildung 8 [8] zu sehende Programm zur geplanten RS232-Kommunikation erstellt werden.

Das Programm enthält jeweils einen Block zum Senden (RS232_SEND), Empfangen (RS232_RECEIVE) und zum Initiieren (RS232_INIT) der Daten (Infos zu den Blöcken sind über den Hilfe-Reiter in PCWorx zu finden).
Außerdem gibt es noch das Parameterungs-Einstellungsfeld (oben rechts), um die Daten in dem gewünschten Format zu senden, werden die Werte in der Bibliothek rs232-types rs232types verändert.

Probleme:
Die Idee war, dem SEND- und RECEIVE-Block über den ONBOARD_INPUT_BIT0 (Schalter) ein HIGH zu geben, um die Daten zu initiieren und dann per HTerm eine Nachricht zu senden, welche auf dem gleichen Weg wieder empfangen wird. Dies funktionierte nicht.
Als nächste Idee wurde dann versucht, jeweils nur den RS232_SEND und den RS232_RECEIVE Block zu betrachten. Indem man den jeweiligen DATA_COUNT auf einen beliebigen digitalen Ausgang der SPS setzt,sollte kontrolliert werden, ob eine Nachricht auch wirklich versendet bzw. empfangen wird. Dies klappte nur bedingt. Bei dem SEND-Block wurde die Nachricht laut HTerm mit dem gewünschten Feedback gesendet und teilweise war dies auch auf der entsprechenden LED des Kommunikationsmoduls (03) zu sehen. Diese LED blinkt auf, sobald Daten gesendet werden. Beim RECEIVE-Block funktionierte dies nicht.

Zusammenfassung und Ausblick

Insgesamt lässt sich festhalten, dass das Projekt eine interessante und sehr herausfordernde Aufgabe war für uns war. Da das Projekt erstmals durchgeführt wurde, gab es keine Vorarbeiten vorheriger Jahrgänge, weshalb eine lange und intensive Einarbeitungsphase benötigt wurde, um die Phoenix Contact AXC 1050 SPS und ihre dazugehörigen notwendigen Module zu verstehen.

Die größte Herausforderung stellte für uns der Kommunikationsaufbau über RS232 dar, hier konnte wie beschrieben keine fehlerfreie Kommunikation aufgebaut werden. Die Aufgabenstellung des Projekts konnte somit nicht vollständig erfüllt werden, nachfolgende Gruppen finden allerdings einen fertigen Hardwareaufbau sowie eine angefangene Programmierung und einen Programmablaufplan vor.

Das Projekt kann von nachfolgenden Gruppen insofern fortgeführt werden, dass eine funktionsfähige RS232 Kommunikation aufgebaut wird, sodass Strings fehlerfrei eingelesen und verarbeitet werden können. Zudem steht noch die Berechnung der Verfahrwege sowie das entsprechende Schalten der Ausgänge und die abschließenden Tests aus.

Trotz des nicht fertigen Arbeitsergebnisses konnten einige Lernerfolge verbucht werden. Insbesondere sind hierbei die Erfahrungen im Umgang mit einer SPS zu nennen, welche vorher nicht vorhanden waren. Zudem konnte die Arbeit mit dem V-Modell erlernt werden und es wurde der Umgang mit SVN aufgefrischt und verbessert.

Weblinks und Literatur

SVN Links
HSHL-Wiki

Quellen

  1. Abbildung 1: eigene Quelle
  2. Abbildung 2: eigene Quelle
  3. Abbildung 3: eigene Quelle
  4. Abbildung 4: eigene Quelle
  5. Abbildung 5: https://www.phoenixcontact.com/online/portal/de?uri=pxc-oc-itemdetail:pid=2688666&library=dede&tab=1 (Screenshot vom Datenblatt des Kommunikationsmoduls AXL F RS UNI 1H - 2688666 (S.4))
  6. Abbildung 6: eigene Quelle
  7. Abbildung 7: eigene Quelle
  8. Abbildung 8: eigene Quelle




→ zurück zur Übersicht: 3-D-Bearbeitungsmaschine (Projekt des Schwerpunkts GPE im Studiengang MTR)