Bislang werden beim metallischen 3D-Druck für CAD, CAM und Nacharbeit verschiedene Datenformate genutzt. Das einheitliches offenes Format OVF beschleunigt die Prozesse erheblich.

Bislang werden beim metallischen 3D-Druck für CAD, CAM und Nacharbeit verschiedene Datenformate genutzt. Das einheitliches offenes Format OVF beschleunigt die Prozesse erheblich. (Bild: Fraunhofer ILT, Aachen / Volker Lannert.)

Das große Ganze

Für den 3D-Druck von Metallen gibt es vielfältige Verfahren. Am geläufigsten ist die Laser Powder Bed Fusion (LPBF), wo Laser durch schichtweises Belichten von Metallpulver ein Werkstück aufbauen. Entlang der Prozesskette müssen die Konstruktionsdaten hierbei mehrfach umgewandelt werden. Dabei entstehen teils Datenvolumen im zweistelligen Gigabyte-Bereich. Sie zu verarbeiten kostet nicht nur Zeit, sondern bringt selbst moderne IT-Systeme an Grenzen.

Bleiben Sie informiert

Diese Themen interessieren Sie? Mit unserem Newsletter sind Sie immer auf dem Laufenden. Gleich anmelden!

Praktikablere Lösung durch offenes Format

Darstellung der Datenverarbeitung entlang der Prozesskette beim LPBF. Das neue Open-Vector-Format wird nach dem Slicing eingesetzt.
Darstellung der Datenverarbeitung entlang der Prozesskette beim LPBF. Das neue Open-Vector-Format wird nach dem Slicing eingesetzt. (Bild: Lehrstuhl für Digital Additive Production DAP, RWTH Aachen University)

Ein Forschungsteam der Lehrstühle für Lasertechnik LLT und für Digital Additive Production DAP der RWTH Aachen University sowie des Fraunhofer-Instituts für Lasertechnik ILT in Aachen hat eine praktikablere Lösung entwickelt. Das neue Open-Vector-Format beschleunigt den 3D-Druck, erlaubt verteilte Datenverarbeitung und vereinfacht neben der Anlagenskalierung auch die Steuerung größerer Anlagenparks.

Warum genau ein neues Datenformat?

Das erschließt sich beim Blick auf die komplexen Abläufe in der LPBF-Prozesskette:

  • Nach der Konstruktion mit einem CAD-Programm müssen die Bauteilkonturen im zweiten Schritt in kleinste geometrische Strukturen umgewandelt werden. In der Regel sind das Dreiecke (»Tesselation«).
  • Anschließend folgt das virtuelle Einpassen des Bauteils in den Bauraum, wobei es so gedreht und gegebenenfalls mit anderen Teilen im virtuellen Bauraum angeordnet wird, um dessen Volumen optimal zu nutzen (»nesting and orientation«).
  • In diesem Schritt wird die Konstruktion außerdem durch etwaige Stützstrukturen abgesichert.
  • Es folgt das  »Slicing«, das die 3D-Struktur in tausende 2D-Schichten für den LPBF-Prozess übersetzt. LPBF-Anlagen breiten nach jeder Laserbelichtung ein frisches Pulverbett aus, fixieren darin per Laser die vorgesehene Bauteilstruktur und gehen dann zur nächsten Schicht über. Neben den 2D-Konturen der jeweiligen Schicht setzt dieser Prozess präzise Anweisungen zur Maschinensteuerung voraus.

An diesem letzten Punkt ergibt sich der Bedarf: Denn während für 3D-Konstruktionsdaten ausreichend Formate existieren, werden die Daten nach dem Slicing vor allem über proprietäre Lösungen der jeweiligen LPBF-Anlagenhersteller verarbeitet. Das liegt auch daran, dass standardisierte Lösungen anderer Bereiche, wie das Format »G-Code« für CNC-Maschinen nur bedingt nutzbar sind. So basiert G-Code auf der Speicherung der Koordinaten im Textformat (ASCII), wodurch die Datenvolumen schnell auf einige 10 GB anschwellen. Entsprechend zeitaufwändig ist die Verarbeitung dieser Datenmengen.

Was kann das neue Format OVF?

  • Die neue Lösung »Open Vector Format OVF« bietet zunächst einmal offene Strukturen, sodass die Nutzer vollen Zugriff auf die Geometriedaten haben.
  • Diese werden in einem am Fertigungsprozess orientierten Vektorformat gespeichert; das reduziert den Umfang der Dateien gegenüber dem Textformat drastisch.
  • Zusätzlich lassen sich im neuen OVF Fertigungsinformationen speichern, wie zum Beispiel die Laserleistung oder die Delay-Zeiten beim Scanprozess.
  • Bei Mehrstrahlanlagen wird zudem die so genannte Scan-Feed-Allocation festgelegt, also die Aufteilung auf mehrere Strahlquellen.

Im Detail basiert das Format auf der Open-Source-Technologie »Protocol Buffers«, die auch Google für strukturierte Daten nutzt. Protocol Buffers definiert eine Interface Description Language (IDL), die zur Definition der OVF-Daten genutzt wurde.

Das Format ist für sechs von Google unterstützte Programmiersprachen lesbar, 30 weitere Sprachen können ebenfalls damit arbeiten. Es basiert auf Binärdaten. Für den 3D-Druck ist die schichtweise Verarbeitung der Daten wichtig, was die Steuerung über ein Netzwerk ermöglicht und so die lokale Datenhaltung stark reduziert.

Experimentelle Vergleiche zeigen, dass das neue Format in ähnlicher Geschwindigkeit verarbeitet wird wie proprietäre Formate der Maschinenhersteller – und damit erheblich schneller als andere offene Formate wie G-Code.

Koppelung mit Vision für Prozessüberwachung

Stärken hat das OVF auch bei der Prozessüberwachung: Um die Kontur des Werkstücks im Zuge der Bearbeitung an Soll-Daten abzugleichen, müssen einerseits der Zugriff auf die Konstruktionsgeometrie gewährleistet und andererseits die Vergleichsmöglichkeit mit Daten der 3D-Vermessung gegeben sein. Hier liegt eine zentrale Motivation für die Entwicklung des neuen Formats: OVF erlaubt es Systementwicklern, LPBF-Anlagen mit einer Bildverarbeitung ihrer Wahl zu koppeln und die Daten zu verknüpfen. Das dient nicht nur der Qualitätssicherung, sondern erleichtert obendrein den Leistungsvergleich verschiedener LPBF-Anlagen. Diese Option besteht auch dann, wenn mehrere LPBF-Systeme samt Prozessüberwachung über ein Netzwerk gesteuert werden.

Anwendung auch in der Mikrostrukturierung

Der automatisierte Vergleich von Soll- und Ist-Daten und das Unterstützen der Maschinensteuerung über das Netzwerk sind auch für ablative Verfahren wie die Laser-Mikrobearbeitung relevant. Ein Beispiel ist das Multistrahlverfahren, das simultan viele kleine Löcher bohrt. Ein Kamerasystem prüft anschließend, ob diese durchgängig gebohrt sind oder noch Materialreste stehen. Durch den Vergleich der Kameradaten mit der Sollgeometrie lässt sich so entscheiden, ob und wo Nacharbeit nötig ist. Die Anweisungen für die Nacharbeit lassen sich dann direkt in OVF programmieren.

Die Definition des OVF-Formats ist auf GitHub verfügbar. Dort sind auch Tools hinterlegt, um andere Formate in OVF zu konvertieren. Obendrein findet sich auf der Plattform Validierungssoftware, mit der sich OVF-Datensätze überprüfen lassen. Zudem ist ein Slice-Viewer geplant, der die einzelnen Schichten visualisiert.

Sie möchten gerne weiterlesen?