Often just oem windows 7 serial a minor piece of technical advice will solve most software problems and it's important that your software run right. It helps, purchase windows 7 enterprise, in effective management of escrow accounts property REO for investors real estate transactions (purchase/sale lease deposits etc. If you windows 7 oem hash are credulous enough to run this program it just installs a Spyware instead of eliminating any.

Alder-Wiki
Anmelden 
Artikel  Diskussion  bearbeiten  Versionen 

Diplom

aus Alderwiki, der freien Wissensdatenbank

Der vorliegende Text wurde automatisch mit OpenOffice 2.3 "wikifiziert"

Die Arbeit liegt auch als PDF vor.

Technische Universität Chemnitz

Fakultät für Maschinenbau

Diplomarbeit

Thema:Baukasten für die Produktentwicklung von

Motorspindeln auf Basis Virtueller Realität


vorgelegt von: Tim Alder

geb. am: 03.05.1976 in: Chemnitz

Studiengang: Aufbaustudium Maschinenbau

Betreuer: Dipl.-Ing. Ralf Steiner

Tag der Ausgabe:01.02.2005

Tag der Abgabe:30.06.2005


Referat

Es war das Ziel, ein Konzept zur Umsetzung eines Baukastens für die rechnergestützte Produktentwicklung von Motorspindeln zu erarbeiten. Im Umfang der Arbeit wurden Lösungsprinzipien zur Lagerstellengestaltung, zur Motorenauswahl, der Gestaltung der Werkzeug- und Werkstückaufnahme sowie der Gehäuseformen analysiert und in geeigneter Form mittels Werkzeugen der Virtuellen Realität visualisiert. Nach der Entwicklung der untereinander kompatiblen funktionalen Bausteine für das Baukastensystem wurden die Möglichkeiten der VRML eigenen Skriptsprache verwendet, um bei geringen Datenmengen eine effiziente Baugruppendarstellung für die VR zu ermöglichen. Die Geometrieerzeugung wurde außerdem auf einen Web-Server verlagert, um bei der Umsetzung eines Produktmodells auch nichtgeometrische Daten sinnvoll zu integrieren und ein verteiltes Arbeiten zu ermöglichen. Am Beispiel der Motorspindel entstand ein über Webformulare konfigurierbares, auf Bauteilschnittstellen und Geometrieparametern basierendes Baukastensystem, dessen Visualisierungen in der weitere Baukastenplanung zum Zweck der Bewertung und Optimierung in der VR genutzt werden kann.

Aus dieser Entwicklung wurden Erkenntnisse für die zukünftige Anwendung der Virtuellen Realität bei der Produktentwicklung abgeleitet.


Danksagung

Für die konstruktive Zusammenarbeit möchte ich mich bei meinem Betreuer Herr Dipl. Ing. Ralf Steiner bedanken. Dank für die zur Verfügung gestellten Möglichkeiten möchte ich den Mitarbeitern des Universitätsrechenzentrums und des VRCPs aussprechen.

Inhaltsverzeichnis


Verzeichnis der Abkürzungen

B-Rep: Boundary Representation

CAVE: Cave Automatic Virtual Environment

CSG: Constructive Solid Geometrie

ERP: Enterprise-Resource-Planning

DB: Datenbank

HSC: High Speed Cutting

HSK: Hohlschaftkegel bzw. Kegel-Hohlschaft

HTW: Hochschule für Technik und Wirtschaft Mittweida

LOD: level of detail

MCAD: Mechanical Computer Aided Design

Ms. Motorspindel

MySQL MySQL-Datenbanksystem

PHP „PHP Hypertext Preprocessor“ oder früher “personal homepage tools”

PLM Produktlebenszyklusmanagement

SPS speicherprogrammierbare Steuerung

Ws. Werkstück

Wz. Werkzeug

VRCP Virtual Reality Center Production Engineering in Chemnitz

VRML Virtual Reality Modeling Language

VR Virtuelle Realität


Verzeichnis der Formelzeichen


q[mm] generalisierter Verschiebungsvektor

p[N] generalisierter Kraftvektor

CSteifigkeitsmatrix

DDeformationsmatrix

Mgeneralisierte Massenmatrix


Betrachtungen zur Motorspindel

Einordnung der Motorspindel in die Werkzeugmaschine

Eine Motorspindel bezeichnet den Zusammenschluss eines Elektromotors und einer Spindel auf einer gemeinsamen Welle. Sie gehört damit in die Gruppe der rotativen Direktantriebe, da die in klassischen Hauptantrieben vorhandenen mechanischen Übertragungselemente (Riementrieb, Getriebe) zwischen Antrieb und Prozess entfallen.

Aufgrund ihrer Funktion als Hauptantrieb zur Erzeugung der Schnittbewegung und ihrer direkten Verbindung zum Werkzeug oder Werkstück hat sie eine entscheidende Bedeutung für die Qualität und Wirtschaftlichkeit des Zerspanungsvorganges.

Die Baugruppe Motorspindel besteht neben dem eigentlichen Bauteil Hauptspindel, aus den Lagern, dem Gehäuse und dem Motor. Zudem sind Dichtungen, Kühlmittelleitungen und Vorrichtungen zur Steuerung und Überwachung integriert. Das Bauteil Hauptspindel enthält die Aufnahmeflächen für das Werkzeug bzw. Werkstück und dient als Träger des entsprechenden Spannsystems. Eine typische Ausführung ist in Abbildung 1 dargestellt.

[[Image:]]

Abbildung 1: Funktionsgruppen einer Frässpindel (Quelle: CyTec Zylindertechnik GmbH)

Die Spindel mit ihrer Lagerung und dem Gehäuse umfasst dabei die folgenden Hauptfunktionen [RAMA-00], [HIRS-00]:

  • Übertragen des Motormomentes und der Drehzahl in das Werkzeug bzw. Werkstück
  • Aufnahme des Spannsystems für das Werksstück oder das Werkzeug
  • Führen der rotatorischen Bewegung mit einer ausreichenden Genauigkeit
  • Übertragen der Prozess- und Gewichtskräfte in das Gestell bei niedrigen statischen, dynamischen und thermischen Verlagerungen
  • Integration von Mess-, Überwachungs- und Kühlmittelzufuhreinrichtungen


Das System Motorspindel besitzt sowohl Schnittstellen in Richtung Prozess als auch in Richtung Gestell. Diese Schnittstellen unterteilen sich in mechanische Befestigungen und Versorgungsleitungen (s. Abbildung 2).


Abbildung 2: Schnittstellen der Motorspindel


Durch den Zusammenschluss von Motor und Hauptspindel werden folgende Vorteile erreicht:

  • Es wird eine hohe Torsionssteifigkeit des Antriebes bei geringer Schwingungsanfälligkeit und hoher Dynamik ermöglicht.
  • Die Hauptantriebseinheit kann kompakter gebaut werden, dieses ist besonders wichtig bei Frässpindeln, die in zweiachsig verstellbaren Schwenkköpfen zum Einsatz kommen.
  • Die Spindel wird durch die Krafteinleitung nicht auf Querkraft belastet und hat einen ruhigen Lauf auch bei kleinen Drehzahlen.
  • Besondere Eignung zur HSC-Bearbeitung mit hohen Drehzahlen bei kleineren Drehmomenten [SCHR-02].

Möglich wurde diese Entwicklung durch neue, leistungsstarke, in der Drehzahl regelbare Hohlwellenmotoren. Diese werden sowohl in Spezialanfertigung [KESS] produziert, als auch in standardisierte Baureihen [SIEM] angeboten.

Als Nachteile sind zu erwähnen:

  • Es können keine Standardelektromotoren zum Einsatz kommen. Im Gegensatz zu klassischen Maschinenkonzepten, wo diese Motoren auch thermisch entkoppelt von der Maschine arbeiten und z. T. einfach luftgekühlt werden.
  • Die Wärmeentwicklung durch Blindströme [WECK-02a, S.520] kann im Rotor zu Temperaturen bis 120-160°C führen, da dieser Bereich schwierig zu kühlen ist. Dieses führt bei ungünstiger Konstruktion zu erheblichen Belastungen der Lagerstellen und zu thermischen Verformungen.
  • Es ist bei Motorspindeln nicht möglich, die Spindelmomente und -drehzahlen über ein Getriebe an die Prozessanforderungen anzupassen.

Aufgrund der bestehenden Vorteile geht der Trend in der spanenden Fertigung eindeutig in Richtung Motorspindel [SCHR-02], mit dafür verantwortlich sind auch die durch neue Schneidwerkstoffe erreichbaren höheren Schnittgeschwindigkeiten, die sich bei kleiner werdenden Werkzeugdurchmessern (Fräsen) nur über höhere Drehzahlen erreichen lassen.


Unterscheidung nach dem Fertigungsverfahren

Große Teile der späteren Betrachtungen sind sowohl auf Drehmaschinen als auch auf Fräsmaschinen zutreffend. Um abzuklären, ob das zu realisierende Baukastensystem sowohl auf werkstück- als auch auf werkzeugtragende Spindeln und somit auf Dreh- und Frässpindel einheitlich anwendbar ist, sind die Unterschiede in Tabelle 1 aufgeführt.

Tabelle 1 Vergleich von Motorspindelausführungen nach dem Fertigungsverfahren


Drehspindeln
Fräs- und Bohrspindeln
Funktion
Träger des Spannfutters und somit des Werksstückes. Träger des Werkzeugspannsystems und somit des Werkszeuges (HSK oder Steilkegel).
Form des vorderen Lagers
Die äußere Form des vorderen Lagerschildes hat keinen größeren Einfluss auf die Flexibilität der Fertigung. Um mit dem Fräser auch vertiefte Stellen des Werkstückes zu erreichen, ist es vorteilhaft, das vordere Lagerschild der Spindel möglichst schlank auszuführen.
Lagerabstand
Bei längeren Werkstücken ohne Anwendung eines Reitstockes ergibt sich aufgrund des längeren Lastangriffshebels ein größerer optimaler Lagerabstand. Die Lagerabstände sind im Vergleich eher kurz. Eine Ausnahme sind Frässpindeln für vertieft liegende Stellen mit langen Fräsern.
Einbauvarianten
Der Einbau erfolgt in horizontaler oder bei PickUp-Drehmaschinen in verti-kaler Position.

(Die Einbauposition ist bei der Planung des Schmiermittelflusses zu berücksichtigen.)

Neben dem Einbau in horizontalen und vertikalen Bearbeitungszentren ist immer stärker der Einsatz in 5-Achszentren verbreitet, dabei ist eine Platz sparende Bauweise von besonderer Bedeutung.
Motor-
dynamik
Abbremsen und Beschleunigen ist zum Werkstückwechsel sowie beim Formdrehen notwendig (um konstante Schnittgeschwindigkeit zu erzielen). Das Beschleunigungsverhalten ist für die Wirtschaftlichkeit bedeutender als bei Drehspindeln (Span-zu-Span-Zeit).
Schnitt-bewegung
Drehen: Die geschlossene Schnittbewegung führt zu geringen dynamischen Beanspruchungen. Fräsen: Die nicht ständig im Eingriff befindliche Schneide bewirkt hohe dynamische Belastungen.

Bohren: mit geringen Radialkräften

Prozess-versorgung
Die Materialzuführung kann über Stangenmaterial von hinten, über externe Roboterzuführung oder manuell erfolgen. Die Verwendung von Stangenmaterial hat entscheidenden Einfluss auf die Spindelkonstruktion. Das Werkzeug wird bei Minimal- mengenschmierung durch die Spindel mit Kühlschmiermittel versorgt. Das Spannsystem benötigt incl. seiner Sensoren diverse Versorgungsleitungen.
Sonderformen
Zum Teil wird die Spindel zusätzlich als C-Achse ausgeführt, um dann mit angetriebenen Werkzeugen auf einer hauptsächlich für das Drehen genutzten Maschine auch Fräsarbeiten durchzuführen. auswechselbare Frässpindeln die über die Steilkegel- oder HSK-Aufnahme mit der WZM verbunden sind [LANG]
Hauptkenngrößen
Hauptkenngrößen der Drehmaschinen sind der größten aufnehmbaren Werksstückdurchmesser und dessen Länge. Hauptkenngrößen der Fräsmaschinen, welche in Verbindung mit der Motorspindel stehen, sind die Spindeldrehzahl und -leistung sowie der Werkzeugaufnahmekegel.

Aufgrund des gleichen funktionalen Aufbaus von Motorspindeln für Fräs-, Dreh-, Bohr- und Schleifaufgaben, scheint es trotz der aufgezeigten Unterschiede als durchaus sinnvoll, ein gemeinsames Baukastensystem für diese Fertigungsverfahren zu entwickeln und somit einen größeren Absatzmarkt abzuschöpfen. Ein weiterer Grund für die Entwicklung eines relativ universellen Baukastensystems im Rahmen dieser Arbeit ist, dass das konkrete Spannsystem als Subsystem (z. B. [OTT]) in der Hauptspindel relativ eigenständig arbeitet und als mögliches Zukaufteil nicht den näheren Gegenstand dieser Betrachtung darstellt.

Abgrenzung des betrachteten Themengebietes

Aufgrund des umfangreichen Themengebietes und der Vielzahl möglicher Ausführungsformen von Motorspindeln können in dieser Arbeit nicht sämtliche Sonderformen erwähnt werden. Zudem liegt der Aufgabenschwerpunkt der Arbeit weniger in der technisch-technologischen Weiterentwicklung des Produktes Motorspindel, sondern in der Konzeption eines Verfahrens zur Baukastenentwicklung unter Berücksichtigung der VR am Beispiel der Motorspindel.

Die Werkzeugspannsysteme werden ohne Berücksichtigung der Morsekegelaufnahme (kein automatisierter Werkzeugwechsel möglich), der japanischen MAS-BT-Schnittstelle oder der amerikanischen ANSI-CAT-Schnittstelle betrachtet.

Diese Betrachtungen umfassen ausschließlich Spindeln mit einer Leistung von größer als 1 kW. Sonderausführungen wie Karusselldrehmaschinen werden hier ebenfalls nicht untersucht.

Zu den nicht weiter untersuchten Spindelvarianten zählt auch die in Abbildung 3 dargestellte Form einer aerostatisch gelagerten Spindel mit außenliegendem Rotor und innenliegendem Stator.

Die in Abbildung 4 dargestellte Sonderform, ist ebenfalls nicht Gegenstand der Arbeit. Sie besitzt einen besonders langen Spindelhals mit zusätzlichen aerostatischen Lagern, um auch tiefer gelegene Stellen mit dem Fräser erreichen zu können.


[[Image:]]
Abbildung 3: Patent [DPMA] DE 19831951 A1 D. Schall
[[Image:]]


Abbildung 4: Patent [DPMA] DE 199551405 A1 Firma ACTECH

Systematik zur Klassifikation von Motorspindeln

Zuordnung der Baugruppen zur Funktionsausbildung

Zur Darlegung der Funktionen der einzelnen Baugruppen in einer Motorspindel sei auf Abbildung 5 verwiesen. Darin sind die Funktionen, die Parameter und die üblichsten Varianten der Baugruppen als Problemvisualisierung aufgeführt.

Dabei werden die Funktionen der Drehmoment- und Drehzahlerzeugung der Baugruppe Motor zugeordnet. Die Prozesskräfte werden über die Spindelwelle, die Lagerungen und das Gehäuse in das Gestell eingeleitet. Als Schnittstelle zur Werkzeugmaschine und als Träger der anderen Baugruppen dient das Gehäuse der Motorspindel. Die Sensorikbauteile zur Drehzahl- und Positionsbestimmung, zur Temperatur- und Vibrationsüberwachung und zur Sicherstellung des automatisierten Spannvorganges sind an verschiedenen Baugruppen der Motorspindel befestigt. Die Dichtungen befinden sich einerseits zwischen der Spindel und dem Gehäuse, um das sensible Innenleben der Motorspindel vor den Einwirkungen aus dem Spanungsprozess zu schützen. Andererseits sind Dichtungen vorzusehen, um das Eindringen von Kühlmittel zu verhindern, häufig werden diese Dichtungen durch die Verwendung von Sperrluft unterstützt.



Abbildung 5: Funktionale Baugruppen einer Motorspindel, deren Parameter und Varianten

Parametrisierung der Schnittstellen zum Prozess

In diesem Kapitel werden die genormten Schnittstellen zum Werkzeug bzw. zum Werkstück hinsichtlich ihrer geometrischen Parameter (Tabelle 2) untersucht. Daraus sollen im weiteren Parametrisierungsmöglichkeiten für das spätere Baukastensystem abgeleitet werden.


Spannfutteraufnahmen gemäß DIN 55022-26 Steilkegel

gemäß DIN 2079


HSK-Aufnahme

gemäß DIN 69893-1



[[Image:|thumb|{| class="prettytable" | {| class="prettytable" |
Nr. |
d1
[mm]
|- |
3
|
92
|- |
4
|
108
|- |
5
|
133
|- |
6
|
165
|- |
8
|
210
|- |
11
|
280
|- |
15
|
380
|- |
20
|
520
|- |
28
|
725
|- | | |- | | |} | |}]]
[[Image:|thumb|{| class="prettytable" | {| class="prettytable" |
Nr. |
d1
[mm]
|- |
30
|
31,75
|- |
40
|
44,45
|- |
45
|
57,15
|- |
50
|
69,85
|- |
55
|
88,90
|- |
60
|
107,95
|- |
65
|
133,35
|- |
70
|
165,10
|- |
75
|
203,20
|- |
80
|
254,00
|- | | |} | |}]]
[[Image:|thumb|{| class="prettytable" | {| class="prettytable" |
Nr. =d1 |
d2
[mm]
|- |
32
|
24
|- |
40
|
30
|- |
50
|
38
|- |
63
|
48
|- |
80
|
60
|- |
100
|
75
|- |
125
|
95
|- |
160
|
120
|- | | |} | |}]]

Tabelle 2: Gegenüberstellung der verschiedenen standardisierten Schnittstellen mit ihren Hauptabmessungen


Die Analyse der in den Normen aufgeführten Abmessungen zeigte, dass nur die HSK-Schnittstelle nach dem System der Normzahlreihen gemäß DIN 323 (R10) aufgebaut ist. Somit wurde diese Schnittstelle im späteren Baukastensystem ausgewählt, um beispielhaft die Geometriegenerierung über einen einzelnen Parameter zu demonstrieren.


Lagerarten und -gestaltungen

Die Lagerung kann neben der Wälzlagerung über hydrostatische, hydrodynamische, aerostatische, aerodynamische oder elektromagnetische Lagerung erfolgen.

Dabei besitzen die Wälzlagerungen einen Marktanteil von ca. 90%, deren gebräuchlichsten Ausführungen sind in Tabelle 3 dargestellt:


O-Anordnung aus vorderem und hinterem Lager (Kegelrollenlager)
[[Image:]]
axiales Festlager über Axial-schrägkugellager vorn und Radiallager auf Basis von Zylinderrollenlagern
[[Image:]]
axiales Festlager (Schrägkugellager in Tandem-O-Anordnung) an der vorderen Lagerstelle und Loslager am hinteren Lager.
[[Image:]]
An der vorderen und an der hinteren Lagerstelle Schrägkugellager in O-Anordnung
[[Image:]]

Tabelle 3: Gebräuchliche Spindelkonstruktionen [WECK-02a]

Aufgrund der bei Motorspindeln üblichen hohen Drehzahlen werden als Wälzlagerlösungen überwiegend Kugellager eingesetzt. So treten im Einsatzbereich von 5000 U/min bei Schrägkugellagern nur 20% der Lagerverlustleistungen im Vergleich zu Kegelrollenlagern auf [WECK-02a, S. 415]. Zur Anpassung an die geforderte Lagersteifigkeit werden diese Schrägkugellager dann in Tandemausführung eingesetzt.

Ausführungen aus Seminararbeiten der HTW Mittweida aus dem Jahre 2005 dienten neben verschiedenen Firmeninformationen [WEIS; SPL; HYPRO; CYTEC] als Anhaltspunkte für die spätere Baukastenentwicklung. In Tabelle 4 sind dabei die Wälzlagerausführungen und in Tabelle 5 die Ausführungen mit hydrostatischen Lagern und mit Magnetlagerung dargestellt.

Gegenstand der Aufgabenstellung war, aus den vorliegenden unabhängigen Spindelvarianten ein einheitliches Baukastensystem zu entwickeln, bei dem sich die einzelnen Baugruppen untereinander kompatibel verbinden lassen.


Tabelle 4: verschiedene Wälzlagerausführungen für Motorspindeln


Vorderes Lager [[Image:]]Hinteres Lager
//\\
\\//
T-O-T-Anordnung
-
[[Image:]]-
Zylinderrollenlager
/ \
\ /
O-Anordnung
\
/
[[Image:]]Einzellager
//
\\
T-Anordnung
\
[[Image:]]/
Einzellager
/\
\/
O-Anordnung
/\
\/
[[Image:]]O-Anordnung
//\
\\/
T-O-Anordnung
--
--
[[Image:]]Zylinderrollenlager
//\
\\/
T-O-Anordnung
/\
\/
O-Anordnung

Tabelle 5: Motorspindelausführungen mit hydrostatischer Lagerung bzw. mit Magnetlager


hydrostatische Lagerung
Magnetlager
[[Image:]]


[[Image:]]

Baukastenentwicklung von Motorspindeln

Allgemeines zur Baukastenentwicklung

Ein Baukastensystem kann nach [KOHL-97] als technisches Gebilde mit einem begrenzten Anwendungsbereich verstanden werden, welches aus einer Anzahl von untereinander verträglichen Bausteinen aufgebaut ist. Diese Bausteine oder Module sind durch definierte Schnittstellen miteinander verbunden.

Dabei gelten auch Formelemente als abstrakte Bausteine. Auch wenn diese abstrakten Bausteine nur geringe Vorteile für die Lagerhaltung besitzen, so sind sie doch für die kombinatorische Vielfalt in der Konstruktion und für eine einheitliche Fertigung von entscheidender Bedeutung. Dieses trifft im Falle der Motorspindel besonders auf die Gestaltung der Hauptspindel zu.

Des Weiteren wird davon ausgegangen, dass Baukästen auch Baureihen, d. h. Größenordnungen ähnlicher Bausteine, enthalten können.

Die Baukastenentwicklung hat möglichst nah an den Markterfordernissen zu erfolgen. So müssen die Produkte mit den größten Absatzchancen bestmöglich durch das Baukastensystem herstellbar sein. Es ist dem Projekt einer Baukastenentwicklung eine hohe Priorität im Unternehmen zuzuteilen, wobei die beteiligten Personen neben den fachlichen, auch die methodischen Fähigkeiten verfügen müssen. Daneben muss das Produkt gemäß Abschnitt 3.3.1 für eine Baukastenentwicklung geeignet sein. Diese Faktoren sind vor dem Beginn einer Entwicklung zu überprüfen.

Ein wichtiger Punkt für die Wirtschaftlichkeit von Baukastenlösungen ist die Berücksichtigung von Kostendegressionen, die durch die Verwendung von Gleichteilen auftritt. Dabei können die Fixkosten von Baugruppen und Bauteilen auf eine höhere Stückzahl aufgeteilt werden. Es können aber auch durch die größeren Stückzahlen andere Fertigungsverfahren wirtschaftlich werden und somit die Stückkosten weiter sinken. Diese Kostenvorteile überwiegen zumeist gegenüber den als nachteilig anzusehenden, komplexeren Bauteilstrukturen die durch Vereinheitlichung der Schnittstellen entstehen. Ein weiterer Nachteil ist der im Allgemeinen größere Materialeinsatz, der durch die nicht auf den einzelnen Anwendungsfall speziell optimierten Bausteine und Bausteinverbindungen eines Systems entsteht.

Im Anschluss an die Ermittlung der Marktanforderungen unterteilen sich die Phasen der Baukastenentwicklung in das Planen des Baukastensystems, das Entwickeln der Bausteine und Baukastenprodukte und dem Entwickeln der Baukastenstruktur. Dabei wird empfohlen [KOHL-97], zuerst die Struktur, die wichtigsten Bausteine und die als bedeutungsvoll abzusehenden Baukastenprodukte zu konzipieren, sowie die Schnittstellen ausreichend genau zu definieren. Die kosten- und zeitintensive Entwurfs- und Ausarbeitungsphase der einzelnen Bausteine ist dann ggf. auch im konkreten Auftragsfall möglich.

Die entstandenen Lösungen werden in der Entwicklungsphase in regelmäßigen Abständen einer Beurteilung, Modifikation und Variation unterzogen. Die Beurteilung umfasst das technische und wirtschaftliche Bewerten und die Einschätzung der Flexibilität eines Baukastensystems. Die Baukastenentwicklung wird dabei erst abgeschlossen, wenn eine insgesamt positive Beurteilung in diesen Punkten vorliegt. Dabei wird auch versucht, durch die Eingrenzung der Variantenanzahl die Wirtschaftlichkeit des Baukastensystems zu erhöhen.

Im Anschluss an die Baukastenentwicklung können aus dem entwickelten Baukastensystem in der Phase der Auftragsabwicklung Produkt- oder Angebotsvarianten (Baukastenprodukte) konfiguriert werden.

Rechnergestütztes Entwickeln von Baukastenstrukturen

Zur Beschreibung der Baukastenstruktur [BÖGE-98; HAAS-95] werden die Nennung der verwendeten Bausteine (Stückliste) und die Aufführung der objekt- und relationsbeschreibenden Eigenschaften gemäß dem Entity-Relationship-Modell benutzt (s. Abbildung 6).

Diese Unterteilung ist besonders bei der informationstechnischen Bearbeitung von Baukastensystemen von Vorteil.


Beispiele: Die Masse der Spindel ist eine objektbeschreibende Eigenschaft des Bausteins „Rotor“ mit dem Merkmal „Masse“ und dem Wert „15 kg“.

Die Eigenschaft, dass der Motorenrotor auf die Welle durch Pressverbindung gefügt ist, kann dargestellt werden, als relationsbeschreibende Eigenschaft „wird gekoppelt mit“ als Beziehung zw. Rotor und Welle mit dem Wert „Kraftschluss“.

Abbildung 6: Mögliche Zuordnung von Attributen zu Objekten


Für die Ordnung von Baukastensystemen gibt es verschiedene mögliche Ordnungsformen (Hierarchien):

  • Die Kombinierende Hierarchie beschreibt einen Hierarchiebaum in dem gezeigt wird, welcher Baustein mit welchem kombiniert werden kann und hilft somit bei der Auffindung von Unverträglichkeit und der Systematisierung sämtlicher Produktvarianten. Eine spätere Anwendung dieser Ordnung im Motorspindelbaukasten ist in Abbildung 15 im Abschnitt 3.4 zu sehen.
  • Die Partitative (teileartige) Hierarchie besagt, welche Bausteine in dem übergeordneten Element enthalten sind. Diese Ordnung enthält damit die Informationen der klassischen Stückliste, lässt sich aber bis auf die Ebene der Punktinformationen datentechnisch erweitern. Dabei zeigt sich folgende absteigende Ordnung: Anlage, Maschine, Baugruppe, Maschinenelement, Bauteil, Teilkörper, Wirkfläche, Konturen und Punkte. Am Beispiel der Motorspindel zeigt sich, dass diese in der Ebene der Baugruppe beginnt, übergeordnet sind ggf. das flexible Fertigungssystem und die Werkzeugmaschine. Untergeordnet sind die Maschinenelemente (Gehäuse, Lagerung, Spindel). Die Spindel umfasst dann die Formelemente und Wirkflächen, die sich über Punkte beschreiben lassen.
  • Die Abstrakte Hierarchie dient zur Begriffsklärung in Systemen. Man kann dafür den Zusatz „ist ein“ benutzen. Beispiel: Die Frässpindel „ist eine“ Spindel. Somit können Erklärungen und Nachweisverfahren für Wellen, auch für Frässpindel übernommen und ergänzt werden.
  • Beschreibende Hierarchien gehen den umgekehrten Weg wie Abstrakte Hierarchien und beschreiben übergeordnete Objekte durch untergeordnete Objekte. So ist z. B. für die Spindelberechnung die Kerbwirkung der einzelnen Formelemente ausschlaggebend.

Des Weiteren ist es für die spätere informationstechnische Aufbereitung wichtig festzustellen, ob es sich bei dem jeweiligen Ordnungssystem um eine Mono- oder eine Polyhierarchie handelt (s. Abbildung 7). Eine Monohierarchie liegt vor, wenn nur ein Element an der Spitze dieser Ordnung steht. Zum Beispiel lassen sich bei der Untersuchung einer konkreten Maschine sämtliche darin enthaltenen Baugruppen und Bauteile dieser unterordnen. Andererseits handelt es sich um eine Polyhierarchie wenn man berücksichtigt, dass die gleichen Baugruppen und Bauteile auch in anderen Baukastenlösungen zum Einsatz kommen können.


Abbildung 7: Hierarchieformen zur Baukastenbeschreibung


In der Entwurfs- und Ausarbeitungsphase sind sowohl die Funktion als auch die Montage zu berücksichtigen. Dies erfordert jedoch unter-schiedliche Sichtweisen auf die Objektstruktur, wie in Abbildung 8 am Beispiel der Funktion „Spindel führen“ gezeigt werden soll.


Abbildung 8: Verschiedene Sichtweisen auf die Funktion die Spindel zu führen




Dieser Sachverhalt ist EDV-technisch und organisatorisch schwierig zu berücksichtigen, zumal im Produktlebenszyklus auch noch andere Sichtweisen zu berücksichtigen sind, so die der Arbeitsplanung, der Lagerhaltung, des Einkaufs, der Kostenrechnung, der Ersatzteileversorgung und des Vertriebs (s. Abbildung 9). Außerdem soll der Fertigungsprozess aus Rohmaterialien und Halbzeugen zum fertigen Produkt abgebildet werden.

Es ist zudem wünschenswert, die komplette Entstehungsgeschichte der Produktentwicklung zu dokumentieren. Außerdem benötigen viele CAD-Systeme zur sicheren Arbeitsweise, z.B. auch bei einem plötzlichen Stromausfall, zusätzlich eine Absicherung durch regelmäßiges Abspeichern der Zwischenergebnisse.

Zusammenfassend ist somit bei sämtlichen Produktentwicklungssystemen eine Abwägung zwischen dem Nutzen der Datenhaltung und der durch die anfallenden Datenmengen entstehenden Aufwendungen vorzunehmen.

[[Image:]]

Abbildung 9: Produktmodell zur Abbildung aufgabenbezogene Sichtweisen [HAAS-95]


Entwicklung des Motorspindelbaukastens

Bei Baukästen von Motorspindeln spricht man von offenen Baukastensystemen mit komplexen Funktionen der einzelnen Bausteine, da die möglichen Baukastenlösungen auf Kundenwunsch noch erweitert werden können. Zudem sind sie strukturgebundene Baukästen, da bei ihnen im Gegensatz zu modular aufgebauten Baukästen die Funktionsbausteine an bestimmten Positionen sitzen.

Bewertung der Motorspindel auf ihre Eignung als Baukastensystem

Über die Wirtschaftlichkeit einer Baukastenentwicklung entscheiden nach [KOHL-97] die:

  • Anzahl und Ähnlichkeit möglicher Produktvarianten
  • Produktionsmenge und -sicherheit
  • vorhandene Entwicklungszeit
  • Kompromissbereitschaft der Kunden
  • Betriebliche Faktoren wie die Struktur und Kapazität der Projektorganisation.


In der nachfolgenden Beurteilung wird auf Basis der o. g. Kriterien die Eignung der Motorspindel als Baukastensystem untersucht. Dabei bleiben die zu prüfenden betrieblichen Vorraussetzungen unberücksichtigt:

  • Anzahl und Ähnlichkeit der Produktvarianten: Als zentrales Bauteil fast aller spanend arbeitenden Werkzeugmaschinen (Drehen, Fräsen, Bohren, Schleifen) ist die Anzahl von rotierenden Hauptantrieben als hoch anzusehen. Die Motorspindeln besitzen aufgrund ihrer aufgeführten Vorteile einen erheblichen Anteil innerhalb dieser Antriebe. Hinsichtlich der Ähnlichkeit kommt es jedoch durch unterschiedliche Leistungsanforderungen zu einer starken Größenstufung der Maschinen, was durch viele Baureihen innerhalb des Baukastensystems abgedeckt werden müsste. Ähnlichkeiten zwischen verschiedenen Motorspindeln sind aufgrund der gleichen Funktionsanordnung vorhanden.Wertung neutral
  • Prognosesicherheit der Kundenerwartung: Auch in Zukunft werden Werkzeugmaschinen Hauptspindeln benötigen. Aufgrund ihrer Vorteile wird der Marktanteil von Motorspindeln im Vergleich zu getrennten Lösungen aus Motor, Übertragungselementen und Spindel eher steigen. Die allgemeinen Konjunkturschwankungen im Maschinenbau bleiben dabei unbeachtet.Wertung positiv
  • Entwicklungszeit wird als ausreichend vorhanden angenommen. Wertung positiv
  • Kosten auftragsspezifischer Baugruppen und Bauteile: Aufgrund der doch relativ geringen Stückzahlen (z.B.: im Vergleich zur Motorenfertigung in der Automobilindustrie) und den aufwendigen Prüfverfahren sind die auftragsspezifischen Planungskosten im Vergleich zu den Gesamtkosten hoch. Somit erscheinen diese hohen Kostenanteile durch die Wiederverwendbarkeit der Fertigungsunterlagen in einem Baukastensystem reduzierbar.Wertung positiv
  • Kompromissbereitschaft der Kundschaft: Bei Verringerung der Lieferzeiten, günstigem Preis, guter Einpassbarkeit in verschiedenen Werkzeugmaschinen und besserer Sicherstellung der Qualität ist durchaus eine Kompromissbereitschaft der Kunden denkbar. Dabei muss sich der Kunde mit auf eine Änderung der Arbeitsweise einstellen. Statt der Konstruktion der Motorspindel im Auftragsfall ohne Baukastensystem würde im besten Fall die Motorspindel nur noch nach seinen Vorgaben konfiguriert werden (s. Abschnitt 3.4). Allerdings ist die Motorspindel so bedeutend für die spätere Fertigungsqualität auf einer Werkzeugmaschine, dass nicht jeder Werkzeugmaschinenhersteller dort sein Mitspracherecht, wie er es bei einer Individuallösung hat, aufgeben wird. Wertung neutral

Als Ergebnis dieser Bewertung erscheint aufgrund der positiven bzw. neutralen Einzelwertungen eine Baukastenentwicklung für Motorspindeln Erfolg versprechend, dabei sollte die Betriebsstruktur allerdings eine gewisse Größe besitzen, um die positiven Effekte eines Baukastensystems voll ausnutzen zu können.

Variationsmöglichkeiten im Baukastensystem

Bei dem hier aufgezeigten Weg handelt es sich um das Aufzeigen einer Methode und weniger um das Aufzeigen einer konkreten Lösung, d.h. für eine praktische Baukastenentwicklung von Motorspindeln ist dieser Weg mit dem realen Firmenwissen und den jeweiligen ins Auge gefassten Produktzielen erneut abzuschreiten.

Wichtigste Bedingung für eine Baukastenentwicklung ist die Systematisierung der Kundenanforderungen und der Lösungsmöglichkeiten. Nur so ist es möglich, den Baukasten auf einen sinnvollen Bereich einzugrenzen und den Kunden über die Vorteile, die Kombinationsmöglichkeiten und die Grenzen des Baukastensystems zu informieren. Somit wurden im vorliegenden Fall vier Variationsmöglichkeiten festgelegt:

  • Das vom Kunden gewünschte Fertigungsverfahren definiert die Schnittstelle zum Prozess und somit die Werkzeug- bzw. Werkstückaufnahme.
  • Die verschiedenen möglichen Bauformen von Werkzeugmaschinen bedingen verschiedene Schnittstellen zwischen Motorspindel und Maschine und somit unterschiedliche Gehäuseformen.
  • Das gewünschte Drehmoment bei einer vorgegebenen Drehzahl bedingt eine entsprechende Motorleistung. Um diese verschiedenen Motorbaugruppen in das Baukastensystem integrieren zu können, wurde sich auf die Variation der Motorlänge beschränkt.
  • Für die mit einer Motorspindel zu erreichenden Fertigungsqualitäten und Drehzahlkennwerte ist die verwendete Lagerungsart und -gestaltung von ausschlaggebender Bedeutung.

Diese Variationsmöglichkeiten werden in den folgenden Abschnitten im Einzelnen erläutert.

Werkzeug- bzw. Werkstückaufnahme

Die in Abschnitt 2.2 bereits aufgeführten Schnittstellen zum Prozess galt es so zu parametrisieren, dass eine gleichmäßige Dimensionierung und Auslastung der Hauptspindel erreicht wird.

  • Somit wurde für Drehspindeln der Spindelkopf DIN 55026-A6 (Bohrungsdurchmesser ca. 80 mm) gewählt.
  • Für die Steilkegelausführung kam der Steilkegel Nr. 50 (Hauptdurchmesser 69.85 mm) gemäß DIN 2080 zum Einsatz.
  • Als Kegel-Hohlschaft-Ausführung (DIN 69893) wurde neben der konkreten HSK-A100-Schnittstelle (Hauptdurchmesser 75 mm) sämtliche Größen-abstufungen parametrisiert.

Gehäusevarianten

Aus den verschiedenen Anwendungsbereichen für Motorspindeln wurden folgende Gehäusevarianten umgesetzt:

  • die am Gestell oder einem verfahrbaren Bock montierte Drehspindel
  • die Ausführung in einer Pinole bzw. als auswechselbare Spindeleinheit
  • die Ausführung in einer 5-Achs-Fräsmaschine

Für die Ausführungen der zusätzlichen Schwenkbewegungen in einer 5-Achs-Maschine sind mögliche Ausführungen in Tabelle 6 dargestellt, umgesetzt wurde dabei für das Baukastensystem die gezeigte Gabelausführung.


[[Image:]]
[[Image:]]
[[Image:]]
Universalausführung
Gabelausführung
Orthogonalausführung

Tabelle 6: Mögliche Ausführungsformen für Schwenkbewegungen [CYTEC]

Variation des Motors

Im Rahmen der Betrachtung wurde sich für die Verwendung der Einbaumotoren der Baureihe 1PH2 der Firma Siemens [SIEM] entschieden. Dabei handelt es sich um Asynchronmotoren mit Hohlwellen-Käfigläufer. Diese sind nahezu wartungsfrei und besitzen eine kompakte Bauform mit relativ hoher Leistungsdichte. Dadurch empfiehlt sich die Übernahme der dortigen 4 Durchmesserabstufungen auf das gesamte Baukastensystem. Diese Motoren haben einen Wellendurchmesser von 67, 82, 122 bzw. 165 mm und Leistungen (S1) von 7,5 bis 39,3 kW. Für jeden dieser Durchmessergrößen gibt es 2 bis 4 verschiedene Motorenlängen. Mit diesem Leistungsbereich ist dann auch der Großteil des Werkzeugmaschinenmarktes abdeckbar.

Da man über verschiedene Motorlängen beim Einsatz gleicher Lagerbaugruppen unterschiedliche Leistungsbereiche bedienen kann, empfiehlt sich für ein Baukastensystem besonders die Längenvariation. So ist mit einem einheitlichen Wellendurchmesser von 122 mm ein Leistungsbereich von 11,8 bis 23,6 kW abdeckbar. Die Auswahl wurde dabei auf die Ausführungen 182-6WC41 (11,8kW) und 186-6WC41 (18,3 kW) gemäß Abbildung 10 eingegrenzt.

[[Image:|thumb|{| class="prettytable" | l1=320mm =33 | l1=540mm =33 |}]]Abbildung 10: Variation der Spindelleistung über die Motorlänge

Varianten der Lagerung

Eine Möglichkeit zur Auswahl der Lagerart einer Motorspindel ist die Nutzung der Abbildung 12 nach den im jeweiligen Fall vorliegenden Prioritäten der einzelnen Funktionen.

Als andere Charakterisierungsmöglichkeit (s. Abbildung 11) wurden hier der Drehzahlkennwert und die erzielbare Genauigkeit der Motorspindel für verschiedene Lagerstellenlösungen aufgetragen. Die möglichen Grenzen der Drehzahlkennwerte wurden aus der einschlägigen Literatur [KAMP-90; WECK2-02; HIRS-00] quantitativ entnommen. Die Werte für die Genauigkeit konnten nur qualitativ erfasst werden. Grund dafür ist, dass die erreichbare Fertigungsgenauigkeit neben den Eigenschaften der Spindellagerung auch stark vom Fertigungsprozess, dem Werkzeug und dem verwendeten Werkstoff abhängig ist. Daneben wirken sich natürlich auch noch weitere, von der Motorspindel unabhängige Einflüsse auf die Fertigungsqualität aus (z.B. Gestellsteifigkeit und -dämpfung). Die erzielbare Genauigkeit setzt sich dabei aus den von den Lagern beeinflussten Punkten der statischen Steifigkeit, der Laufgenauigkeit, der Dämpfung und der Schwingungsanregung zusammen.


Abbildung 11: Portfolioanalyse zur
Systematisierung möglicher Lagervarianten
[[Image:]]


Abbildung 12: Qualitativer Vergleich der Lagerarten [DUBB-01]

Eine Betrachtung gemäß dem obigen Diagramm erschien trotz dieser Nichtquantifizierbarkeit sinnvoll, um eine gewisse Grundsystematisierung zu erhalten. Dabei besteht auch ein Zusammenhang zwischen der darin angegebenen Genauigkeit und der für die Herstellung der Spindel zur Verfügung stehenden finanziellen Mittel. Allerdings sei auch erwähnt, dass auch durch Anpassung der einzelnen Lagerprinzipien der Einsatzbereich in einem weiten Bereich variiert werden kann. So können z. B. durch die Anwendung der Tandemlagerung die Lagersteifigkeit und damit die Fertigungsgenauigkeit auf einfache Weise erhöht werden.

Die Benutzung der Drehzahlkennwerte, also dem Produkt aus Drehzahl und Lagerdurchmesser, ermöglichte eine weitgehende Größenunabhängigkeit des obigen Diagramms. Nach der Systematisierung der Lösungsmöglichkeiten erfolgt für die Baukastenentwicklung eine Eingrenzung auf die am ehesten Erfolg versprechenden Lösungsprinzipien.

Dafür dienen die in Abbildung 11 eingezeichneten Quantitäten der Marktwünsche. Diese wurden durch folgende Überlegungen ermittelt. Generell dürften Lösungen mit einem zu geringen Drehzahlkennwert gerade für Motorspindeln nicht die notwendige Wirtschaftlichkeit erreichen. Der wirtschaftliche Einsatz von Lösungen mit sehr hohen Drehzahlkennwerten ist auch durch technische Grenzen der Schneidwerkzeuge begrenzt. Lösungen mit einer zu geringen Genauigkeit dürften an einem zu unflexiblem Fertigungseinsatz scheitern. Andererseits macht es auch wenig Sinn, eine höchstgenaue Spindelbewegung zu erzielen, wenn die Prozessungenauigkeiten (z.B. die Rillenbildung beim Drehen) diesen Einfluss um ein Vielfaches übersteigen. Außerdem wird die notwendige Fertigungsgenauigkeit durch das zu fertigende Werkstück bestimmt, so dass nur für einen geringen Teil der Fertigungsaufgaben eine Hochpräzisionsbearbeitung notwendig ist.

Somit dürfte sich in vielen Fällen eine Eingrenzung auf die im Mittelfeld des obigen Diagramms liegenden Wälzlager ergeben. Für eine möglichst anschauliche, spätere Visualisierung der verschiedenen Baukastenlösungen in der Virtuellen Realität wurde diese Eingrenzung hier jedoch nicht vorgenommen. Es wurden für die VR-Visualisierung zusätzlich zu den verschiedenen Wälzlagerlösungen auch die Lagervarianten mit hydrostatischer Lagerung und elektromagnetischer Lagerung genutzt. Tabelle 7 zeigt die in den entstandenen Baukasten integrierten Lagervarianten.

Tabelle 7: Lagervarianten des Baukastensystems


vordere Lagerstelle
hintere Lagerstelle
Wälzlagerausführung I
[[Image:]]
Schrägkugellager in
Tandem-O-Tandem Anordnung
[[Image:]]
Zylinderrollenlager
(zweireihig)
Wälzlagerausführung II
[[Image:]]
Schrägkugellager in O-Anordnung
[[Image:]]
Zylinderrollenlager als Loslager
Magnetlagerung
[[Image:]]
[[Image:]]
Hydrostatische Lagerung
[[Image:]]
[[Image:]]

Mit dieser Baukastenaufteilung ist ein Großteil des Anwendungsbereiches von Motorspindeln abzudecken. Aufgrund der nur grob unterteilten Lösungsvarianten, sind die Bausteine in wirtschaftlichen Stückzahlen zu produzieren, die Zukaufteile unter Nutzung von Mengenrabatten zu beschaffen und bei geringen Lagerhaltungskosten zu verwalten. Andererseits ist das System als offenes Baukastensystem angelegt und somit auch nach Kundenwunsch erweiterbar. Die Funktionsbausteine der dabei aufgezeigten Varianten sind relativ unabhängig voneinander kombinierbar.

Dabei ist im speziellen Anwendungsfall über eine Unverträglichkeitsliste zu prüfen, ob die spezielle Baukastenlösung sinnvoll und funktionsfähig ist. Beispielsweise dürften sich bei einer Kombination aus hydrostatischer Lagerung und einer 5-Achs-Gehäuseausführung Probleme mit der kontrollierten Schmierstoffführung in vertikaler Position ergeben. Ein weiteres Beispiel ist, dass die Verwendung von unterschiedlichen Lösungsprinzipien für die vordere und die hintere Lagerstelle nur in den seltensten Fällen wirtschaftlich sinnvoll ist.

Auftragsabwicklung bei entwickelten Baukästen

Die Abbildung 13 zeigt den Ablauf der Planung bei einem entwickelten Baukasten über die Kundenanfrage, die Erstellung der Anforderungsliste bis hin zur fertigen Produktdokumentation für die Fertigung. Dabei kommt es nur dann zu einer aufwendigen Neukonstruktion von Bauteilen, wenn mit der Konfiguration der Baukastenlösung die Kundenanforderungen nicht erfüllt werden können.

Der Ablauf einer Motorspindelentwicklung ohne Baukastensystem, wie in Abbildung 14 verkürzt dargestellt, unterscheidet sich davon grundlegend. Es erfolgt eine schrittweise Auslegung der Bauteile von dem Spannsystem, über die Spindelform bis hin zur Auswahl der Lagerart und Lagerdimensionierung. Die größten Aufwendungen liegen dabei in der detaillierten Ausarbeitung und der Phase der Arbeitsvorbereitung.


Abbildung 13: Auftragsabwicklung bei einem entwickelten offenen Baukastensystem

Abbildung 14: Auftragsabwicklung ohne vorhandenes Baukastensystem

Vorraussetzungen für eine effiziente Baukastenanwendung sind ausgearbeitete Produktinformationen und Konfigurationsübersichten.

Dazu kann auch eine Darstellung der Kombinierende Hierarchie (s. Kapitel 3.2) des Baukastens gehören, wie sie in Abbildung 15 dargestellt ist. Anhand dieser Übersicht kann systematisch jede mögliche Baukastenlösung konfiguriert werden.


Abbildung 15: Kombinatorische Aufschlüsselung des Baukastens

Umsetzung des Baukastensystems Motorspindel in die Virtuellen Realität

Einführung in die Virtuelle Realität

Virtuelle Realität (VR) bezeichnet eine neue Mensch-Maschine-Schnittstelle mit dem Wunsch nach höherer Ergonomie und Effizienz der Ingenieurstätigkeit. Aufgrund der Dominanz der visuellen Eindrücke bei der Informationsaufnahme des Menschen, geht es dabei hauptsächlich um eine in der optischen Qualität, der Realität möglichst nahe kommenden Darstellung von künstlich geschaffenen Welten und der Interaktion in diesen Welten. Im Rahmen dieser Arbeit handelt es sich bei diesen „Welten“ um technische Gebilde, die sich zum Teil noch in der Planungsphase befinden. Die Darstellungen ihrer Funktionen und Eigenschaften umfasst neben dem Hauptschwerpunkt Geometrie, den Kraftfluss, das Spannungsverhalten und das dynamische oder kinematische Verhalten von Bauteilen. Aber auch die Funktionen von Baukastenelementen und die Struktur von Baukastensystemen können in einem VR-System analysiert werden.

Die Verbesserungen der Effizienz im Vergleich zu heute üblichen Computerarbeitsplätzen soll durch die Aufhebungen der räumlichen Begrenztheit von heutzutage üblichen Monitoren erreicht werden, da diese nur einen Bruchteil des Sichtfeldes des Benutzers ausnutzen und auch nicht den Kopfbewegungen des Nutzers folgen.

Ein weiterer wichtiger Faktor für höhere Effizienz und Ergonomie ist die Erhöhung der räumlichen Wahrnehmungsfähigkeit des Benutzers durch stereoskopisches Sehen. Dabei werden vom Computersystem zwei getrennte Bilder mit unterschiedlichem Blickwinkel berechnet und diese dem jeweiligen Auge des Betrachters zugeführt.

Systeme für die Virtuelle Realität

Dabei beziehen sich die späteren Betrachtungen auf die folgenden VR-Systeme, da diese im Rahmen der Arbeit zur Verfügung standen:

  • Die Darstellung kann über Projektoren auf eine Wand (ca. 5m x 3m) erfolgen; dieses System nennt sich Powerwall.
  • Eine andere Variante ist die L-Bench, dabei befinden sich vor dem Benutzer in Tischhöhe eine horizontale Projektionsebene und dahinter eine senkrechte Projektionswand.
  • Die aufwendigste Ausführung wird als CAVE bezeichnet, dabei sind um den Benutzer herum bis zu 6 Projektionsflächen angebracht und der Benutzer befindet sich somit im inneren eines Würfels, diese Ausführung erzeugt die größte Immersion und dient damit z. B. für Designstudien von Fahrzeuginnenräumen, Planung von ganzen Maschinensystemen und psychologischen Studien. Die Aufwendung für die CAVE sind jedoch zu hoch und der Bauteilgröße der hier behandelten Motorspindeln nicht angemessen.

Diese Systeme ermöglichen durch ihre Größe die gleichzeitige gemeinsame Nutzung der virtuellen Welt und eine direkte Kommunikation für eine ganze Gruppe der am Produktentwicklungsprozess Beteiligten.

[[Image:]]Eine Platz sparende Alternative zu den o. g. Systemen ist eine direkte Projektion des Computerbildes in das Auge des Benutzers über einen tragbaren Helm oder eine Brille. Eine weitere Variante von Systemen der VR-Technologie ist die Umlenkung des Lichtes eines Monitors über kleine Prismen, dabei wird jede zweite Spalte von Monitorpixeln in das linke Auge und die dazwischen liegenden Pixel in das rechte Auge projiziert. Die Erfassung der Benutzerposition erfolgt über ein Videosystem mittels eines Bildverarbeitungsverfahrens. Über Motoren wird die Prismenposition entsprechend nachkorrigiert. [SEER]

VRML (Virtual Reality Modeling Language)

Abbildung 16: VRML-Szene-Graph in [WHIT]VRML ist eine auch für den Menschen lesbare Beschreibungssprache für 3D Welten incl. derer Geometrie, Beleuchtungssituation und einer Vielzahl von Animations- und Interaktionsmöglichkeiten. Aufgrund ihrer langjährigen Standardisierung, ihrer Nutzung als Austauschformat für Geometriedaten und für Internetanwendungen besitzt VRML eine dominierende Rolle bei der Beschreibung von VR-Welten.

Dabei wird durchaus auch der Informationsverlust bei der Formatumwandlung in das nur die Oberfläche beschreibende VRML-Format genutzt, um so beim Datenaustausch mit anderen Firmen nicht auch Firmen- und Produktionsgeheimnisse mit preiszugeben.

Die 3D-Welt wird in einem so genannten Szene-Graphen gespeichert, dabei sind in einer Wurzelstruktur verschiedene Knoten hinterlegt.

Bei den Knoten handelt es sich u. a. um:

  • die Geometriebeschreibung. Dazu gehören Geometriegrundkörper wie Kugeln, Quader, Zylinder und Kegel. Aber auch das allgemeine IndexedFaceSet, wobei es sich um eine Auflistung von Punktkoordinaten und den darauf basierenden, die Oberfläche beschreibenden Polygonen handelt. In einem so genannten Shape werden diese Geometriedaten mit Oberflächen-informationen verbunden. Somit sind neben Materialfarbe, auch die Farbe und Größe des Glanzpunktes beschreibbar. Allerdings muss bis auf Ausnahmen auf die sonst selbst in einigen CAD-Programmen heutzutage üblichen reflektiven Texturen (Environment Mapping) zur Darstellung von metallischen Oberflächen verzichtet werden.
  • Transform-Knoten dienen zur Skalierung, Rotation oder Transformation der Geometrie.
  • Verschiedene Lichtquellen dienen zur Beleuchtung der Szene
  • Sensoren reagieren auf Ereignisse wie Benutzereingaben oder Zeitevents.
  • Der Scriptknoten ist für die clientseitigen Programmierung besonders wichtig. Er behandelt gemäß einer objektorientierten Programmierung Eingangsevents mit den Programmiersprachen JavaScript und Java zu den Ausgangsevents. Als Event wird dabei ein Ereignis mit einem Zeitstempel verstanden. Ein Event kann dabei Einzelwerte oder ganze Felder von Werten mit übergeben. Die Werte können dabei die Typen Integer, Float, Bool, String und Time aber auch spezifischere Typen wie Color, Vector, Image, Rotation und Knoten annehmen. Über Route sind dann die Ein- und Ausgänge der verschiedenen Objekte miteinander verknüpft.
  • Protos dienen zum Zusammenfassen von mehreren Grundknoten zu Objekten mit neuen Eigenschaften und damit zur Modularisierung.

In dem VR-System oder dem VRML-Plugin wird dann aus den einzelnen Objektbeschreibungen die Szene mit Geometrie, Licht und Kamera zusammengebaut. Dabei werden die lokalen Koordinatensysteme in ein einheitliches System überführt und anschließend werden zur Erhöhung der Performance nicht sichtbare Objektteile aus der Szene entfernt. Daraufhin erfolgt eine Projektion der in Polygone zerlegten Oberflächen auf die Kameraperspektive.

Bei modernen VRML-Anwendungen [Blax] und einer T&L-Grafikkartenunterstützung (Transform und Lightning) erfolgt diese Transformation komplett auf der Grafikkarte, was die Performance extrem steigert und sowohl CPU als auch Grafikbus entlastet. Danach erfolgen die Beleuchtungsberechnung (nach einem lokalen Beleuchtungsmodell) und das Shading. Beim Shading wird häufig das relativ einfache Gouraud-Shading eingesetzt, wobei die Objekte in Dreiecke zerlegt und die Farbwerte zwischen den Eckpunkten interpoliert werden. Dank OpenGL- bzw. DirectX-Unterstützung der Grafikkarten erfolgt dieses in der Regel auf der Grafikkarte.

Unterscheidung der Programmierarten zur Beschreibung technischer Systeme für die VR

Aufgrund der vorgenannten Funktionalitäten von VRML [WEB3D], bot es sich an, die Darstellung der Motorspindelbaustruktur und der Baukastenstruktur in der VRML eigenen Programmierung, der so genannten clientseitigen Programmierung vorzunehmen.

Aufgrund der in Tabelle 8 aufgeführten Nachteile dieser Programmierung erwies es sich im Anschluss daran jedoch als sinnvoll, auch die Möglichkeiten einer serverseitigen Programmierung zu nutzen. Dabei werden Programme auf einem zentralen Web-Server ausgeführt, welche eine VRML-Datei erzeugen. Diese Programme wurden in der Programmiersprache PHP geschrieben und ermöglichten eine Verbindung zu einer MySQL- Datenbank.

Die clientseitige Programmierung ist somit Gegenstand von Abschnitt 4.2, während die serverseitige Programmierung in Abschnitt 4.3 abgehandelt wird. Für eine Gegenüberstellung sei auf Tabelle 8 verwiesen.


Clientseitige Programmierung
Serverseitige Programmierung
Stärken:* einfache Integration in VRML-Datein
  • Programmierung für Echtzeitinteraktion und –animation.
  • Ereignisgesteuerte Programmierung zur Echtzeit-Simulation technischer Systeme .


Stärken:* Multiuserfähige Datenbankanbindung
  • Programmierung in einer kontrollierbaren einheitlichen Serverumgebung
  • Programmausführung kann bei vielen Web-Anfragen auf mehrere Rechner verteilt werden.


Schwächen:* keine Abspeicherung der Interaktionsergebnisse vorgesehen, starke Abhängigkeit von der verwendeten Umgebung (trotz ISO-Standardisierung)
  • Begrenztheit der Komplexität der VR-Welten


Schwächen:
  • Zeitverzögerung bei der Interaktion
  • erhöhter Netzwerkverkehr



Programmiersprache:

Java-Script bzw. ECMAScript

Dient für die objektorientierte Animation, Interaktion und Simulation innerhalb von VRML.

Programmiersprache:

PHP

Durch PHP können komplexe VRML-Dateien in Abhängigkeit von DB-Einträgen generierten werden.

Webserver: * Speicherung der PHP-Skripte und der VRML-Dateien
  • Datenbankanbindung


Tabelle 8: Gegenüberstellung von clientseitiger und serverseitiger Programmierung


Clientseitige Programmierung

Clientseitige Programmierung zur Darstellung des Motorspindelbaukastens

Die clientseitige Programmierung innerhalb von VRML dient hierbei zur Darstellung der Baukastenstruktur. Um die in der Produktplanung notwendige Flexibilität zu erreichen, sollte dabei auf den sonst üblichen Export der Geometriedaten aus Modellierungsprogrammen (3Dmax u.a.) bzw. aus CAD-Systemen (CATIA, Inventor, PRO/Engineer u.a.) verzichtet werden. Bei diesen Programmschnittstellen werden aus den 3D-Modellen VRML-Dateien erzeugt, die sich aufgrund der großen Datenmengen nur schwer nachträglich an die Bedürfnisse der VR-Umgebung anpassen lassen, zudem sind nur begrenzte Interaktionsmöglichkeiten realisierbar. Ein weiterer Nachteil dieser Schnittstellen ist, dass erst ein komplettes 3D-Modell angelegt werden muss, um eine VRML-Ausgabe erzeugen zu können. Diese Vorgehensweise zeigt sich jedoch in der Konzeptphase eines Projektes, in der auch mit häufig zu überarbeitenden Skizzen und abstrakten Symbolen gearbeitet wird, als zu unflexibel.

Da bei der behandelten Motorspindel (s. Abbildung 17) die Rotationssymmetrie eine dominierende Rolle spielt, wurde für diese Anwendung ein spezieller Proto (siehe Abschnitt 4.1.2) geschrieben. Dieser Proto entwickelt aus der 2D Kontur die 3D-Oberfläche des Objektes und arbeitet dabei mit dem zugrunde liegenden VRML-Grundelement „Extrusion“ und einer skriptgesteuerten Extrusionsbahn. Als Rotationsachse dient die x-Achse, der Körper kann aber durch anschließende Transform-Befehle in jede beliebige Position gebracht werden.

Da sich die Baukastenentwicklung im Rahmen der Grobplanung bewegt, wird es als zulässig angesehen, dass Formelemente, welche von der Rotationssymmetrie abweichen (wie z.B. Befestigungsbohrungen), nicht dargestellt werden. Daneben wurde für einen besseren Einblick in die Konstruktion ein Proto geschrieben bei dem nur eine Dreiviertelrotation stattfindet. Ein weiteres Proto besitzt eine Methode um besonders die Objektkanten zu betonen. Dieses führt zu einer subjektiv besseren Aufnahmefähigkeit der Objektstruktur. (Oftmals wird diese Zeichnungsart als „Comic-Shader“ bezeichnet.)

[[Image:]]

Abbildung 17: Zusammengebaute Spindel (siehe Anhang: Spindel_rot2com.wrl)

Als weiteres sollte auch der gesamte Baukasten für Motorspindeln für eine spätere Bewertung und Optimierung in der VR visualisiert werden (s. Abbildung 19).

Für die Benutzerinteraktion in der Baukastenstruktur wurde ein Proto namens „Block“ angelegt. Dieses enthält neben einem symbolischen Objektquader, der Objektbeschriftung auch die Sensoren, um das Objekt in alle Richtungen des Raumes bewegen zu können. Dieses Block-Proto repräsentiert somit die objektbeschreibenden Eigenschaften eines jeden Bausteins im Baukastensystem.

Die relationsbeschreibenden Eigenschaften und somit die Verbindungseigenschaften zwischen den Objekten werden durch das „Verbindung“s-Proto dargestellt.

Die clientseitige Programmierung ist bestens geeignet für solch eine Art der Echtzeitinteraktion. Allerdings erwies sich das hierarchische Datenmodell [HASS-95] innerhalb von VRML als zu unflexibel um die verschiedenen Sichtweise des Produktmodells (gemäß Abschnitt 3.2 Abbildung 8) umsetzen zu können. Es wurde deshalb eine einfache Umsetzung von einem relationalen Datenmodell in die hierarchische VRML-Struktur vorgenommen (s. Anhang Net_spindel2.wrl). Dieser skriptgesteuerte Ablauf ist in Abbildung 18 dargestellt.


Durch ein Skript werden alle Verknüpfungen zwischen Objekten und Verbindungen hergestellt, dieses wird (als initialize-Funktion) direkt nach dem Laden der VR-Welt ausgeführt. Dabei ist in einer Art Tabellenstruktur nur hinterlegt welche Objekte miteinander verbunden sind. Das Skript positioniert die Objekte danach automatisch. Die Event-Weitergabe erfolgt dabei in der Bauteilhierarchie von oben nach unten.


Abbildung 18: Umwandlung eines relationale Datenmodells in die hierarchische VRML-Struktur


[[Image:]]

Abbildung 19: Aufteilung des Baukastensystems (siehe Anhang: Net_spindel2.wrl)

Lösungsansätze zur Simulation mechanischer Eigenschaften von Motorspindeln

Ziel dieses Teils der Arbeit war es, die Möglichkeiten einer intuitiveren, sinnlicheren und interaktiveren Berechnung der mechanischen Eigenschaften von Maschinenbaustrukturen für spätere VR-Anwendungen zu untersuchen, als sie von herkömmlichen FEM-Programmen bekannt sind.

Diese Möglichkeiten wurden an einem vereinfachten Modell einer Hauptspindel untersucht. Das Modell arbeitet mit der Theorie der Biegelinie und berücksichtigt dabei die elastische Lagerung der Spindel. Die Untersuchung wurde auf die radiale Richtung beschränkt, da sich in axialer Richtung, aufgrund des dominierenden Einflusses der Lagernachgiebigkeit gegenüber der Nachgiebigkeit der Welle, das Spindelverhalten sich einfach aus den Lagereigenschaften ergibt.

Das Verfahren soll an dieser Stelle nur kurz skizziert werden, für detaillierte Informationen sei auf [DRES-04] verwiesen.

Zum Verständnis des Verhaltens bei radialer Krafteinwirkung wurde im Rahmen der Arbeit die Steifigkeit der Spindel als einfacher Biegebalken mit veränderlichem Querschnitt in einer Steifigkeitsmatrix festgehalten. Die Lagersteifigkeiten wurden durch einfache Addition auf der Matrizen-Diagonalen ergänzt. Die Steifigkeitsmatrix C der Gesamtspindel ergab sich durch Zusammensetzen der zugrunde liegenden 4x4-Elementarmatrizen der vorliegenden 8 Elementar-Biegebalken.

Als generalisierte Koordinaten wurden für jeden der 9 Punkte sowohl die radiale Abweichung von der Nullachse, als auch die Verdrehung der Stabachse zur Nullachse verwendet. Der Kraftangriffspunkt ist dabei der Kontaktpunkt zwischen Werkstück und Werkzeug.

Danach war es in der verwendeten Tabellenkalkulation möglich, durch Matrizeninvertierung von C die Nachgiebigkeitsmatrix D zu ermitteln.

[[Image:]](1)

Durch einfache Multiplikation der Nachgiebigkeitsmatrix mit dem Belastungsvektor p ergab sich der Verformungsvektor q. (siehe (1)) Dieses Verfahren wurde an einem einfachen Modell verifiziert und anschließend auf das Modell der Motorspindel übertragen.


Für das dynamische Verhalten der Spindel diente in Excel ein kleines Makro. Dabei wurde die momentane Spindel- und Lagerverformung q multipliziert mit der Steifigkeitsmatrix C. Die Differenz aus dem Cq zur äußeren Belastung p ergab den an den Punkten wirksame Beschleunigungskraftvektor f. Diese Beschleunigungskraft geteilt durch die Trägheitswerte (Masse und Trägheitsmoment) der Punkte ergab den generalisierte Beschleunigungsvektor [[Image:]] (siehe (2)). Die Beschleunigung wurde nun zweifach über einem kurzen Zeitintervall [[Image:]] numerisch integriert (siehe (3)), somit ergab sich die neue Position der Spindel q. Mit diesen Werten wurde ein neuer Rechendurchlauf gestartet.

[[Image:]]

Abbildung 20: Möglichkeit zur Untersuchung der dynamischen Eigenschaften von Spindeln

In Abbildung 20 ist die Steifigkeitsmatrix C gelb markiert. Der Kraftangriffspunkt ist dabei auf der blau gezeichneten Biegelinie auf der rechten Seite mit einem Kraftpfeil gekennzeichnet. Die Spindel wurde mit 3 Lagern simuliert.

Interessant ist, dass diese Methode ohne mathematisch aufwendige Matrizeninvertierung oder Nullstellensuche wie bei der Modalanalyse auskommt, und somit auch für eine Skript-Implementierung in einer VRML-Datei geeignet scheint. Damit könnte eine intuitive Schwingungsanalyse von Bauteilen ermöglicht werden. Denkbar ist dabei eine VR-Anwendung in der der Benutzer ein Objekt virtuell anschlägt und dann dessen Eigenschwingung auch durch taktielle Ausgabegeräte (z.B.: Phantom) erfahren kann. Weiterhin könnte aus den Bauteilschwingungen die Anregung der Luftpakete an allen Oberflächenteilen ermittelt werden, um daraus ein akustisches Signal für den Benutzer zu erzeugen. Über eine Sinuserregerfunktion mit langsam ansteigender Frequenz und einem virtuellen Messaufnehmer für die Verformung ließen sich sogar die Eigenfrequenzen und die Verstärkungsfunktion ermitteln.

[[Image:]] (2)

[[Image:]](3)

Es zeigten sich aber folgende Nachteile: Bei der verwendeten Programmierung als Excel-Skript wurde eine Rechengeschwindigkeit von 20 Programmdurchläufen pro Sekunde erreicht, somit konnte das dynamische System in dieser Programmierweise nur stark verlangsamt wiedergegeben werden oder es zeigten sich Instabilitäten in der Simulation. Versuchskripte mit JavaScript-Programmen in VRML zeigten, dass sich dabei die gleiche Größenordnung von Intervallzeiten einstellen dürfte. Nachteilig erscheint auch, dass die Eigenformen höherer Ordnung optisch von den Eigenformen niedrigere Ordnung überlagern werden, da bei diesen im Allgemeinen höhere Amplituden-Ausschläge auftreten. Zudem ist diese Simulationsart anfällig für den Einfluss von numerischen Fehlern und den Fehlern aus der zeitlichen Diskretisierung.

Somit empfiehlt sich für quantitative Untersuchungen schwingender Systeme weiterhin die Verwendung von kommerziellen FEM-Programmen, da deren Berechnungsverfahren im Allgemeinen verifiziert sind und außerdem die Modalanalyse, die für die Entwicklung wichtigen Kennwerte wie Eigenformen und Eigenfrequenzen schnell liefert.

Das aufgezeigte Verfahren eignet sich jedoch durchaus für die Simulationen von Maschinenbaugruppen bei denen die Schwingungen vernachlässigbar sind oder mit niedriger Frequenz ablaufen. So ist es zum Beispiel möglich, an einer Werkzeugmaschinen-Vorschubachse die Beschleunigung [[Image:]] aus den Faktoren von Motormoment, der Gewindespindelübersetzung und den zu beschleunigenden Massen zu ermitteln und dann den Bewegungsablauf zu simulieren.

Möglichkeiten zur Echtzeitinteraktion mit Strukturen des Maschinenbaus

Aufgrund der Rotationssymmetrie der Hauptspindel eignen sich deren rotativen Bewegungsabläufe nur bedingt für eine Darstellung in der VR. Aus diesem Grund wird in diesem Kapitel auf die der Motorspindel übergeordnete Baugruppenebene der Werkzeugmaschinen eingegangen.

Die clientseitige Programmierung der Virtuellen Realität zeigt ihre Stärken bei der Echtzeitinteraktion mit dem Benutzer. Neben der freien Bewegung von Bauteilen, zum Beispiel in der Phase der Montageplanung, ist diese Interaktion besonders bei komplexeren Mechanismen von Interesse.

Aufgrund der vorhandenen hierarchischen Ordnung der Transform-Knoten eignet sich VRML sehr gut für die Bewegungsanalyse an Werkzeugmaschinen mit seriellem kinematischem Aufbau.


[[Image:]] [[Image:]]

Abbildung 21: Struktur der Kinematik an einem Modell einer Fräsmaschine in Kreuzbettbauweise.


In Abbildung 21 ist eine modellierte Kreuzbettfräsmaschine mit dazugehöriger Bewegungshierarchie dargestellt, die kinematische Struktur geht dabei vom Maschinenbett über den Tisch und den Drehteller zum Werkstück bzw. vom Maschinenbett über den Ständer, den Support und die Schwenkachsen zum Werkzeug (5-Achs-Frässpindel).

Sämtliche Maschinenachsen sind über die vor der Maschine befindlichen Eingabemöglichkeiten zu bewegen, dabei können auch die Trägheiten der Maschinenelemente und die Eigenschaften der elektrischen Antriebe (in Anlehnung an Abschnitt 4.2.2 Gleichung (3)) simuliert werden.

[[Image:]]

Abbildung 22: Bewegungsuntersuchung an einer Parallelkinematik


Als weiteres Beispiel sei neben den seriellen Kinematiken, die Interaktion mit einem parallelkinematischen Tripod aufgezeigt (s. Abbildung 22). Bei diesem Tripod wird im realen System eine Arbeitsplattform mittels dreier parallel arbeitender Hydraulikzylinder in einer Ebene bewegt.

Deren VR-Umsetzung benötigte jedoch im Vergleich zu den aufgezeigten seriellen Maschinen eine intensive Nutzung von integrierten Skripten. Die Hydraulikzylinder sind in einem eigenen Proto mit ihrem jeweiligen Anfangs- und Endpunkt programmiert. Die Koordinaten der Endpunkte ergeben sich aus der jeweiligen Position der Arbeitsplattform durch einfache Punkttransformation, während die Anfangspunkte fest in ihren Gestellpunkten liegen.

Somit ist es leicht möglich, verschiedene Maschinenkonzepte des Werkzeugmaschinenbaus schon in einer frühen Planungsphase zu visualisieren, und auf dieser Basis zu diskutieren und zu optimieren.

Serverseitige Programmierung des Motorspindelbaukastens

Ziel der serverseitigen Programmierung war der Ausgleich der folgenden Hauptnachteile der clientseitigen Programmierweise:

  • Keine dauerhafte Speichermöglichkeit der Interaktionsergebnisse
  • Unterschiede in der Auslegung der VRML-Spezifikationen führen in den unterschiedlichen VRML-Plugins oder VR-Umgebungen zu unterschiedlichen Erscheinungsbildern oder sogar zu nicht funktionsfähigen Skripten.
  • Begrenzung der Erweiterbarkeit. Da sämtliche Informationen in VRML-Dateien vorliegen, ist es nur begrenzt möglich Programmierung und Objektdaten zu trennen. Somit wächst mit steigender Komplexität der Aufwand für Programmierung und Fehlersuche überproportional.
  • Abgrenzung zu nichtgeometrischen Themengebieten. Aufgrund der Ablage der Informationen in VRML-Dateien erscheint es nicht sinnvoll, die in Abschnitt 3.2 bereits angesprochenen verschiedenen Sichtweisen auf das Produktmodell umzusetzen.
  • Das zeitgleiche, weltweit oder regional verteilte Arbeiten an der Lösungsfindung und Ausarbeitung erscheint nicht möglich.


Ablauf eines serverseitig programmierten VRML-Szenenaufbaus

Die serverseitige Programmierung wird dadurch ermöglicht, dass es sich bei VRML um eine gut dokumentiert, standardisierte und auch für den Menschen lesbare Skriptsprache handelt. Somit wird serverseitig eine ganz normale Textdatei ausgegeben, welche dann aber durch ihren Header, also ihre Anfangszeile „#VRML V2.0 utf8“ als VRML erkannt und vom Clienten interpretiert wird.

Dabei erfolgt der in Abbildung 23 dargestellte und im Folgenden beschriebene Informationsfluss.


Abbildung 23: Struktur der serverseitigen Programmierung


  1. Der Nutzer ruft am Clienten mit seinem Browser eine PHP-Seite vom Server auf. Gegebenenfalls kann er direkt (mit der Get-Methode), mittels der Adressleiste des Browsers, dem Programm Variablen übergeben oder die Variablen werden indirekt über vorgelagerte Webformulare und für den Benutzer nicht sichtbar (mit Post-Methode) an den Server übergeben.
  2. Durch die angeforderte Dateiendung .php erkennt der Server, dass die Datei als PHP interpretiert werden soll. Durch einfache Einstellung im Server (Apache) könnten auch .wrl –Dateien oder andere als PHP interpretiert werden.
  3. In der PHP –Datei werden alle Zeichen zwischen „<?php“ und „?>“ als PHP-Programmcode interpretiert, alles andere wird unverändert an den Clienten ausgegeben. Es steht dem PHP-Programm eine Vielzahl der in modernen Programmiersprachen üblichen Verfahren offen [PHP], deren genaue Beschreibung den Rahmen dieser Arbeit sprengen würde. Die wichtigsten der verwendeten Funktionen werden im Anschluss erläutert.
  4. Über die Befehlszeilen:mysql_connect("HOST","USER","PASSWORD") ordie("Unable to connect to SQL server");mysql_select_db("DB") or die("Unable to select database");wird eine Verbindung zur MySQL-Datenbank DB auf dem Rechner HOST als Nutzer USER hergestellt. Durch die Rechtevergabe an den Nutzer User ist auch geklärt, ob der Zugriff nur lesend oder auch schreibend erfolgen kann.
  5. Durch den Befehl: $variable= mysql_query“SQL-Anweisung“ erfolgt die Abfrage oder Änderung der Datenbank. (Das $-Zeichen steht in PHP am Anfang jeder Variablen)
  6. Der aus der Datenbank ermittelte Array wird dann in PHP interpretiert und durch den echo-Befehl werden Knoten der VRML-Datei an den Clienten zurückgegeben.
  7. Im Clienten verarbeitet das Plugin oder die angeschlossene VR-Umgebung die VRML-Datei in einen Szenegraphen zur Darstellung einer virtuellen Welt.

Gewählte Vorgehensweise bei der Serverseitige Programmierung

Als Lösungsmöglichkeit kam aus den oben genannten Gründen nur ein Programmierverfahren mit Datenbankanbindung in Betracht. Aufgrund der starken Anbindung des VRML-Standards an die Möglichkeiten des Internets bot sich eine webbasierte Lösung an.

Aus folgenden Gründen kam es zum Einsatz einer Kombination aus MySQL, PHP und einem Apache-Webserver:

  • Als mögliche freie Datenbanken mit Web-Schnittstelle kamen MySQL und PostgreSQL in Frage. Aufgrund der besseren Performance, der weiten Verbreitung und dem Angebot des Chemnitzer Universitätsrechenzentrums MySQL Datenbanken bereitzustellen, fiel die Wahl auf ersteres DB-System.
  • Bei der Wahl des verwendeten Programmiersystems fiel die Entscheidung aufgrund der leichten Implementierung und der großen Verwendung sehr schnell auf PHP. Andere Varianten, wie die Verwendung von cgi- oder asp–Skripten, wurden aufgrund des fehlenden freien Serverzugriffes nicht in Betracht gezogen. Eine Alternative hätte die Programmierung in Perl dargestellt, der Einarbeitungsaufwand erschien dabei jedoch höher.
  • Ein weiterer Vorteil der gewählten Kombination aus MySQL-Datenbank und PHP-Programmierung ist die Möglichkeit, diese Programme auch auf einem lokalen Rechner einfach installieren zu können. Der Zusammenschluss von Apache-Webserver, MySQL-Datenbank, PHP und PhpMyAdmin wird als so genannter Xampp bezeichnet und steht unter [XAMP] zum freien Download für verschiedene Betriebssysteme zur Verfügung.

Wichtig war weiterhin die Entscheidung zwischen dem VRML-Standard und dem als Nachfolger von VRML bezeichneten X3D-Standard für die Objektbeschreibung in der Virtuellen Realität. Der X3D-Standard bietet aufgrund seiner XML-Konformität sicherlich Vorteile bei der Aufschlüsselung durch ein Programm, aber folgende Gründe sprachen für die VRML-Anwendung:

  • Es war nicht das Ziel 3D-Daten zu lesen, sondern zu schreiben. Somit entfiel der Hauptvorteil von X3D mit seiner XML-Konformität.
  • Auch zeitgemäße Anwendungen wie White dune [WHIT] oder VRMLPad arbeiten mit VRML. Diese waren bei der Entwicklung und der Fehlersuche hilfreich.
  • Die vorhandenen X3D-Viewer sind zu VRML abwärtskompatibel.
  • Die zur Verfügung stehenden VR-Systeme erforderten die Verwendung von VRML 1.0.


Ein weiterer Grund, der für die Verwendung der MySQL-Datenbank sprach, war die flexible Verbindung an verschiedene Systeme. So kann auf die MySQL-Datenbank neben der PHP-Programmierung auch auf die folgenden Weisen zugegriffen werden:

  • Die MySQL-Konsole dient u. a. für Wartungsaufgaben und das Einspielen großer Datenmengen.
  • PHPMyAdmin dient als universeller DB-Webeditor ohne Einschränkungen für einen Administrator.
  • Über Web-Formulare können durch Einschränkungen des Funktionsumfanges ggf. nur sinnvollen Eingaben vorgenommen werden. Zudem können Relationen zwischen verschiedenen DB-Tabellen für den Nutzer anschaulich programmiert werden. Diese Web-Formulare können auch durch PHP in Abhängigkeit der DB generiert werden.
  • Über VRML-Anchor können PHP-Programme aus der VR-Umgebung heraus ausgelöst werden, die dann auf die Datenbank zugreifen.


Funktionsorientierte Umsetzung des Motorspindelbaukastens für die VR

In der Phase der Baukastenkonfiguration zeigte es sich, dass der Aufwand zur Änderung von Lösungsprinzipien bei einer hinterlegten Funktionsstruktur sich stark reduzieren lässt im Verhältnis zu einer Datenstruktur ohne Funktionsorientierung, da die grobe Funktionsanordnung gemäß Abbildung 24 bei allen untersuchten Motorspindeln gleich ist.



Abbildung 24: generelle Anordnung der Funktionselemente an einer Motorspindel


Diese Funktionsanordnung musste bauteilübergreifend in die Datenbankstruktur integriert werden, da eine Funktion wie z.B. die Lagerung von mehreren Bauteilen übernommen wird. Dabei sollte eine Art Skelett die Verbindung zwischen den Bauteilen und die Positionierung der Bauteile herstellen. Für die Positionierung war es vorteilhaft auf die in VRML üblichen Transform-Anweisungen zurückzugreifen.

Diese Art der Verknüpfung von Bauteilen unterscheidet sich auch von der reinen Bauteilanordnung vieler MCAD–Programme, bei denen Bauteile über eine Anzahl von Objektmerkmalen (Punkten, Achsen, Kanten oder Flächen) an den Objektmerkmalen von anderen Bauteilen ausgerichtet werden. Das MCAD-Programm PRO/ENGINEER besitzt z.B. für Konfigurationsaufgaben eine Funktion namens Austauschbaugruppe [RUES-00], mit der jedoch die Weitergabe von Objektinformationen an andere Bauteile nicht gegeben ist. Es war jedoch bei der Motorspindelkonfiguration z. B. erstrebenswert, dass sich die Positionen der Lager an die Auswahl des verwendeten Motors automatisch anpassen sollten.

Die Geometriedaten stammten als 2D-Konturdaten aus Eingaben in dem Programm AutoCAD. Somit standen komfortabel alle CAD-typischen Möglichkeiten für die Gestaltung der untereinander kompatiblen Bausteine zur Verfügung.

Exportiert wurden die Konturdaten über die Funktion Auflisten im Autocad-Menü Werkzeuge/Abfrage. Zur Geometrieumwandlung dienten ein zu diesem Zweck angefertigtes, eigenständiges Webformular Acadeingabe.php (siehe Anhang) mit einem Eingabetextfeld und ein anschließendes PHP-Skript Acadausgabe.php (siehe Anhang) zur Verarbeitung der Texteingabe und der Ergebnisausgabe im Browser.

Daneben ist es auch möglich, die aus dem Export von 3D-Programmen stammenden .wrl-Dateien direkt als Text in die Datenbank einzutragen oder mit Hilfe des Eintrags Inline{url „./Datei.wrl“} auf größere VRML-Dateien zu verweisen.

Darstellung der verwendeten Datenbankstruktur

Zur Umsetzung wurden die in Abbildung 25 dargestellten und im Anhang aufgeführten Tabellen in der Datenbank angelegt.

In der Tabelle geom wurde dabei für jede Kombination aus Bauvariante, Bauteil, Funktion und Lösungsprinzip eine Geometrie hinterlegt. Somit war es auch möglich, das Bauteil „Welle“ in die abstrakten Bauteile „Lagerstelle“, „Motorbefestigung“, „WZ-WS-Aufnahme“ usw. zu zerlegen. Als Primärschlüssel, d. h. als Felder zur eindeutigen Kennzeichnung eines Datenbankeintrages, dienen die Spalten SatzNr und Prinzip. Neben der Geometrie bietet die Tabelle geom Spalten für die Aufnahme der Bezeichnung, der Materialeigenschaften (Optik) und der Positionsnummer.


Abbildung 25: Datenbankstruktur (Ein Großteil des Informationsfluss wird durch das PHP-Skript gebildet und ist nicht dargestellt)

Für jedes Bauteil können in der Tabelle Schnittst beliebig viele Schnittstellen festgelegt werden. Diese Schnittstellen erfassen einen 3D-Vektor für die relative Position eines anschließenden Bauteils und einen Rotationswert für die Orientierung des Bauteils. Die Orientierung ergibt sich aus einem Richtungsvektor und einer Winkelangabe für die Rotation um den Richtungsvektor.

In der Tabelle Var_zuord erfolgen die relationsbeschreibenden Festlegungen. Als Primärschlüssel dient das Feld ID. Im Feld Oberbauteil wird festgelegt, ob es sich bei dem Bauteil um ein so genanntes Oberbauteil für eine Baugruppenvariante handelt, d. h. ob es das in der Bauteilhierarchie höchstgelegene Bauteil ist. Bei allen untergeordneten Bauteilen wird die ID-Nummer des nächst höher gelegenen Bauteils im Feld verbMit und die jeweilige Schnittstelle im Feld Schnittstelle mit angegeben. Somit ist es möglich, die Geometrie eines Bauteils zu ändern und dabei die Verbindung zu anschließenden Bauteilen auf die aktuellen Schnittstellenwerte zu aktualisieren. Des Weiteren ist für jedes Bauteil die Zugehörigkeit zu einer bestimmten Funktionsgruppe (Lager vorn, Antrieb, Dichtung vorn, WS-WZ-Aufnahme, Lager hinten, Gehäuse und Sensor) mit angegeben.

Über die Funktionsgruppe kann mittels der Tabelle Prinzipzuord festgestellt werden, welches Lösungsprinzip bei einer bestimmten Variante zum Einsatz kommen soll.

In den Tabellen Varianten und Prinzip können Zusatzinformationen zu der jeweiligen Variante bzw. Lösungsprinzip zugeordnet werden, diese Tabellen sind wie alle anderen erweiterbar, um sich spezifizierten Anwendungen anzupassen und das Gesamtsystem erweitern zu können.

Eine weitere wichtige Tabelle ist die Tabelle Variable. Mit ihr lassen sich für globale und lokale Variablen Werte zuteilen und auch Berechnungen durchführen. Diese Variablen können dann für die Anzeigeeigenschaften (s. Abbildung 26), die Geometriebeschreibung (s. Abbildung 27) und die Oberflächenwerte verwendet werden.


[[Image:]]

Abbildung 26: Motorspindeldarstellung mit einer geringen Polygonanzahl, gesteuert über eine Variable.

[[Image:]]

Abbildung 27: verschiedene Abmaße der HSK-Schnittstelle (Nenngrößen 40-125 überlagert)

Zusammenwirken der verschiedenen Programme

Für die Konfiguration von Baukastenlösungen und deren Änderung wurden zudem zwei zusätzliche PHP-Skripte geschrieben. Baugkonf4.php (siehe Abbildung 28 und Anhang) stellt ein Webformular dar, in dem aus der Tabelle Prinzip die möglichen Lösungsprinzipien und aus der Tabelle Prinzip_zuord die aktuell zugeordneten Prinzipien genutzt werden, um die aktuellen Einträge zu markieren.

Nach entsprechenden Formulareinträgen wird das Skript baug_edit3.php (siehe Anhang) mit den gewünschten Parametern aufgerufen, was dann die Einträge in die Datenbank vornimmt.

Somit ist eine Nutzung für eine einfache und geschützte Konfiguration ebenso möglich wie über PHPMyAdmin der komplette Datenbankzugriff für autorisierte Benutzer.


[[Image:]]

Abbildung 28: webbasiertes Konfigurationsformular


[[Image:]]Zur anschließenden Visualisierung wird, durch die Auswahl der gewünschten Baukastenvariante im Formular BaugAuswahl4.php (s. Anhang) das Programm baug_darstel4.php (s. Anhang und folgenden Abschnitt) mit den entsprechenden Parametern zur Erzeugung der Geometriebeschreibung gestartet.

Abbildung 29: BauAuswahl4.php

Programmablauf zur Darstellung der Motorspindel-Baustruktur

Der Programmablauf des Programms baug_darstel4.php (im folgenden Hauptprogramm genannt) ist in Abbildung 30 aufgezeigt und im Anschluss erläutert.


Abbildung 30: Programmablauf aus den in der Datenbank abgelegten Daten über ein PHP-Skript zur Erzeugung der Geometriebeschreibung in einer VRML-Datei


  1. Einlesen der Variablen aus dem Webformular BaugAuswahl4.php. Zusätzlich zur ausgewählten Variante werden die Anzeigeoptionen übergeben, ob die Darstellung mit Beschriftungen der Bauteile oder als Explosionsdarstellung erfolgt.
  2. Bestimmung des zur jeweiligen Variante gehörenden Oberbauteils aus Tabelle Var_zuord.
  3. Rekursive Programmierung: Ein relativ kurzes Hauptprogramm ruft für das in der Hierarchie höchstgelegene Bauteil die Funktion btanzeige(Bauteil) auf. In dieser Funktion werden alle untergeordneten und von ihrer Position abhängigen Bauteile durch den Aufruf der Funktion btanzeige(jeweiliges Unterbauteil) aufgebaut. Dadurch ergibt sich relativ einfach die Wurzelstruktur im VRML-Szenegraph.
  4. Globale und lokale Variablen: Zuerst werden die globalen Variablen gesetzt, d.h. die für alle Bauteile gelten. Wenn für ein spezielles Bauteil andere Werte gelten, dann werden diese Variablen überschrieben. Am Schluss wird der Wert noch einmal überschrieben, wenn für das Bauteil in einer speziellen Variante ein anderer Wert gilt. Durch die eval-Funktion ist es möglich über Datenbankeinträge die Werte beliebiger Variablen und auch Funktionen zu definieren. Angewendet wurde dieses Verfahren zur Parametrisierung der HSK-Schnittstelle:


Variablenname Variablenwert
$nr 3
$d2 pow(10,-0.1+$nr*0.1)*24/2

Somit konnten alle geometrischen Parameter dieser auf Normreihen basierenden Schnittstelle auf Grundlage eines einzelnen Parameters generiert werden.

  1. Die Geometriezeichenkette wird analysiert und wenn es sich dabei um ein Rotier{2D-Kontur} handelt, wird dieses umgewandelt in ein Shape {geometry IndexedFaceSet{3D-Koordinaten und Koordinatenindex} }. Dabei dient die Variable $anteil dazu, festzulegen, ob der Rotationskörper vollständig 360° um die x-Achse gedreht wird oder nur zu einem bestimmten Teil rotiert, und dabei noch die Endflächen eingezeichnet werden, um so ein aufgeschnittenes Bauteil zu zeigen. Die IndexedFaceSet´s wurden auf Grund der vorhandenen Funktionalitäten des benutzten VR-Systems eingesetzt, auch wenn die Verwendung der bereits erwähnten Extrude´s den Vorteil eines um ungefähr den Faktor 100 geringeren Netzwerktraffics gehabt hätten. Das System könnte bei Bedarf um weitere sinnvolle Objektklassen wie Extrudierkörper, also Körper mit einem geradlinigen Pfad zur Entwicklung des 3D-Körpers aus der 2D-Form, erweitert werden. Für zukünftige Entwicklungen erscheint die Programmierung einer Wälzkörperklasse oder eine Objektklasse zur Erzeugung von komplexen LOD´s zur Performancesteigerung sinnvoll.


  1. Als Geometriendaten können in einem Datenbankfeld normale VRML-Knoten eingetragen sein. Diese werden dann als Zeichenkette der VRML-Datei zugeführt. Das Einfügen großer Datenmengen in die MySQL-Datenbank erscheint möglich. (So erreichen MySQL-Tabellen auch Größenordnungen von mehreren GByte.)
  2. Mittels Inline{url „./Datei.wrl“} können auch komplexere externe .wrl-Dateien mit eingefügt werden, wie sie aus CAD- oder Modellierprogrammen stammen.
  3. Aus den Daten der geom-Tabelle können ggf. auch sämtliche Bauteile beschriftet werden.
  4. Gemäß den Daten aus der Tabelle Var_zuord werden die untergeordneten Bauteile ermittelt, d.h. die in der skelettartigen Baustruktur abhängigen Bauteile.
  5. Aufgrund der speziellen VRML-Struktur müssen am Ende noch sämtliche Klammern geschlossen werden.

Darstellung der Ergebnisse

Bei der serverseitigen Programmierung konnte gezeigt werde (siehe Abbildung 31 und Abbildung 32), dass es mit der Verwendung von offenen Standards (VRML), freien (MySQL, PHP) und kostenfreien Programmen (VRML-Plugins) möglich ist Struktur- und Geometriedaten zu verwalten und darzustellen.

Dabei zeigte es sich besonders vorteilhaft, dass diese Systeme nicht nur von einem reinen Informatiker beherrscht werden können, sondern auch von einem für Produktentwicklung verantwortlichen Ingenieur.

Aufgrund der Tatsache, dass es sich bei der optischen Wahrnehmung durch den Menschen um einen subjektiven Vorgang handelt, ist es bei der Visualisierung im Rahmen der Produktentwicklung oftmals sinnvoll die Geometriebeschreibung abweichend von der echten Realität zu gestalten. (Schnittmodelle, Transparenzen, Kraftwirkungslinien, u.a.)

Es war nicht das Ziel dieser Arbeit mit professionellen Mechanical-CAD Systemen in Konkurrenz zutreten, da der dort aufgewendete Entwicklungsaufwand entsprechende Größenordnung annimmt, und auch höhere Programmierverfahren (z.B. Eigenschaftsvererbung und Klassen) zum Einsatz kommen. Dafür sind üblichen CAD-Systeme, aufgrund der Ihnen fehlenden Funktionsstruktur, nur bedingt zur schnellen Konfiguration von Baukastenlösungen geeignet bzw. darauf spezialisiert. Außerdem konnte gezeigt werden, dass eine stärkere Internetorientierung von CAD-Systemen durchaus zeitgemäß erscheint.

Durch den beschriebenen Weg erscheinen mögliche Anwendungsfelder der aufgezeigten Methode erreichbar:

  • Durch niedrige Kostenrelationen für einzelne Rechnerarbeitsplätze erscheinen neue Anwendungsfälle erreichbar (z.B. Werkstattanbindung an die 3D-Geometrie-Daten).
  • Neue Kunden wären über das Internet ansprechbar. Bei einfachen technischen Systemen oder entsprechend erfahrenen Kunden ist auch eine komplette Auftragsabwicklung für ein Baukastensystem denkbar. Ob die Konfigurationseingaben dabei wirklich der Kunde, der Kundenbetreuer oder ein spezialisierter Experte vornimmt, hängt im Einzelfall u. a. von dem Willen des Kunden, der technischen Schwierigkeit, dem Wert des Produktes, der entwickelten Benutzeroberfläche und der Rechtslage ab.
  • In Kompetenzzellen und hierarchielosen Produktionsnetzen wäre die Zusammenarbeit sowohl regional als auch weltweit möglich. Auch bei sich rasch ändernden Konstellationen der Zusammenarbeit wäre man ohne große Kapitalbindung des Softwaresystems flexibel.
  • Für die Benutzung in VR-Anwendungen ergeben sich zusätzliche Methoden der Geometrieerzeugung mit einer hohen Flexibilität und Kontrollmöglichkeit durch den Anwender.
  • Für Forschung und Ausbildung erscheint ein so offenes System sinnvoll, da sich somit schnell Thesen über mögliche zukünftige CAD/CAM-Softwaresysteme überprüft und Grundprinzipien dargelegt werden können.


Variationsmöglichkeiten an den Lagern:


Vorderes Lager: Schrägkugellager in Tandem–O–Tandem Anordnung


Hinteres Lager:
Tandemzylinder-rollenlager
[[Image:]]
Magnetlagerung mit Wälzlagern als Fanglagern
(Grobentwurf)
[[Image:]]
Vorderes Lager: Schrägkugellager in
O –Anordnung


Hinteres Lager:
Zylinderrollenlager
[[Image:]]
Hydrostatiklagerung
(Grobentwurf)
[[Image:]]

Abbildung 31: Variationen der umgesetzten Lagerarten

Variationsmöglichkeiten an der Wz-Ws-Aufnahme:


[[Image:]]


Drehfutter

[[Image:]]


Steilkegelaufnahme

[[Image:]]


HSK-Aufnahme

Variationsmöglichkeiten am Gehäuse:


[[Image:]]


Pinolenausführung

[[Image:]]


Drehmaschinengehäuse

[[Image:]]

Gehäuse für 5-Achszentrum

(Bsp.: Gabelkopf)

Variationsmöglichkeiten am Motor:


[[Image:]]
lange Ausführung
[[Image:]]
kurze Ausführung

Abbildung 32: Variationen an der Schnittstelle zum Prozess, dem Gehäuse und dem Motor


Mögliche Erweiterungen des aufgeführten Systems

Es wurde gezeigt, dass sich die zwei prinzipiell unterschiedlichen Lösungsvarianten, der client- und der serverseitigen Programmierung, zur Baukastendarstellung in der VR nutzen lassen. Beide Verfahren haben ihre jeweiligen Stärken und Schwächen.

Die aufgezeigte Lösung der serverseitigen Programmierung erscheint für Konfigurationsaufgaben durchaus geeignet. Andererseits könnten auch durch die Kopplung mit clientseitig programmierten Auswahltools wie VRML-Anchor-Elementen einfache Konfigurationsaufgaben intuitiv direkt in der VR erfolgen. Die VRML-Anchor-Elemente würden dabei die Verbindung zum Server herstellen, sie dienen als eine Art Knopf (s. Abbildung 33), bei deren Betätigung eine neue VR-Welt vom Server geladen wird.

[[Image:]]

Abbildung 33: Interaktive Auswahlmöglichkeiten in der VR (zusammenb1.php siehe Anhang)


Weitere Anwendungsgebiete könnten die folgenden sein:

  • Über eine zusätzliche Angabe der Montagereihenfolge von Bauteilen ist es denkbar automatisch eine Zusammenbauanimation zu erzeugen. Diese könnte bei größeren zu planenden Anlagen auch noch mit Projektmanagementsystemen wie MSProject gekoppelt werden.
  • Erweiterung zu einem ERP- oder PLM-System bei dem eine starke Verknüpfung zwischen geometrischer und nichtgeometrischer Datenhaltung vorliegt (s. Abbildung 34). PLM-Systeme würden zusätzlich zu den in ERP-Systemen gespeicherten Kunden- und Auftragsdaten unter anderem auch noch Produktänderungen während des Produkteinsatzes enthalten.



Abbildung 34: Datenbankstruktur für ein Warenwirtschaftssystem mit möglichen Anbindungen oder Erweiterungen zu verschiedenen Firmenbereichen


  • Es wäre außerdem möglich, die Daten und Geometrien von beliebigen Zwischenprodukten mit zu berücksichtigen und so die komplette Fertigungskette abzubilden. Es stellt sich dabei aber die Frage, ob eine so große Datenhaltung wirtschaftlich vertretbar ist und wie man die funktions- und bauteilorientierten Konstruktionsdaten sinnvoll in fertigungsorientierte Daten umwandelt.
  • Neben der reinen Geometrie könnten auch die Angaben zu Fertigung (Toleranzen, Oberflächen, Fertigungsverfahren u.a.) mit in der Datenbank abgelegt werden (Featuretechnologie).
  • Ebenso sollten ggf. Preis- und Kalkulationsunterlagen mit an das System und die entsprechend hinterlegten Variablen angeschlossen sein.
  • Die Funktionsstruktur sollte incl. der zugrunde liegenden Berechnungen ebenfalls mit an ein rechnergestütztes Planungssystem angeschlossen sein.

Am Beispiel der Motorspindel wurde gezeigt, dass es durchaus wirtschaftliche Chancen für die Entwicklung von Baukastensystemen gibt. Bei der Entwicklung eines solchen Baukastensystems kann die VR-Technologie durchaus hilfreich sein, auch wenn Sie aufgrund der dominierenden Rotationssymmetrie bei Motorspindeln nicht ihre volle Leistungsfähigkeit zur Darstellung komplexer dreidimensionaler Objekte ausspielen konnte.

Die Vorteile der Baukastenentwicklung entstehen durch die Kostendegression aufgrund von höheren Stückzahlen von gleichartigen Modulen. So können aus den aufgezeigten 18 Funktionsbausteinen theoretisch 288 Produktvarianten gebildet werden. Die Spindel müsste dabei allerdings aufgrund der verwendeten abstrakten Bausteine in jedem Fall neu gefertigt werden. Dabei erscheint eine Schnittstelle von der verwendeten Datenbank zu einem CAM-System für die spannende Bearbeitung durchaus denkbar und sinnvoll.

Ableitung von Erkenntnissen für zukünftige VR-Anwendungen in der Produktentwicklung

Die nachfolgenden Ansätze für zukünftige Entwicklungen der VR sind relativ unabhängig von den übrigen in der vorliegenden Arbeit behandelten Themen. Sie sollen aber als Denkanstöße dienen, da es sich gerade bei der Entwicklung der VR-Technologie nicht um einen abgeschlossenen Themenkreis, sondern um eine stürmische Entwicklung handelt.

Nutzungsmöglichkeiten bei der Simulation

Für viele Aufgaben wäre es vorteilhaft, wenn es in VRML-Welten nicht nur eine Kollisionsabfrage zwischen Benutzer-Avatar und der Weltengeometrie gäbe, sondern wenn es auch Kollisionsabfragen zwischen beliebigen Geometrieobjekte untereinander vorhanden wären. Über die bereits implementierte Eventsteuerung könnten damit interessante Simulationen bis hin zur Maschinensteuerung erstellt werden.

Besonders viel versprechend erscheint der Zusammenschluss von VR-Simulation und der Simulation einer SPS-Maschinensteuerung zur Simulation und Programmierung von technischen Anlagen und von Regelsystemen vor ihrer eigentlichen Fertigung. Ansatzweise ist diese Entwicklung im Programm Trysim [TRYS] zu erkennen.

Mögliche Erweiterungen für die Geometriebeschreibung

Für die Geometriebeschreibung im Sinne einer CAD-Anwendung wäre die wichtigste Forderung an zukünftige VR-Standards zur Objektbeschreibung, die Unterstützung von Boolschen-Operatoren gemäß der CSG-Methode [HAAS-95] bzw. die Geometriebeschreibung über die Oberflächenbegrenzungen gemäß eines B-rep-Modells [HART-00].

Damit wäre es dann z. B. einfach möglich, Bohrungen in Bauteilen anzuordnen oder den Materialabtrag beim Fräsen zu simulieren. Vorstellbar ist die Umsetzung in einer reinen Oberflächenbeschreibenden Datenspeicherung, der sauberere Lösungsweg wäre jedoch eine Volumenbeschreibenden Datenspeicherung der Geometrie. Eine derartige Umsetzung ist leider auch bei dem als Nachfolger von VRML bezeichneten X3D-Standard nicht zu erkennen. Andere Standards zur Beschreibung eines kompletten Produktmodells, wie z. B. STEP, erscheinen für eine einfache VR-Anwendung als zu komplex [PROS].

Theoretisch wäre natürlich auch eine Umsetzung der oben genannten Methoden in Form einer serverseitigen PHP-Programmierung denkbar, dabei entstände jedoch eine wesentlich höhere Netzwerklast im Vergleich zu einer clientseitigen Programmierung.

Serverseitige Programmierung zur Darstellung großer technischer Welten

Die Nutzung der VR sollte nicht nur auf einzelne Baugruppen und Werkzeugmaschinen beschränkt sein, sondern auch für die Planung von ganzen Anlagen und Fertigungssystemen nutzbar sein. Ein Grund dafür ist, dass solche VR-Systeme wie die CAVE, nur bei solchen Objekten ihre wahren Stärken im Bereich des Maschinen- und Anlagenbaus zeigen können, wo Desktopsysteme an ihre Leistungsgrenzen stoßen. Dabei können in solchen Systemen gemäß [RUES-00] durchaus mehr als 100.000 Bauteile vorhanden sein.

Bei der Planung solcher Anlagen sind mehrere Firmen mit jeweils mehreren Konstrukteuren beschäftigt. Es bietet sich somit an, die jeweiligen Einzelkomponenten in einer Datenbank abzulegen und dann diese während der Visualisierung in Abhängigkeit von der Bauteilposition und der Position des Betrachters aus der Datenbank auszulesen und in die VR-Umgebung einzuladen.

Zur Demonstration dieser Vorgehensweise wurde eine umfangreiche Demo-Datenbank benötigt, aus diesem Grunde wurde auf die frei verfügbare Datenbank der deutschen Wikipedia [WIKI] zurückgegriffen. Die Wikipedia ist eine auf freiwilliger Basis entstandenen Wissenssammlung mit dem Charakter einer freizugänglichen Enzyklopädie.

Für die Visualisierung war es das selbst erklärte Ziel, die ca. 250.000 vorhandenen Artikel in einem virtuellen Raum webtauglich zugänglich zu machen und diese Artikel nach den ca. 5000 vorhandenen Kategorien zu sortieren. Dazu wurde jedem Artikel, in jeder Kategorie zu der er gehörte, über ein PHP-Skript eine Raumposition zugewiesen (1.2 Mio. Einträge insgesamt).

Für die Visualisierung wurde der Virtuelle Raum über ein PHP-Skript in eine Vielzahl von Raumwürfeln zerlegt. Diese Raumwürfel bestanden aus einem LOD bei dem im Falle einer Annäherung durch den Benutzer eine neue PHP-Datei mittels inline {url...} vom Server nachgeladen wird (s. Abbildung 35).


[[Image:]]
[[Image:]]
[[Image:]]
[[Image:]]

Abbildung 35: Mögliche VRML-Flugsequenz durch die Kategorien der Wikipedia mit Verlinkung zu den einzelnen Artikeln

Ein weiterer Punkt, der an diesem Beispiel getestet werden konnte, ist die Interaktionsmöglichkeit aus der VR-Umgebung in Richtung der serverseitig laufenden PHP-Umgebung und des Datenbanksystems. Dazu dienten die Anchor-Elemente innerhalb von VRML; deren Berührung durch den Benutzer löst das Nachladen einer speziellen Datei aus. Bei dieser Datei handelt es sich um eine PHP-Programmdatei zur Anzeige der Links, die wiederum die Datenbankverbindung herstellt. Mit Hilfe der Variablenübergabe an das PHP-Skript mittels der aufgerufenen URL könnten somit auch Datenbankeinträge vorgenommen werden.

Dieses Verfahren erscheint somit auch für die Darstellung komplexer technischer Systeme geeignet.

Thesen für mögliche zukünftige Erweiterungen von VR-Systemen

Bei den verwendeten VR-Systemen ist im Moment die angestrebte Effizienzsteigerung der Ingenieurstätigkeit nur bedingt gegeben. Als Hauptvorteil erscheint zurzeit aufgrund der großflächigen Anzeige die Nutzung als Kommunikationsplattform zur fachgebiets-übergreifenden Produktentwicklung. Durch das stereoskopische Sehen wird die Wahrnehmungskraft auch von Entscheidungsträgern aus den nichttechnisch (betriebswirtschaftlich) geprägten Abteilungen einer Firma gestärkt. Die Stärke der VR bei der Echtgrößendarstellung für Ergonomieuntersuchungen spielt, ebenso wie die ästhetische Überprüfung von Produktdesigns, nur in Teilbereichen des Maschinenbaus eine Rolle.

Anderseits stellt die VR ein gutes Marketinginstrument dar, da man sich aufgrund der noch geringen Verbreitung als allgemeiner Technologieführer darstellen kann und z.B. auf Messen auch Produkte und Anlagen vorstellen kann, deren Ausmaße den Ausstellungsrahmen sprengen würden.

Für kleinere und mittlere Unternehmen dürfte es im Moment schwierig sein, die hohen Investitionskosten in die VR durch schnellere und bessere Produktentwicklung wieder zu erwirtschaften.

Die hohen Investitionskosten dürften aufgrund der rasanten technischen Entwicklung in diesem Bereich rasch sinken, was allerdings auch den Zeitraum stark verkürzt, indem sich die Investition wieder amortisiert haben müssen. Treibende Kraft für den andauernden Preisverfall der Computerhardware (Grafikkarte und CPU) ist dabei erstaunlicher Weise nicht die CAD-Branche, sondern der Bereich der Computerspiele. Dieser Bereich ist außerdem die Meßlatte für die sich immer weiter verbessernde optische Qualität von VR-Welten. Auch die übrigen Komponenten eines VR-Systems (Vernetzung, Projektionswände und Projektoren) unterliegen einer ständigen Weiterentwicklung, auch wenn bei Ihnen die mögliche Benutzungsdauer auf aktuellem Stand der Technik wesentlich länger sind.

Ausschlaggebend für den wirtschaftlichen Einsatz der VR für Konstruktionsaufgaben wird die Entwicklung der VR-Software sein. Ob es dabei zur Übertragung von etablierten CAD-Systemen (PRO/Engineer, Inventor u.a.) auf die VR-Umgebung oder zu kompletten Neuentwicklungen kommt, bleibt abzuwarten. Es ist außerdem vorstellbar, die Entwicklung eines offenen CAD-Systems mit öffentlichen Forschungsgeldern zu unterstützen, um somit die Effizienz der technischen Entwicklung in Deutschland oder Europa zu fördern und damit diese Entwicklung für die Allgemeinheit rentabel zu machen.

Die VR-Technologie besitzt noch einen starken Forschungs- und Entwicklungsbedarf.

Die Nutzung des VRML-Standards als CAD-Austauschformat, 3D-Standard in Internetanwendungen und Dateiformat in VR-Systemen bringt deutliche Synergieeffekte. Es zeigte sich, dass die Benutzung der VRML-Skriptsprache für Visualisierungsaufgaben eine bedeutende Arbeitserleichterung gegenüber einer kompletten Neuentwicklung auf der Basis von z.B. C++ und OpenGL darstellt, da dem Entwickler die Einzelheiten der Hardwareunterstützung, des Speicher- und Eventmanagements und der Verarbeitung von Benutzerinteraktion abgenommen werden. Dafür müssen allerdings auch Einschränkungen in den Eingriffsmöglichkeiten in Kauf genommen werden.

VR-Systeme sollten die für den jeweilig angestrebten Verwendungszweck folgende sinnvolle Funktionalitäten umfassen:

Eingabemöglichkeiten durch den Benutzer: Neben dem in VR-Systemen heutzutage benutzten einfachen Zeigern, deren Position durch optisches oder magnetisches Tracking im Raum verfolgt wird, böte sich auch einen Kombination mit kabellos vernetzten Handheld-Rechnern an, um per Touchscreen Eingaben vorzunehmen und dem Nutzer Zusatzinformationen zu bieten. Diese Signale sollten in Echtzeit verarbeitet werden und zur Interaktion dienen. Ob Benutzereingaben in zukünftigen VR-Systemen über die Erfassung der Gestik, über eine Sprachsteuerung oder eine Kombination mit anderen Techniken erfolgt, bleibt abzuwarten.

Möglichst realitätsnahe Ausgaben von 3D-Welten: Durch gestiegene Rechenleistung und Optimierung der Rechenverfahren ist es gelungen, auch früher nicht echtzeitfähige Verfahren, wie das Raytracing, in den Geschwindigkeitsbereich von Echtzeitverfahren zu bringen. Allerdings steht diese Entwicklung erst am Anfang und der Aufwand ist mit ca. 48 parallel arbeitenden Prozessoren beachtlich. Eingesetzt wird dieses Verfahren z. B. bei VW für Designstudien von Scheinwerfern und von Automobilen, da dort andere Abbildungsverfahren an der gewünschten exakten Berücksichtigung von Reflektion und Refraktion scheitern. Es wird aber auch durch das globale Beleuchtungssystem und den damit erzielten realistischen Schattenwurf, die räumliche Auffassungsgabe des Benutzers verbessert.

Kommunikation: Auf der Welt verteilte Entwicklungsteams könnten durch die akustische Kopplung und die Einblendung von so genannten Avataren in einer gemeinsamen virtuellen Welt ihre Entwicklungsaufgaben in einer intensivierten Zusammenarbeit erfüllen.

Integration der üblichen 2D-Computerumgebung in die VR: Es erscheint nicht sinnvoll sämtliche nützliche Programmfunktionen wie einen Taschenrechner oder einen Webbrowser für die 3D-Umgebung neu zu entwickeln, sondern ihre auch frei verfügbaren 2D-Varianten (Linux, mittels X-Servers) zu benutzen und die Anzeige auf frei im Raum platzierbaren „Windows“ als veränderliche Texturen zu platzieren. Somit wären dann auch virtuelle Tastaturen denkbar, deren Benutzung erfolgt dann durch einfaches Anklicken. Dieses währe auch eine Möglichkeit die bereits vorhandenen CAD-Programme relativ einfach in eine VR-Umgebung umzusetzen.

Abspeicherung der Ergebnisse: Selbst dieser grundlegende Punkt stellt für heutige VR-Umgebungen noch eine Herausforderung dar, die in zukünftigen Systemen incl. der Versionsverwaltung gelöst werden sollte.

Echtes räumliches Sehen im Sinne einer Veränderung der Scharfstellebene des Auges und einer entsprechende Tiefenunschärfe von davon entfernten Objekten beherrscht keines der vorhandenen Systeme und ist somit eine Herausforderung für zukünftige Entwicklungen.


Literaturverzeichnis

[ADAM-92]Adami, W.:

Strukturen wissensbasierter Systeme für die rechnergestützte Konstruktion: Dissertation TU Braunschweig 1992: ISBN 3-8027-8609-2 Vulkan-Verlag Essen


[BEUK-99]Beuke, D. , Conrad, K.-J.:

CNC-Technik und Qualitätsprüfung: Verlag Fachbuchverlag Leipzig ISBN 3446212434, Leipzig 1999


[BÖGE-98]Böger, H.:

Herstellerübergreifende Konfigurierung modularer Werkzeugmaschinen:: VDI-Fortschrittsberichte 2-462 ISBN 3-18-3462028, VDI-Verlag, Düsseldorf 1998


[DRES-04] Dresig, H.; Holzweißig, F.:

Maschinendynamik 5.Auflage Springer Verlag Berlin : ISBN 3-540-01362-8, Berlin 2004


[DUBB-01] Grote K.-H.; Feldhusen, J.: Dubbel Taschenbuch für den Maschinenbau: Springer, Berlin : ISBN: 3540677771,Berlin 2001


[FLAN-03]Flanagan, D.:

JavaScript kurz & gut: Verlag O'Reilly ISBN 3-89721-253-6,

Köln 2003


[GIES-00]Giesen, K.:

Access 2000 Power!: Verlag Sybex ISBN 3-8155-1003-1, Düsseldorf 1999


[HAAS-95] Haasis, S.:

Integrierte CAD-Anwendungen, Rationalisierungspotentiale und zukünftige Einsatzgebiete: Springer Verlag Berlin : ISBN 3-540-59145-1: Berlin 1995


[HART-00] Hartmann, D. (Hersg.) :

Objektorientierte Modellierung in Planung und Konstruktion: Willey-VCH GmbH Verlag: ISBN 3-527-27146-5: Weinheim 2000


[HIRS-00] Hirsch, A.:

Werkzeugmaschinen Grundlagen:: Vieweg Verlagsgesellschaft : ISBN: 3528049502,Braunschweig 2000


[KAMP-90] Kamp, G.:

Verschleißverhalten von Schrägkugellagern in Schnelllaufenden Spindeln bei Minimalmengenschmierung: Dissertation TU Braunschweig 1990


[KOHL-97] Kohlhase, N.:

Strukturieren und Beurteilen von Baukastensystemen: VDI-Fortschrittberichte 1-275:VDI-Verlag, Düsseldorf 1997


[PEYT-04]Peyton, C.; Möller, A.:

PHP 5 und MySQL 4: Verlag Markt und Technik ISBN 3-8272-6775-7, München 2004


[RUES-00] Rues, K.; Uhlich, D.:

Pro/ENGINEER - Strategien zum Umgang mit großen Baugruppen: Fachbuchverlag Leipzig : ISBN 3-446-21384-8 : Leipzig 2000


[RAMA-00]Ramadan,K. B.:

Methode zur Auslegung und dynamischen Optimierung von Hauptantrieben spanender Werkzeugmaschinen: Verlag Wissenschaftliche Scripten: ISBN 3-928921-60-6 : Zwickau 2000


[ROTH-91]Rothley, J. :

Fertigungsgerechtes Konstruieren mit CAD, Technische Formelemente steigern die Wirtschaftlichkeit: VDI-Verlag : ISBN 3-18-401181-X : Düsseldorf 1991


[SCHR-02] Schreibner, H.:

Abschlussbericht für „InnoSachs“ der Lernstatt GmbH: Chemnitz 2002


[WECK-02a] Weck M.:

Werkzeugmaschinen Konstruktion und Berechnung, Bd. 2:

7.Auflage:Springer-Verlag, Berlin 2002


[WECK-02b] Weck, M.:

Mechatronische Systeme, Vorschubantriebe, Prozeßdiagnose Bd.3: 5.Auflage: Springer-Verlag, Berlin 2002


Online-Adressen:

[BLAX]blaxxun technologies GmbH

http://www.blaxxun.com/de/site/index.html

[CYTEC]CyTec Zylindertechnik GmbH

http://www.cymill.de/

[DPMA]Deutsches Patent- und Markenamthttp://www.dpma.de

[DUNE]White dune-Software

http://www.csv.ica.uni-stuttgart.de/vrml/dune/

[HYPRO]Hyprostatik Schönfeld GmbH

http://www.hyprostatik.com/ger/index.html

[KESS]Franz Kessler GmbH

http://www.franz-kessler.de

[LANG]LANG Antriebstechnik GmbH

http://www.langantriebstechnik.de/

[LUST]Lust Antriebstechnik GmbH

http://www.lust-antriebstechnik.de/cgi-bin/page.pl

[MYSQL-1]MySQL Dokumentation

http://www.tu-chemnitz.de/docs/mysql/

[MYSQL-2]MySQL Dokumentation

http://www.tbee.de/mysql/

[OTT]OTT-JAKOB GmbH & Co

http://www.ott-jakob.de/

[PHP]PHP-Dokumentation

http://www.php-homepage.de

[PROS]ProSTEP iViP Association

http://www.prostep.org/de/standards/was/aufbau/

[SEER]SeeReal Technologies GmbH

http://www.seereal.com

[SIEM]Siemens-Einbaumotoren der Baureihe 1PH

http://www2.automation.siemens.com/mc/mc-sol/de/9d2a796c-613d-4f8f-9fec-813d65b9a0fa/index.aspx

[SPL]SPL Spindel und Präzisionslager GmbH

http://www.spl-spindel.de/index_d.htm

[TRYS]Cephalos Gesellschaft für Automatisierung mbH

www.trysim.de

[WEB3D]Web3D Consortium (VRML-Spezifikationen)

http://www.web3d.org/x3d/specifications/vrml/

[WEIS]Weiss GmbH Schweinfurt

http://www.weissgmbh.de/

[WHIT]White Dune Software für VRML

http://www.csv.ica.uni-stuttgart.de/vrml/dune/

[WIKI]MediaWiki-Software und Datenbankdownload

http://de.wikipedia.org/wiki/Wikipedia:MediaWiki

[WIKI-2]Erfahrungsberichte zum Wikieinsatz

http://de.wikipedia.org/wiki/Wikipedia:Wiki_im_Unternehmen

[VRML]VRML-Forum

http://www.neeneenee.de/vrml/forum/

[XAMP]Xampp-Server

www.apachefriends.org


= Anhang =





MediaWiki