Fernsteuerung einer Hubarbeitsbühnemn-webdesign.com/.../FINAL/Dokumentation_Projektarbe… ·...

zu

Diese Projektarbeit behandelt die Implementierung einer Bedieneinheit, welche die drahtlose Steuerung einer Hubarbeitsbühne der Firma Palfinger Platforms GmbH ermöglichen soll.

FERNSTEUERUNG EINER HUBARBEITSBÜHNE

REALISIERT MIT CAN-BUS

1

Das Team

FERNSTEUERUNG EINER HUBARBEITSBÜHNEREALISIERT MIT CAN-BUS

Inhaltsangabe:

1 Einleitung

2 Das Projekta. Aufgabenbeschreibungb. Planungc. Lösungsansätze/Durchführung

3 Informationen zua. Hardwareb. Softwarec. Funksteuerung

4 Layout/Anzeigemodul

5 Anhängea. Planung (Zeitplan, Stückliste, etc.)b. Pflichtenheft/Lastenheftc. Änderungsverzeichnisd. Hersteller Dokumentationene. Schaltplan/Klemmenplanf. Softwareausdrücke

6 Fazit

7 Eidesstattliche Erklärung

Versionsstand Datum Verfasser Letzte Änderung Projektarbeit1.3 16.04.2012 M.Neitzel/T.Wolfers 02.07.2012 Fernsteuerung einer Hubarbeitsbühne

M.NeitzelMechatroniker0176/32314000

[email protected]

T.WolfersElektriker

0174/[email protected]

AUFTRAGGEBER

Palfinger Platforms GmbHD-47809 Krefeld

Düsseldorferstr. 100

mailto:[email protected]

mailto:[email protected]

2

8 Informationsquellen

1. EINLEITUNG

Mit der vorliegenden Dokumentation sollen die technischen Grundlagen des Projekts Fernsteuerung einer Hubarbeitsbühne realisiert mit CAN-Bus vermittelt und Aufschluss darüber gegeben werden, wie das Projekt geplant und umgesetzt wurde, welche Probleme aufgetreten sind und wie Lösungsansätze erarbeitet wurden. Ebenso werden die eingesetzten Hardwarekomponenten beschrieben und ein Einblick in die Programmierung der Module gewährt.

Die Projektarbeit hat es ermöglicht, bereits vorhandenes Wissen im Bereich der Automatisierungstechnik – speziell mit dem in immer mehr Fahrzeugen eingesetzten CAN-Bus

1 – zu erweitern und gezielt einzusetzen. Diese Projektarbeit dient jedoch nicht nur der Erweiterung des eigenen Wissenshorizonts, sondern leistet einen großen Beitrag zur Sicherung der Kundenzufriedenheit. Auch schon vor Beginn der Ausbildung zum staatlich geprüften Techniker hat sich im Berufsalltag für die Beteiligten der im Projekt eingesetzte CAN-Bus im Bereich Elektrotechnik mit Schwerpunkt Automatisierungstechnik bewährt. Entsprechend bot es sich an, ein passendes und geeignetes Projekt zu suchen.

Die Möglichkeit, eine der Hubarbeitsbühnen aus dem Arbeitsalltag mit einer Funksteuerung auszustatten, war der perfekte Grundstein für die Idee dieser Projektarbeit. Dort sind verschiedene Aufgabenstellungen zu bewältigen, die nicht nur bisher im Verlaufe der Ausbildung behandelte Inhalte ansprechen, sondern auch komplett neue Herausforderungen schaffen. Das Ziel war, eine Steuerung zu entwickeln, die problemlos in verschiedenen HAB-Typen2 eingesetzt werden kann, störungsfrei arbeitet und natürlich Mensch und Maschine sicher drahtlos bewegen kann.

An dieser Stelle gilt der Palfinger Platforms GmbH besonderer Dank für die Bereitstellung der benötigten Ressourcen, Materialien sowie Räumlichkeiten, insbesondere den Herren der Steuerungstechnik - Herr Marks und Herr Jöhren - für die bereitgestellte Unterstützung.

Die Palfinger Platforms GmbH ist ein Unternehmen, das seit Jahrzehnten im Bereich der Hubarbeitsbühnen tätig ist – früher noch unter dem Namen WUMAG elevant und seit 2009 unter

1 CAN – Controller Area Network, siehe Seite 62 HAB – Hubarbeitsbühne


3

dem Dach des Palfinger Konzerns aus Österreich. Die Arbeitshöhen der Bühnen reichen von 11 bis 103 Meter und werden an den Standorten Krefeld und Oberlausitz entwickelt und hergestellt.

2. DAS PROJEKT

2.a AufgabenbeschreibungEin Kunde der Palfinger Platforms GmbH (kurz: PP) möchte in Zukunft sein Ausstellungsgebäude, bestehend aus einer Glaskonstruktion, warten und reinigen. Dafür wird eine Hubarbeitsbühne der PP benötigt, welche über eine drahtlose Bedieneinheit bewegt und gesteuert werden soll. Bisher werden diese Bühnen von zwei Steuerständen aus bedient: einer Zweitsteuerung an der Basis der HAB und direkt vom Korb aus über ein Steuerpult. Der Kunde möchte bei der Reinigung speziell des Daches den Korb der Bühne verlassen und die HAB parallel mitführen können.

Die Hubarbeitsbühnen der Firma PP sind derzeit mit zwei (optional drei) Bedienständen ausgestattet. Der Hauptbedienstand befindet sich am Ende der Hubmechanik, dem sogenannten Korb. Von dort aus wird die HAB in den meisten Fällen gesteuert. Das Bedienpult ist eine von der Firma MOBA angefertigte Baugruppe und wird ebenfalls über den vorhandenen CAN-Bus angesteuert. Möchte man die HAB außerhalb des Korbes bedienen, so kann man dies vom sogenannten Zweitbedienstand, auch Zweitsteuerung genannt, durchführen. Je nach Kundenwunsch gibt es einen zusätzlichen dritten Bedienstand, welcher am Drehturm der HAB über ein Podest erreichbar ist.

Neben der Realisierung des technischen Aspektes der Fernsteuerung stehen an erster Stelle natürlich der Personenschutz und die Kollisionsvermeidung der HAB bei personenlosem Betrieb. Um die Sicherheit für Mensch und Maschine zu gewährleisten, werden z.B. folgende Sicherheitsmittel verwendet: eine Totmannschaltung, Not-Aus-Schalter und ein Fußtaster im Korb. Die Implementierung der drahtlosen Bedienung erfolgt mittels CoDeSys 3, das Palfinger für die Programmierung der CAN-Bus Module verwendet.

Aufgrund der Tatsache, dass mit den HAB der Firma Palfinger Platforms Menschen transportiert werden, muss auch mit Hilfe von Software für die Sicherheit von Mensch und Maschine gesorgt werden, deshalb arbeitet der CAN-Bus funktionell-redundant (CAN-A und CAN-B). Dies betrifft die LMB4-kritischen Werte, wie z.B. Drehtischwinkel, Hubarmwinkel, Fahrzeugneigung, Stützenwerte. Unterteilt wird der Bus in folgende Abschnitte:

- Basis- DT (Drehtisch)- KA (Korbarm)- Korb

3 CoDeSys – Software zur Programmierung von Mikrokontrollern, siehe Seite 20 - 3.b4 LMB = Last-Moment-Begrenzung


4

Die CAN-Bus Teilnehmer sind in IDs aufgeteilt, wobei die ID-Nummer die 50 nicht überschreiten darf, da diese IDs für die interne Kommunikation reserviert sind. Hier eine Übersicht über die bisher eingesetzten Module im CAN-Bus A und B mit jeweiliger ID:


5

2.b PlanungUm während der Projektphase nicht den Überblick zu verlieren und um Aufgaben sinnvoll und terminiert einteilen zu können, wurde ein Projektplan erstellt. In diesem Plan wurde genau festgehalten, welche Aufgaben zu erfüllen sind, wann diese fertiggestellt werden sollten und darüber hinaus auch ihr Fortschritt. So konnten von Anfang Überschneidungen oder Unstimmigkeiten ausgeschlossen werden. Ebenfalls wurden Meilensteine gesetzt, welche bei Erreichen die Motivation innerhalb des Teams steigerten.

Zu den wichtigsten Aufgaben zählten:

- Materialplanung- Pflichten-/Lastenheft erstellen- Auswahl des Lieferanten - Materialbeschaffung- Vorbereitung Projektaufbau (Erstellung von Zeichnungen)- Herstellung des Projektaufbaus- Verdrahtung- Programmierung- Inbetriebnahme- Parallele Pflege der Dokumentation

Die zeitlichen Abfolgen sind im Projektplan (Anhang Seite 5.a) zu erkennen.

Neben Projektablaufplan und Zeitplan war es wichtig, einen guten und genauen Überblick über den Projektumfang zu erhalten und ein Pflichten- bzw. Lastenheft zu erstellen und zu pflegen. Somit war klar definiert, was gefordert war und wie die Umsetzung und Durchführung der Aufgabenstellung aussah. Das Pflichtenheft war mit Revisionsstand gepflegt und war daher immer auf dem aktuellsten Stand. Zu finden ist das Pflichtenheft im Anhang 5.b dieser Dokumentation.

Da zu Beginn der Planungsphase schon klar war, welche Teile mit absoluter Sicherheit im Projekt verbaut/eingebracht werden sollten, konnte die erste Materialanforderung gestellt werden. Die erste Phase der Beschaffung geschah deshalb so früh, weil das Material aus dem Palfinger-Lager in der Oberlausitz nach Krefeld geschickt wurde. Dieser Vorgang nimmt je nach Artikel und Menge ein bis zwei Wochen in Anspruch. Nach Auswahl eines geeigneten Lieferanten, der den im Pflichtenheft festgehaltenen Voraussetzungen entsprach, konnte anhand der nun zur Verfügung stehenden Daten der Umfang der Programmierarbeiten abgeschätzt werden. Da die Lieferzeiten einer neu konstruierten und personalisierten Bedieneinheit 12-14 Wochen betrug, war es am sinnvollsten, eine von der Firma HBC zur Verfügung gestellte Messe-Einheit zu benutzen. Diese ließ sich genauso Versionsstand Datum Verfasser Letzte Änderung Projektarbeit1.3 16.04.2012 M.Neitzel/T.Wolfers 02.07.2012 Fernsteuerung einer Hubarbeitsbühne

6

programmieren wie die zukünftig eingesetzte Bedieneinheit und war funktionell gleichwertig, wenn auch von den Ausmaßen her ein wenig kleiner.

Die entsprechende Software wurde so gestaltet, dass sie sich problemlos nicht nur in die vorhandene Bühnensoftware implementieren, sondern auch unabhängig von der Bedieneinheit benutzen und erweitern lässt. Ermöglicht wird diese Flexibilität durch den CAN-Bus. Dabei handelt es sich um ein asynchrones, serielles Bussystem, welches mit zu den Feldbussen gehört und als ISO 11898 international standardisiert ist. Das Empfängermodul, das sich an der Basis der HAB befindet, gibt vordefinierte Signale ab, die über das Bussystem ausgelesen und weiterverarbeitet werden können. Da das gewählte Empfängermodul mit jeglicher in Frage kommender Bedieneinheit kompatibel ist, können immer die gleichen Daten ausgelesen werden. So lässt sich auch im Falle der Zerstörung der Sendeeinheit ohne größeren Aufwand eine Ersatzbedienung einsetzen.

Im Verlaufe der Planungsphase fiel auf, dass nur unter Schwierigkeiten ein geeignetes Anschauungsobjekt für Präsentationszwecke zu beschaffen war, da sich die HAB, für die diese Steuerung entwickelt wird, selbst noch in der Entwicklungs- und Prototypenphase befindet. Aus diesem Grunde fiel die Entscheidung auf einen eigenen Projektaufbau. Das Ganze sollte auf einem extra angefertigten Gestell angebracht werden, das die Teilbereiche des Projekts gut erkennbar darstellt. Auf diesem Aufbau sollten verschiedene Dinge zu sehen sein: Zum einen das Empfängermodul auf der linken oberen Seite, rechts daneben die CPU von IFM. Direkt darunter sollten Kabelkanäle und die Klemmleiste für die Verdrahtung angebracht werden. Die Anbringung des Anzeigemoduls war für den unteren Bereich des Projektaufbaus geplant. Zur Anzeige von Videos und des Programms selbst sollte der Aufbau an der rechten Seite noch ein kleines Podest erhalten, auf dem ein Laptop platziert werden könnten. Ursprünglich sollte als Befestigungsgrundlage Holz dienen, letztendlich fiel die Entscheidung aber auf dickes und stabiles Makrolon5, um optisch ansprechender zu wirken.

Mithilfe eines CAD-Programms wurden die ersten Bauteile gezeichnet. Die 3D-Ansicht half dabei, mögliche Optimierungen direkt am Computer durchzuführen und eventuelle Schwachpunkte auszubessern, bevor die Bauteile gefertigt wurden.

Um eine Integration der neuen Komponenten in die bestehende Verdrahtung einer HAB zu ermöglichen, wurde der Aufbau der Klemmleiste - entsprechend der bevorstehenden Verdrahtung – wie folgt gestaltet:

- X4.N: Not-Aus-Kette- X4.C: CAN-Bus- X4.A: Analoge Ein-/Ausgänge, diverse andere Belegungen- X4.F: Sicherungsklemmen- X4.T: Trennklemme (benötigt für Programmierung des CR032 IFM Moduls)

5 Makrolon =


7

- X50: Kommunikationsschnittstelle (zum Aufspielen der Software und Konfigurieren der CPU)- X4.TP: Trennklemme zum Abtrennen der Spannungsversorgung der CPU (Programmierung)

Nachdem nun feststand, wie die Klemmleisten bezeichnet werden sollten, konnten die entsprechenden Pläne erstellt werden: Zum einen der Elektroplan, welcher mit Stromlaufplänen die Verdrahtung und den Zusammenhang der einzelnen Komponenten veranschaulicht, und der Klemmenanschlußplan, der genau dokumentiert, welche Verbindungen hergestellt wurden. Diese Unterlagen werden zukünftig der Technikabteilung von Palfinger zur Verfügung gestellt, sobald der Hauptverdrahtungsplan der Prototypenbühne erstellt wird. Der E-Plan6 und Klemmenanschlußplan befinden sich im Anhang dieser Dokumentation unter Punkt 5.e.

Anschließend erfolgte die grobe Planung der Software. Im Verlaufe der Planung tauchten einige Probleme auf, die es zu lösen galt; unter anderem die Frage, ob die bestehende Software angepasst oder das Programm komplett neu programmiert und auf den Projektaufbau abgestimmt werden sollte. Da aber im Nachhinein die Software auf eine HAB abgestimmt sein sollte, fiel die Entscheidung auf das Bearbeiten der vorhandenen Software. Zunächst wurde jedoch festgelegt, wie die Ein- und Ausgänge bezeichnet werden sollten, um hinterher die entsprechenden Variablen zu deklarieren. Hierzu wurde eine Zuordnungstabelle erstellt, um einen Überblick über die benötigten Signale zu erhalten:

- Eingang Joystick 1 FFB_JOY_1 INTEGER7

- Eingang Joystick 2 FFB_JOY_2 INTEGER- Eingang Joystick 3 FFB_JOY_3 INTEGER- Eingang Joystick 4 FFB_JOY_4 INTEGER- Eingang Fußtaster FFB_FUSSTASTER_KORB BOOL8

- Ausgang Hubarm auf HM_HA_AUF BOOL- Ausgang Hubarm ab HM_HA_AB BOOL- Ausgang Hubarm-Teleskop ausfahren HM_HA_TELE_AUS BOOL- Ausgang Hubarm-Teleskop einfahren HM_HA_TELE_EIN BOOL- Ausgang Korbarm auf HM_KA_AUF BOOL- Ausgang Korbarm ab HM_KA_AB BOOL- Ausgang Korbarm-Teleskop ausfahren HM_KA_TELE_AUS BOOL- Ausgang Korbarm-Teleskop einfahren HM_KA_TELE_EIN BOOL- Ausgang Fahrerruf HM_WARNTON BOOL

Da für die Bewegungen (Ausgänge) keine Ventile, sondern Leuchtmittel zur Verfügung stehen, wurde der Datentyp auf boolesche Variablen geändert. Im Normalfall werden hierfür Analogsignale ausgegeben, um die Ventile proportional anzusteuern. Weiterhin wurde festgelegt, welche ID der neue Teilnehmer (Empfängermodul) im Bus bekommen sollte. Die Entscheidung fiel auf die Nr. 5, 6 E-Plan = Elektroplan (Stromlaufplan)7 Integer = Datentyp für ganzzahlige Werte8 BOOL = zweiwertige Schaltvariable (true/1 = wahr, false/0 = falsch)


8

sprich ID05, da diese nicht nur frei war, sondern auch gut in das Bild der bereits bestehenden ID-Vergaben passte.

Des Weiteren wurde entschieden, mit einer Baudrate9 von 125k zu arbeiten. Das bedeutet zwar geringe, kaum spürbare Geschwindigkeitseinbußen bei der Symbolübertragung, jedoch wird dadurch eine höhere Stabilität gewährleistet. Im hier aufgebauten Bus sind zwar nur zwei Teilnehmer vorhanden (IFM CPU + Empfängermodul), im Einsatz der HAB allerdings kommen noch einige Teilnehmer hinzu und machen die Bus-Strecke störanfälliger.

Eine Baudrate von 125k reicht vollkommen aus, um eine sichere Kommunikation zu gewährleisten. Die Baudrate ist ein Begriff aus der Nachrichten- bzw. Fernmeldetechnik und gibt Aufschluss über die Schrittgeschwindigkeit von Symbolen, die sog. Symbolrate. Wird ein Symbol pro Sekunde übertragen, so spricht man von 1 Baud. Der Signalcode eines Symbols beinhaltet - je nach Codierung - unterschiedlich viele Bits des Datenstroms und entspricht einer Signaländerung, die sowohl messbar als auch klar definiert ist.

Nach Ausarbeitung der Programmrierroute war die Planungsphase so gut wie abgeschlossen und die ersten Lösungsvorschläge konnten umgesetzt werden.

2.c Lösungsansätze/DurchführungWie in 2.a beschrieben, sollte ein Projektaufbau gestaltet werden. Um Kosten zu sparen und den Aufwand so gering wie möglich zu halten, wurden Materialien verbaut, die bereits in der Produktion von Palfinger Platforms eingesetzt werden, wie etwa die für das Projektgestell benötigten Aluminiumprofile, die Leuchtmittel der Visualisierung, Klemmen und Leitungen. Ein weiterer Vorteil bestand darin, dass durch den Einsatz der genannten Materialien dieselben Bedingungen geschaffen wurden wie an einer echten HAB.

Der Aufbau zeigt links oben das Empfängermodul der Firma HBC radiomatic, welches direkt neben der CPU von IFM (rechts) angebracht wurde.

9 Baudrate =


9

Unter dem Empfänger befindet sich die Hauptklemmleiste, unterteilt in X4.N, X4.C, X4.A, X4.F, X50 und X4.T und X4.TB. Die Buchstaben geben Aufschluss über den Verwendungszweck der Klemmen, so steht z.B. das „N“ für Not-Aus Kette, das „C“ für CAN-Bus, das „A“ für Analogsignale, das „F“ für Fuse 10 und das „T“ für Trennklemme, welche zum Programmieren der CPU benötigt wird.

Direkt unter der Klemmleiste befindet sich das Anzeigemodul. Die Bewegungen werden durch Lichtsignale auf einer ebenfalls extra angefertigten Lichteinheit aus Makrolon angezeigt.

Da im Vorfeld sowohl ein E-Plan als auch ein dazugehöriger Klemmenanschlußplan erstellt wurden, konnte nun die Verdrahtung der entsprechenden Komponenten erfolgen. Für energieführende Strecken wurde ein Querschnitt von 1,5mm2, für Signalstrecken 1mm2 und für CAN-Strecken 0,34mm2 bzw. 0,5mm2 gewählt. Die Anbindung des Empfängermoduls erfolgte mittels eines Harting-Steckers, welcher in zwei 16-polige Anschlussstellen im Inneren aufgeteilt ist.

10 Fuse (engl.) = Sicherung


10

Hier wurde nur der erste 16polige Stecker benutzt, da dort die benötigten und vom Hersteller vorgegebenen Signale abgegriffen werden müssen. Der erste 16polige Stecker wurde mit X40.1 und der zweite mit X40.2 benannt. X40.2 dient rein zur direkten digitalen Ansteuerung. Diese wird nicht benötigt, da alle relevanten Signale, sowohl analog als auch digital, über den CAN-Bus verarbeitet und ausgelesen werden können.

Der Hardware-Grundstein war gelegt; nun konnte die Inbetriebnahme beginnen. Um in den verschiedenen Applikationen Verdrahtungsfehler, fehlende Abschlusswiderstände, Leitungsunterbrechungen oder Kurzschlüsse am CAN-Bus zu entdecken, wurden vor Inbetriebnahme des Projektes bei abgeschalteter Spannungsversorgung folgende Schritte durchgeführt:

- Alle Stellen, an denen die Leitungen des CAN-Bus unterbrochen sind (z.B. Schraubklemmen, Kabelverbindungen, Kabeldurchführungen, etc.), wurden einer Sichtprüfung unterzogen. Es wurde darauf geachtet, dass die Kabelenden fest und sauber verbunden sind.

- An beiden Enden der CAN-Busleitung wurde geprüft, ob die Abschlusswiderstände vorhanden und sauber angeschlossen sind. Bei Geräten mit internen Abschlusswiderständen wurde geprüft, ob diese zugeschaltet sind (durch Jumpereinstellungen, Kippschalter o.ä.)

- Mit Hilfe eines digitalen Multimeters, eingestellt auf Widerstandsmessung (Bereich 0 bis 500 ), wurde der Widerstand zwischen CAN_High und CAN_Low gemessen. Damit war prüfbar, ob die Abschlusswiderstände vorhanden und von richtigem Wert waren, bzw. ob irgendwo eine Leitungsunterbrechung oder ein Leitungsschluss vorlag. Der erwartete Messwert bei dieser Messung lag zwischen 55 und 70. Der gemessene Gesamtwiderstand betrug hier ungefähr 60, was auf einen geschlossenen Bus hinweist.


11

Der CAN-Bus ist so aufgebaut, dass der Widerstand bei ca. 60 liegt. Jeder CAN-Teilnehmer hat einen Innenwiderstand von 120. Des Weiteren befindet sich jeweils am Anfang und am Ende des Busses ein 120 Abschlusswiderstand.

Nun begann der softwarebezogene Teil. Zu Beginn musste jedoch erst einmal die CPU lauffähig gemacht werden. Hierzu musste die Firmware11 auf die CPU aufgespielt werden: dies geschah mit Hilfe eines sog. Bootloaders, welcher die Grundsoftware für das entsprechende IFM Modul (in diesem Falle CR0032) geladen hat, vergleichbar der Firmware anderer Geräte. Danach wurde dann die eigentliche Software auf die CPU überspielt, die letztendlich alle Funktion einer HAB beinhaltet.

Um das Empfängermodul im CAN-Bus zu integrieren und ansprechbar zu machen, musste es vorher in die bestehende Hardwarekonfiguration des Programms implementiert werden. Dies war möglich mit Hilfe eines sogenannten EDS-Files12. Das File wurde vom Lieferanten mitgeliefert und ermöglicht die nahtlose Einbindung in CoDeSys. Die Abkürzung „EDS“ steht für Electronic Data Sheet und verkörpert damit ein elektronisches Datenblatt bzw. Treiber, der alle Informationen über die Hardwarekomponente beinhaltet, wie z.B. Belegungen von Ein- und Ausgängen.

In Form eines Datenbausteins wurden also die Informationen in die Software übertragen. Dazu musste das EDS-File in die Hauptbibliothek von CoDeSys kopiert und in die Steuerungskonfiguration geladen werden. Diese ist vergleichbar mit einem Hardware-Manager – ähnlich wie bei Siemens Step7 – in dem sämtliche Komponenten aufgelistet sind, die mit der Software interagieren. Somit standen alle Ein-/Ausgänge zur Verfügung und konnten deklariert werden.

Bevor jedoch die Deklaration stattfand, musste geprüft werden, ob der Empfänger nicht nur im Bus, sondern auch mit dem Sendemodul erfolgreich kommuniziert. Hierfür wurde die Anlage elektrisch in 11 Firmware = Treibersoftware für die entsprechende Hardware12 EDS - Electronic Data Sheet (engl.) = Elektronisches Datenblatt


Gerät 1 Gerät 2 Gerät 3

120 120

CAN_H

CAN_L

12

Betrieb genommen, um zu schauen, ob alle Teilnehmer mit Spannung versorgt waren. Im Anschluss daran wurde die Funkstrecke zwischen Sender und Empfänger geprüft. Hierfür wurden die einzelnen Joysticks und Taster bewegt und es wurde darauf geachtet, ob sich die Statusanzeige am Empfänger ändert. Der Empfänger hat eine 5-LED-Anzeige:

- LED1: Betriebsspannung- LED2: ein = kein Funkempfang/aus = Funkempfang - LED3: Funkanlage betriebsbereit- LED4: Sicherheitskanal für Fahrbefehle- LED5: Rückmeldung

Hierbei fiel auf, dass bei Einschalten des Sendemoduls kein Funkkontakt hergestellt wurde. Nach einer kleineren Fehlersuche ist aufgefallen, dass der Not-Aus Kontakt des Empfängers falsch beschaltet wurde. Statt diesen mit Spannung zu versorgen wurde dieser nicht belegt. Das Problem wurde behoben und der Funkkontakt wurde hergestellt.

Nun konnten die einzelnen Bewegungen aufgenommen werden, um sie später in der Steuerung zu verarbeiten. Dafür wurden die einzelnen Betriebsmittel bewegt und das entsprechende Signal war in der Steuerungskonfiguration ablesbar. Somit war klar, welches Betriebsmittel mit den einzelnen Eingängen verknüpft war.

Betriebsmittel Adresse Wert Deklaration DatentypBewegung Steuerung

Joystick 1 :: Auf %IB906 +127 Hubarm Auf FFB_HA_AUF INTEGERJoystick 1 :: Ab %IB906 -128 Hubarm Ab FFB_HA_AB INTEGERJoystick 2 :: Auf %IB907 +127 Hubarmteleskop Aus FFB_HA_TELE_AUS INTEGERJoystick 2 :: Ab %IB907 -128 Hubarmteleskop Ein FFB_HA_TELE_EIN INTEGERJoystick 3 :: Auf %IB908 +127 Korbarm Auf FFB_KA_AUF INTEGERJoystick 3 :: Ab %IB908 -128 Korbarm Ab FFB_KA_AB INTEGERJoystick 4 :: Auf %IB909 +127 Korbarmteleskop Aus FFB_KA_TELE_AUS INTEGERJoystick 4 :: Ab %IB909 -128 Korbarmteleskop Ein FFB_KA_TELE_EIN INTEGERKippschalter 1 :: Hoch %IB898 +16 Fahrerruf FFB_WARNTON BOOLKippschalter 1 :: Runter %IB898 +32 Nicht belegtStartknopf :: Press %IB890 0 Freigabe/Reset FFB_RESET BOOLStartknopf :: Release %IB890 +1 Freigabe/Reset FFB_RESET BOOLNot-Aus :: Press %IB870 -1 Not-Aus Funktion FFB_NOTAUS BOOLNot-Aus :: Release %IB905 -1 Not-Aus Funktion FFB_NOTAUS BOOLEin/Aus – Schlüsselschalter :: An %IB897 -1 Betriebsbereitschaft ein FFB_KEYSWITCH BOOLEin/Aus – Schlüsselschalter :: Aus %IB905 -1 Betriebsbereitschaft aus FFB_KEYSWITCH BOOL

Mit Hilfe der zuvor erstellten Zuordnungsliste konnten Eingänge direkt in der Steuerungskonfiguration und Ausgänge über eine separate Variablenliste deklariert werden. Diese Art der Deklaration hat verschiedene Vor- und Nachteile. Festzuhalten ist jedoch, dass bei der Vergabe von festen Variablennamen für Eingänge per Variablenliste diese Namen absolut an diese Stelle in der Steuerungskonfiguration gebunden sind.


13

Fügt man später Komponenten hinzu, verschieben sich unter Umständen manche Zeilen und die Zuordnung muss umgeschrieben werden. Deshalb wurde hier der flexiblere Weg gewählt, die Eingänge direkt in der Steuerungskonfiguration zu deklarieren.

Die Ausgänge wurden in einer separaten Liste zugeordnet. Bei CoDeSys finden sich u.a. diese Variablenlisten unter „Ressourcen“. Dort wurde nun unter der Rubrik „Globale Variablen“ eine neue Liste erstellt mit dem Namen COM_ID05_HBC_FFB. Hier wurden Hilfsmerker deklariert, um die Ansteuerung des Anzeigemoduls zu ermöglichen. Hier ein Auszug aus der Variablenliste:

VAR_GLOBAL


14

(* Ausgänge *)

HM_HA_AUF :BOOL; (* QX0.00 / DIGITAL_OUTPUT 1 *)HM_HA_AB :BOOL; (* QX0.01 / DIGITAL_OUTPUT 2 *)HM_HA_TELE_AUS :BOOL; (* QX0.02 / DIGITAL_OUTPUT 3 *)HM_HA_TELE_EIN :BOOL; (* QX0.03 / DIGITAL_OUTPUT 4 *)HM_KA_AUF :BOOL; (* QX0.04 / DIGITAL_OUTPUT 5 *)HM_KA_AB :BOOL; (* QX0.05 / DIGITAL_OUTPUT 6 *)HM_KA_TELE_AUS :BOOL; (* QX0.06 / DIGITAL_OUTPUT 7 *)HM_KA_TELE_EIN :BOOL; (* QX0.07 / DIGITAL_OUTPUT 8 *)HM_WARNTON :BOOL; (* QX0.08 / DIGITAL_OUTPUT 9

*)HM_OPT_2 :BOOL; (* QX0.09 / DIGITAL_OUTPUT 10 *)

(* Hilfsmerker *)

HM_KEY_SWITCH :BOOL; (* Schlüsselschalter *)HM_NOT_AUS :BOOL; (* Not-Aus *)HM_START_RESET :BOOL; (* Start/Reset-Knopf *)

END_VAR

Nachdem nun Ein- und Ausgänge benannt waren, erfolgt die Zuweisung der einzelnen Ausgangsmerker für die entsprechenden Ausgänge an der CPU selber. Dafür wurde ein neuer Baustein in der Bausteinliste erzeugt. Dieser wurde FFB_OUT_DIGITAL genannt und ist wie folgt aufgebaut:

Im oberen Bereich der Programmierebene befindet sich ein kleines Fenster für die Zuweisung lokaler Variablen. Jeder Ausgang benötigt eine Zuweisung auf eine dieser lokalen Variablen und muss entsprechend seiner Funktion beschrieben werden, was hier durch die Anweisung :OUTPUT_CURRENT; geschieht. Hier ein Auszug:

PROGRAM FFB_OUT_DIGITALVAR

OC_Q00 :OUTPUT_CURRENT;OC_Q01 :OUTPUT_CURRENT;...OC_Q09 :OUTPUT_CURRENT;

END VAR

Direkt danach folgt die direkte Zuweisung auf die digitalen Ausgänge der CPU; hier ebenfalls ein Auszug:


15

(* Beschaltung OUTPUT_DIGITAL_Q0.00 *)

Q00_MODE:=137;

OC_Q00 (ENABLE := TRUE, OUTPUT_CHANNEL :=00, DITHER_RELATED := TRUE);

Q00 :=HM_HA_AUF;

In der ersten Zeile gab man dem Ausgang den zulässigen Konfigurationsmodus vor, in diesem Falle wurde der voreingestellte Wert 137 benutzt. Mit der nächsten Programmzeile wurde der Ausgang einem Kanal zugewiesen und der Baustein aktiv gesetzt. Dazu kam die Option, ob der Strom als Mittelwert über eine Dither-Periode13 oder eine PWM-Periode14 ermittelt werden sollte. Die Zustandsänderung des Ausgangs erfolgte dann in der letzten Zeile durch die Aktivierung eines Hilfsmerkers, in diesem Falle HM_HA_AUF. Wird dieser Merker „TRUE“ gesetzt, wird der Ausgang QX0.00 geschaltet und gibt ein digitales Signal raus. Das Ganze wiederholte sich entsprechend für die restlichen benötigten Ausgänge. Da nun sowohl Ein- als auch Ausgänge vollständig deklariert und beschaltet waren, wurde die eigentliche Funktion der Fernsteuerung entworfen. Auch hierzu wurde ein neuer Baustein programmiert, welcher die Joystickzuweisungen und ein paar Sonderfunktionen beinhaltet. Unter dem Namen HBC_FFB wurden folgende Funktionen beschrieben:

IF FFB_FUSSTASTER_KORB = FALSETHEN

(* Zuordnung der Joystickauslenkung auf entsprechenden Hilfsmerker - eingestellter Schwellenwert: 10/-10 *)

(* Joystick 1 *)IF FFB_JOY_1 > 10

THEN HM_HA_AUF:=TRUE;ELSE HM_HA_AUF:=FALSE;

END_IF...(* Warntongeber - Fahrerruf *)IF FFB_KIPP_BIT = 16

THEN HM_WARNTON:=TRUE;ELSE HM_WARNTON:=FALSE;

END_IF

END_IF

Als erstes wurde im Programm abgefragt, ob der Fußtaster im Korb gedrückt ist. Der Fußtaster galt hier als Sicherheitseinrichtung und soll nur dann gedrückt sein, wenn eine Person im Korb steht. Bei nicht betätigtem Fußtaster werden automatisch die Funkfernbedienung aktiviert und die 13 Dither = Dithering (engl. für „Zittern“) Statt störender Verzerrungen entsteht ein weniger störendes gleichmäßiges Rauschen, das dem eines analogen Verstärkers ähnelt. (Quelle: Wikipedia)14 PWM = Pulsweitenmodulation. Modulationsart, bei der eine technische Größe (z. B. elektrischer Strom) zwischen zwei Werten wechselt


http://de.wikipedia.org/wiki/Dithering_(Audiotechnik)

16

Bewegungen freigegeben. An der HAB selber wird es später noch andere Sicherheitseinrichtungen geben, wie z.B. die Abfrage über einen Lastmesssensor oder Ähnliches.

Da es sich bei den Bewegungen um analoge Signale handelte und der Projektaufbau nur die Möglichkeit hat, digitale Signale zu verarbeiten, mussten die Analogsignale umgewandelt werden. Da in der HAB später die Joysticks weiterhin als Analogwerte verarbeitet werden, wurde der Programmieraufwand hier so gering wie möglich gehalten. Ursprünglich wurde versucht, den Analogwert des Joysticks direkt auf einen Ausgang zu leiten, was sich aber als unmöglich erwies, da es beim Kompilieren15 zu einer Fehlermeldung kam. Daher fiel die Entscheidung auf die Unterstützung von Hilfsmerkern. Die - wie weiter oben beschrieben - vorher festgelegten Hilfsmerker können zur Absolutwertabfrage von Analogsignalen benutzt werden.

So konnte z.B. festgelegt werden, dass ein Hilfsmerker bei einem bestimmten Analogwert bei einer Auslenkung des Joysticks den Zustand „TRUE“ annahm. Wie das Beispiel oben zeigt, reagiert der Hilfsmerker ab einem Wert von 10 respektive -10 bei Auslenkung der negativen Achse des jeweiligen Joysticks. So konnte eine simple A/D-Wandlung16 umgesetzt werden, die einzig für das Projekt gedacht war. Um den Merker bei Loslassen des Joysticks wieder zu resetten, wurde diese Umkehrfunktion mit in die IF-Schleife genommen. Somit werden keine Bewegungen ohne Auslenkung der Joysticks angesteuert.

Abschließend mussten die neu geschriebenen Bausteine in der globalen Anweisungsliste aufgerufen werden. Um Komplikationen zu vermeiden, wurden entsprechend alle nicht benötigten Bausteine vorerst ausgeklammert, da hier nur sieben Bausteine zum Ablauf des Projektprogramms notwendig waren. Diese Liste wird zyklisch abgearbeitet, daher war darauf zu achten, die Bausteine ihrer Priorität entsprechend einzubinden. Hier ein Auszug aus der Anweisungsliste PLC_PRG:

RELAIS_VBBO:=TRUE;RELAIS_VBBR:=TRUE;

Objekt1xxxh();CAN_OPEN_STATUS();SPS_STATUS();

(* Funktionsbaustein für Funkfernbedienung laden *)HBC_FFB();

(* Ein- und Ausgänge laden *)FFB_OUT_DIGITAL();Der IFM-Controller verfügt über zwei interne Überwachungsrelais, die jeweils 8 Ausgänge von der Klemmenspannung VBBx trennen können. Daher müssen die entsprechenden Bits zuerst gesetzt werden. Dies geschieht mit Hilfe von RELAIS_VBBO:=TRUE; und RELAIS_VBBR:=TRUE;.

15 Kompilieren = das in einer Quellsprache geschriebene Programm wird in ein semantisch äquivalentes Programm in der Zielsprache übersetzt.16 A/D Wandlung =Analog/Digital-Wandlung. Analoge Signale werden in digitale Signale umgewandelt.


17

Der Baustein „Objekt1xxxh“ wird systembedingt zum Versenden der PDO’s17 benutzt und darf nicht gelöscht werden. Für den Controller wurde unter anderem noch der Baustein „CAN_OPEN_STATUS“ benötigt. Hier werden Informationen über den CAN-Bus und der eigene Status verarbeitet und herausgegeben. Mit diesen Informationen kann man in anderen Dateien entsprechend reagieren. Die Fehlermeldungen des eigenen Status werden in SPS_STATUS verarbeitet und herausgegeben, so dass man auch hier diese Informationen gezielt in anderen Bausteinen einsetzen kann.

Im Anschluss wurden nun die neuen Bausteine geladen; zuerst der Funktionsbaustein mit den Bewegungen (HBC_FFB) und danach die Ansteuerung der Ausgänge (FFB_OUT_DIGITAL). Zu Simulationszwecken wurde noch eine Visualisierung der Fernbedienung in CoDeSys erstellt, auf der man die Hilfsmerker entsprechend anzeigen lassen kann. Parallel dazu wurde ein Diagnosefenster entworfen, in dem der CAN-Status des neu hinzugefügten Teilnehmers (Funkfernbedienung ID05) angezeigt werden kann, mit entsprechendem NODE18_Status. Der NODE_Status gibt Auskunft über den Status des Knotens; dabei kann er verschiedene Zustände annehmen:

Status Beschreibung hex dezFF -1 Der Slave wird durch die NMT-Nachricht (Reset Node) zurückgesetzt und wechselt selbstständig in

den Status 1.00 0 Nicht definiert01 1 Status = Warten auf BOOTUP

Der Slave wechselt nach einer maximalen Zeit von 2s oder sofort nach Empfang seiner Bootup-Message in den Status 2.

02 2 Status = BOOTUPDer Slave wechselt nach einer Verzögerung von 0,5s automatisch in den Status 3.

03 3 Status = PREPAREDIm Status 3 wird der Slave konfiguriert. Der Slave bleibt solange im Status 3, bis er alle vom Konfigurator erzeugten SDOs erhalten hat.

04 4 Status = PRE-OPERATIONALEin Knoten wechselt immer in den Status 4, außer:

- Es handelt sich um einen „optionalen“ Slave und er wurde als nicht am Bus verfügbar deklariert

- Der Slave ist zwar vorhanden, aber hat auf die Abfrage des Objekts 1000,16 mit einem anderen Typen in den unteren 16bits reagiert, als der Konfigurator erwartet hat.

05 5 Status = OPERATIONALIm Status 5 findet der normale Datenaustausch statt: „Normale Operation“.

61 97 Ein Knoten wechselt in den Status 97, wenn er optional ist und nicht auf die SDO-Anfrage nach dem Objekt 1000,16 reagiert hat.

62 98 Ein Knoten wechselt in den Status 98, wenn der Gerätetyp nicht dem konfigurierten Typ entspricht.63 99 Im Falle eines Nodeguarding-Timeouts wird der Slave auf Status 99 gesetzt.Die zuvor erwähnte Visualisierung dient nicht nur zu Anschauungszwecken, sondern kann auch als Überwachungsmodul eingesetzt werden. Die Variablen, wie z.B. die Hilfsmerker für die Joystickauslenkungen, Schlüsselschalter, Kippschalter etc. wurden auf die entsprechenden Ausgabebilder gelegt.

17 PDO’s = Process Data Object = Nachrichten-Objekt mit Prozessdaten18 NODE (engl.) = Knoten


18

Die Zustände der einzelnen Variablen wurde hier durch rote Kreise signalisiert. Je nach Zustand der Variable färben sich die Kreise grün bei Aktivierung bzw. Zustandseinnahme TRUE respektive rot bei Deaktivierung bzw. Zustandsänderung FALSE.

Das Diagnosefenster wurde wie folgt gestaltet:


19

Im grauen Feld befindet sich der Name des Teilnehmers, sowie die Statusrückmeldung in Form eines Kreises, der auch je nach Zustand die Farbe in grün für aktiv und rot für passiv bzw. nicht im Bus vorhanden darstellt. NODE_A_05 %s ist die Variable, die für den entsprechenden Status des Knotens steht. Die verschiedenen Zustände wurden in der Liste weiter oben beschrieben.

Nach dem Erstellen des Datenbausteins HBC_FFB, der Ausgangsbeschaltung FFB_OUT_DIGITAL, der Hilfsmerkerdeklaration in COM_ID05_HBC_FFB, der Variablenvergabe in der Steuerungskonfiguration und der Erstellung der Visualisierung war der programmierbezogene Teil abgeschlossen. Es folgte die Inbetriebnahme bzw. Prüfung des Programms. Hierfür wurden lediglich die die einzelnen Betriebsmittel angesteuert, die bei richtiger Programmierung das entsprechende Anzeigemodul zum Leuchten bringen. Alles lief wie gewünscht, alle Bewegungen wurden richtig belegt. Als Demonstration wurde ein Fußtaster eingebaut, der, sofern betätigt, eine Person im Korb simuliert und die Funkfernbedienung passiv schaltet.

Während sich jemand im Korb der HAB befindet, darf die Funkfernsteuerung nicht aktiv sein bzw. es darf sich niemand im Korb befinden, wenn die HAB mit der Funkfernbedienung gesteuert wird. Damit war auch der programmierbezogene Teil dieses Projekts abgeschlossen.

3. INFORMATIONEN ZUVersionsstand Datum Verfasser Letzte Änderung Projektarbeit1.3 16.04.2012 M.Neitzel/T.Wolfers 02.07.2012 Fernsteuerung einer Hubarbeitsbühne

20

3.a HardwareZur Realisierung der Steuerung wurden folgende u.a. Komponenten eingesetzt:

- CPU CR0032 der Firma IFM (Beschreibung siehe Anhang 5.d)- Taster mit Leuchtmittel der Firma Klöckner Möller- COM19 Schnittstelle Sub D9 der Firma Murr Elektronik (Beschreibung Siehe Anhang 5.d)- Klemmen der Firma Murr Elektronik- Sicherungsklemmen der Firma Murr Elektronik

3.b SoftwareDie Programmierung des Datenbausteins erfolgte mit CoDeSys V2.3.9.3 der Firma Smart Software Solutions GmbH. Mit diesem Programm hat man die Möglichkeit, in allen fünf zur Verfügung stehenden Sprachen laut IEC 61131-3 zu programmieren. Diese lauten:

AWL (Anweisungsliste) ST (Strukturierter Text, angelehnt an PASCAL zur strukturierten Programmierung) KOP (Kontaktplan) FUP/FBS (Funktionsbausteinsprache). AS (Ablaufsprache)

Die für dieses Projekt erstellte Software wurde in Strukturiertem Text und Funktionsbausteinsprache programmiert. Ausdrücke befinden sich im Anhang unter 5.f. Zur Erstellung des E-Plans wurde Microsoft VISIO benutzt, da sich dieses Programm nicht nur über MSDNAA kostenlos nutzen lässt, sondern, weil es in der Handhabung relativ einfach aber dennoch effektiv ist. Natürlich kam auch hier das Officepaket von Microsoft zum Tragen; Word für die Dokumentation, Excel für Klemmenplan und Stückliste. Der Projektplan wurde mit Hilfe von Microsoft Project 2010 erstellt.

3.c FunksteuerungNach sorgfältiger Auswahl des Herstellers, in Anlehnung an das Pflichten/Lastenheft, fiel die Entscheidung auf die Firma HBC Radiomatic. Die Firma stellt Funkfernsteuerungen für Krane, Hebezeuge, Mobilhydraulik, Forstanwendungen, Kommunikation und Ex-Bereiche her. Für die Projektarbeit wurde folgendes bestellt:

- FFB20 Sendermodul Linus4 der Firma HBC (Beschreibung Siehe Anhang 5.d)- FFB Empfängermodul FSE 727 radiobus der Firma HBC (Beschreibung Siehe Anhang 5.d)

4. LAYOUT/ANZEIGEMODUL

19 COM = Abk. für Communication (engl.) = Kommunikation20 FFB = Funkfernbedienung


http://de.wikipedia.org/wiki/Ablaufsprache

http://de.wikipedia.org/wiki/Funktionsbausteinsprache

http://de.wikipedia.org/wiki/Kontaktplan

http://de.wikipedia.org/wiki/Strukturierter_Text

http://de.wikipedia.org/wiki/Anweisungsliste

http://de.wikipedia.org/wiki/IEC_61131-3

21

Das Layout für das Anzeigemodul wurde in Word erstellt und später auf Folie ausgedruckt. Die Folie wurde entsprechend der Vorgabe auf eine weiße dünne Kunststoffplatte geklebt, die vorher entsprechend gebogen wurde (siehe Bild 02).

Bild 01: Word-Vorlage für Foliendruck

Bild 02: Fertiges Anzeigemodul an der Anlage


22

6. FAZIT

Nach knapp vier Monaten ist das Projekt „Fernsteuerung einer HAB“ so gut wie abgeschlossen. Im Verlaufe der Projektphase wurden vorhandene Kenntnisse erweitert und zusätzlich völlig neues Wissen erarbeitet, speziell im Bereich der Automatisierungstechnik und darin vor allem der Programmierung mit CoDeSys. Neben der Verarbeitung analoger Signale wurde auch die Arbeit in der Digitaltechnik vertieft sowie das praxisnahe Programmieren von CAN-Bus-Steuerungen. Natürlich war der Projektablauf nicht reibungslos; so kam es etwa im Verlaufe der Planung oft zu Materialknappheit, da das benötigte Material nicht pünktlich geliefert wurde und daher Ausweichkomponenten verbaut wurden, die dann im Verlaufe der Montage des Projektgestells ausgetauscht wurden. Ein weiteres und auch das größte Problem war die Programmierung mit CoDeSys.

Die vorhandenen Kenntnisse mit dieser Software reichten nicht aus, um ein Programm zu schreiben, das die gewünschten Funktionen umsetzt. Nach zahlreichen Nachtschichten und dem Wälzen der Dokumentationen zu der IFM CPU CR0032 und des CoDeSys Handbuchs war es dann doch möglich, im Trial&Error-Verfahren die entsprechende Software zu programmieren. Sinnvoll erscheinende Schritte wurden ausprobiert und auf Funktionstüchtigkeit geprüft. Die Anpassung an die vorhandene Bühnensoftware gestaltete sich letztendlich doch einfacher als eingangs befürchtet. Dadurch, dass die Grundsoftware gut kommentiert und strukturiert war, war die Implementierung des neu erstellten Datenbausteins schon fast Routine. Alles Unwichtige bzw. die für die Funktion des Projektaufbaus nicht benötigten Daten und Bausteine wurden entsprechend ausgeklammert.

Durch die entstandenen Probleme, aber auch durch die gut aufgebauten Dokumentationen von IFM und CoDeSys war es möglich, das Programm funktionstüchtig zu gestalten. Weiterhin von großem Nutzen war die Auswahl eines geeigneten Lieferanten für die Steuerung. So kam auch der kaufmännische Aspekt bei dieser Projektarbeit nicht zu kurz, da ein sowohl zuverlässiges und funktional flexibles, als auch kosteneffizientes Modul gefunden werden musste.

Besonders angenehm war die hervorragende Zusammenarbeit aufgrund der Aufgabenverteilung im Team. Durch das Setzen von Meilensteinen und das regelmäßige Führen von To-Do-Listen und Gesprächsprotokollen konnte eine gute Zusammenarbeit ohne Überschneidungen, Wartezeiten oder Dopplungen gewährleistet werden. Ebenfalls von großem Vorteil waren die zahlreichen Skype-Telefonate, in denen man im Vorfeld schon einige Dinge besprechen konnte.


23

Das sagt Herr Neitzel über die Projektarbeit:

„Mir hat es großen Spaß gemacht, ein Projekt zu bearbeiten, das später mal in der Praxis eingesetzt wird und nicht als Anschauungsobjekt in einer Ecke steht. Anfangs machte ich mir schon Gedanken, ob z.B. die Programmierung nicht doch mehr Zeit in Anspruch nehmen würde, da wir ja mit CoDeSys in der Form noch nie gearbeitet haben. Aber letztendlich ging unser Zeitplan auf und wir sind pünktlich mit Allem fertig geworden!“

Das sagt Herr Wolfers über die Projektarbeit:

„“


24

7. EIDESSTATTLICHE ERKLÄRUNG

Projektteilnehmer 1:_________________________________________________________________________

Projektteilnehmer 2:_________________________________________________________________________

Wir erklären mit unseren Unterschriften, dass wir die vorstehende Arbeit selbstständig und ohne fremde Hilfe angefertigt haben. Wir haben alle Stellen, die wir wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen haben, als solche kenntlich gemacht und uns auch keiner anderen als der angegebenen Literatur oder sonstiger Hilfsmittel bedient. Die Arbeit hat in dieser oder in ähnlicher Form noch keiner anderen öffentlich rechtlichen oder staatlichen Prüfungsstelle vorgelegen.

______________________________ ______________________________(Ort, Datum) (Unterschrift der Verfasser)


25

8. INFORMATIONSQUELLEN

Informationen zu HBC FSE 767 EmpfängermodulDokumentation von HBC, Anhang 5.d

Informationen zu HBC linus 4 SendemodulDokumentation von HBC, Anhang 5.d

Informationen zu IFM CR0032 und CoDeSysDokumentation von HBC, Anhang 5.d

Sonstige Informationsquellen

http://www.wikipedia.de


Fernsteuerung einer Hubarbeitsbühnemn-webdesign.com/.../FINAL/Dokumentation_Projektarbe… ·...

Documents

Transcript of Fernsteuerung einer Hubarbeitsbühnemn-webdesign.com/.../FINAL/Dokumentation_Projektarbe… ·...