Varianten in Autodesk Inventor über Parameter, iParts und iLogic steuern
Eine kopierte Baugruppe ist am ersten Tag die schnellste Lösung und ab der ersten Änderung die teuerste. Dieser Ablauf zeigt, wie du stattdessen eine steuerbare Konstruktion aufbaust und wann welche der drei Stufen die richtige ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Kopieren kostet nichts, bis sich etwas ändert
Der Anlass ist immer derselbe. Ein Kunde braucht dieselbe Vorrichtung, nur zweihundert Millimeter länger. Die vorhandene Baugruppe wird kopiert, die betroffenen Bauteile werden kopiert, die Maße werden angepasst, und nach zwei Stunden steht die neue Ausführung. Das ist an diesem Tag tatsächlich der schnellste Weg, und niemand kann daran etwas kritisieren. Der Preis entsteht erst später und fällt zunächst gar nicht auf.
Er entsteht bei der ersten Änderung, die für alle Ausführungen gilt. Eine Bohrung wandert, eine Norm ändert sich, ein Zukaufteil wird abgekündigt. Jetzt muss jemand herausfinden, wie viele Kopien es gibt, welche davon noch aktiv sind und in welcher die Änderung schon eingepflegt wurde. In Häusern, die über Jahre so gearbeitet haben, ist diese Frage nicht mehr beantwortbar, weil die Kopien in verschiedenen Projektordnern liegen und die Dateinamen nur teilweise einer Systematik folgen.
Der zweite Preis ist stiller. Eine kopierte Baugruppe sieht aus wie eine eigenständige Konstruktion, obwohl sie keine ist. Sie erbt alle Fehler des Originals, und sie erbt sie ohne Verbindung dorthin. Wenn im Original ein Fehler gefunden und behoben wird, bleibt er in allen Kopien stehen. Eine gesteuerte Variante hat dieses Problem nicht, weil es nur eine Konstruktion gibt und die Unterschiede in Werten stehen, nicht in Dateien.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Ablauf von der gewachsenen Kopiensammlung zur gesteuerten Variante
Sechs Stationen, und die Reihenfolge ist nicht beliebig. Wer mit der Regel anfängt, bevor die Parameter benannt sind, automatisiert ein Modell, das niemand lesen kann. Der Ablauf funktioniert an einer bestehenden Konstruktion und verlangt keinen Neuanfang.
- 1
Den Bestand aufnehmen und die Unterschiede aufschreiben
Sammle die vorhandenen Kopien einer Baugruppe und schreib für jede auf, worin sie sich vom Original unterscheidet. Trenn dabei zwei Arten von Unterschied: andere Werte an denselben Stellen und andere Bauteile oder andere Zahl von Bauteilen. Die erste Art ist ein Fall für eine Tabelle, die zweite ein Fall für eine Regel. Diese Liste ist die Grundlage für alles Weitere und meistens kürzer, als alle erwarten.
Geschafft, wenn: Eine Tabelle mit einer Zeile je Ausführung und einer Spalte je Unterschied, aus der hervorgeht, ob es überhaupt eine Größenreihe gibt.
- 2
Die variantenbildenden Maße benennen
Geh die Skizzen und Elemente durch und gib jedem Maß aus deiner Liste einen sprechenden Namen. Alles, was keine Variante bildet, bleibt, wie es ist. Leite abhängige Maße als Gleichung von den führenden ab, statt sie einzeln zu pflegen, denn eine Gleichung geht nicht verloren, wenn jemand nur den einen Wert ändert. Benenn im selben Durchgang auch Elemente, Skizzen, Arbeitselemente und Abhängigkeiten um, die du später aus Regeln ansprechen willst, denn Vorgabenamen aus der Erstellung sind dafür nicht geeignet.
Geschafft, wenn: Ein Modell, in dem die steuernden Maße an ihrem Namen erkennbar sind und in dem Regeln später auf stabile Bezeichnungen zugreifen können.
- 3
Zulässige Werte festlegen statt freier Eingabe
Wandle die Parameter, für die es nur bestimmte Werte gibt, in Multivalue-Parameter um und trag die zulässige Liste ein. Bleib dabei ehrlich: Ein Bereich, in dem tatsächlich jeder Wert vorkommen kann, gehört nicht in eine Liste, sondern bekommt später eine Parametereinschränkung mit Mindest- und Höchstwert. Beide Wege sind gut, aber sie lösen unterschiedliche Aufgaben, und die Verwechslung führt zu Listen mit hundert Einträgen, die niemand pflegt.
Geschafft, wenn: Eine Konstruktion, in der eine Fehleingabe nicht mehr zu einer Geometrie führt, die es in der Fertigung nicht gibt.
- 4
Die feste Größenreihe als iPart oder iAssembly abbilden
Für Bauteile mit abzählbaren Ausführungen erstellst du die Tabelle über Verwalten und die Gruppe Autor. Wähl die Spalten bewusst schmal, setz mit dem Kontextmenü die Standardzeile fest und vergib sprechende Variantennamen. Beachte dabei, dass eine Änderung am Variantennamen den Dateinamen der erzeugten Variante beeinflusst, Inventor weist darauf ausdrücklich hin. Für Baugruppen gilt derselbe Weg als iAssembly, und die darin verbauten iParts lassen sich je Zeile auf eine bestimmte Variante festlegen.
Geschafft, wenn: Eine Datei je Bauteilfamilie statt einer Datei je Ausführung, mit einer Tabelle, in der jede Zeile eine belegte Ausführung ist.
- 5
Die Entscheidungen als Regeln ergänzen
Alles, was sich nicht in eine Spalte schreiben lässt, wird zur Regel. Typische Fälle sind: Ab einer bestimmten Länge kommt eine zusätzliche Abstützung dazu, unterhalb einer Wandstärke wird ein anderes Fügeverfahren gewählt, ab einer Baugröße wechselt das Zukaufteil. In der Regel greifst du Parameter als Variablen ab, in externen Regeln über die Parameter-Funktion, weil dort die Namen nicht automatisch als Variablen bereitstehen. Halte jede Regel kurz und gib ihr einen Namen, der die Entscheidung benennt.
Geschafft, wenn: Eine Konstruktion, die auch die Fälle abdeckt, in denen sich die Zahl der Bauteile ändert, ohne dass dafür eine Kopie entsteht.
- 6
Eine Oberfläche bauen und den Ablauf im Team verankern
Leg ein Formular an, das nur die Eingaben zeigt, die tatsächlich gewählt werden, und verbind es mit den Parametern und Regeln. Speicher es als globales Formular, wenn mehrere Dokumente dieselbe Bedienung bekommen sollen. Halte danach schriftlich fest, wer neue Werte in die Listen aufnehmen darf und wie eine Änderung getestet wird, bevor sie freigegeben ist. Ohne diese Vereinbarung wird die erste Sonderanfrage wieder per Kopie gelöst, und dann fängt die Sammlung von vorne an.
Geschafft, wenn: Eine Variantenkonstruktion, die auch bedient wird, weil niemand dafür die Parametertabelle öffnen muss.
Fünf Fragen, und die Stufe steht fest
- 01 Unterscheiden sich die Ausführungen nur in Zahlen oder auch in der Zahl der Bauteile?
- 02 Gibt es eine endliche Liste zulässiger Ausführungen oder einen freien Bereich?
- 03 Wie oft ändert sich etwas, das für alle Ausführungen gleichzeitig gilt?
- 04 Wer wählt die Variante aus: die Konstruktion selbst oder der Vertrieb?
- 05 Existiert für jedes variantenbildende Maß schon ein sprechender Parametername?
Die drei Stufen und woran du die richtige erkennst
Inventor bietet drei Mechanismen an, die aufeinander aufbauen. Sie schließen sich nicht aus, im Gegenteil: Die höheren Stufen setzen die niedrigeren voraus. Wer mit Stufe drei anfängt, ohne Stufe eins ordentlich gemacht zu haben, baut eine Automatisierung auf unbenannte Maße.
Stufe eins: benannte Parameter statt d0, d1 und d17
Jedes Maß, das eine Variante ausmacht, bekommt einen sprechenden Namen und wird über die Parametertabelle gepflegt. Numerische Parameter dürfen dabei Brüche und Gleichungen enthalten, etwa dreiviertel eines anderen Maßes. Das ist keine Fleißarbeit ohne Gegenwert: Solange die Maße d0 und d17 heißen, kann niemand eine Tabelle oder eine Regel darauf aufbauen, ohne sie vorher zu suchen.
Stufe eins plus: Multivalue-Parameter für zulässige Werte
Ein Multivalue-Parameter ist ein Parameter mit einer hinterlegten Liste möglicher Werte, von denen zu jedem Zeitpunkt genau einer gilt. Anlegen kannst du ihn im Dialogfeld Parameter über das Kontextmenü mit Mehrere Werte erstellen, die Werte lassen sich aus einem Editor oder aus Excel einfügen. Über Multivalue-Liste bearbeiten und das Kontrollkästchen Benutzerdefinierte Reihenfolge legst du die Sortierung fest. Damit kann niemand mehr eine Zwischengröße eintragen, die es in der Fertigung nicht gibt.
Stufe zwei: iParts und iAssemblies für feste Reihen
Wenn es eine überschaubare Zahl fest definierter Ausführungen gibt, ist die Tabelle die richtige Antwort. Über die Registerkarte Verwalten und die Gruppe Autor startest du iPart erstellen und wählst aus, welche Parameter, Eigenschaften, Ausschlussstatus, iMates, Arbeitselemente und Gewinde je Variante unterschiedlich sein sollen. Für jedes gewählte Attribut entsteht eine Spalte, für jede Ausführung eine Zeile. Nimm nur die Werte auf, die sich wirklich unterscheiden, denn jede überflüssige Spalte muss in jeder Zeile gepflegt werden.
Stufe drei: iLogic für alles mit Wenn und Dann
Sobald eine Variante nicht nur aus anderen Zahlen besteht, sondern aus anderen Entscheidungen, reicht die Tabelle nicht mehr. Eine iLogic-Regel ist ein kleines VB.NET-Programm, das direkt im Bauteil-, Baugruppen- oder Zeichnungsdokument gespeichert wird und Parameter, Elemente und Komponenten steuert. Damit lassen sich Komponenten und Abhängigkeiten über bedingte Argumente aktivieren, iPart-Konfigurationen anhand von Bedingungen auswählen und Stücklistendaten mitziehen, wenn eine neue Konfiguration entsteht.
Die Bedienoberfläche vom Modell trennen
Wer eine Variante auswählt, soll nicht die Parametertabelle öffnen müssen. Dafür gibt es Formulare: eine angepasste Oberfläche, die du mit Ziehen und Ablegen zusammenstellst und mit Parametern, Eigenschaften und Regeln verbindest, ohne dafür zu programmieren. Formulare lassen sich mit einem Dokument speichern oder als globale Formulare für mehrere Dokumente ablegen. Genau das entscheidet darüber, ob eine Variantenkonstruktion im Team ankommt oder ob am Ende doch wieder jemand kopiert.
Grenzen einbauen, bevor jemand sie überschreitet
Eine steuerbare Konstruktion ist nur so gut wie ihre Absicherung. Im Dialogfeld Regel bearbeiten gibt es auf der Registerkarte Assistenten einen Assistenten für Parametereinschränkungen, mit dem du Mindest- und Höchstwerte festlegst. Dazu kommen Meldungsfelder und Eingabefelder, mit denen eine Regel während der Ausführung nachfragt oder eine Rückmeldung gibt. Ohne diese Grenzen entsteht früher oder später eine Konfiguration, die zwar durchgerechnet wird, aber nicht fertigbar ist.
Modellzustände sind etwas anderes als Varianten
Modellzustände steuern, welche Elemente und Komponenten in einem Dokument aktiv sind, etwa für Rohteil und Fertigteil oder für eine vereinfachte Darstellung. Sie sind nicht der Ersatz für eine Größenreihe. Wer sie dafür einsetzt, bekommt eine Datei mit vielen Zuständen, deren Stücklistenverhalten von Sonderregeln abhängt. Halte die beiden Konzepte auseinander: Modellzustände für Zustände eines Bauteils, iParts und iLogic für Ausführungen eines Produkts.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Tabelle oder Regel: die Entscheidung fällt an der Bauteilzahl
Die nützlichste Unterscheidung für diese Frage ist einfach: Ändert sich zwischen den Ausführungen nur, wie groß etwas ist, oder ändert sich auch, was verbaut ist? Im ersten Fall lassen sich alle Unterschiede in Spalten schreiben, und dann ist die Tabelle die richtige Antwort, weil sie ohne Programmierung auskommt und weil jeder sie lesen kann. Im zweiten Fall bräuchtest du für jede Kombination eine eigene Zeile, und die Zahl der Zeilen wächst schneller als die Zahl der Merkmale.
iLogic ist genau für den zweiten Fall gebaut. Die Automation-Funktionen umfassen ausdrücklich das Suchen und Ändern von iPart- und iAssembly-Konfigurationen anhand von Bedingungen, die auf Baugruppenebene definiert sind, sowie das Aktivieren von Bauteilen, Baugruppenelementen, Komponenten und Abhängigkeiten über bedingte Argumente. Damit lässt sich eine Konstruktion beschreiben, in der die Zahl der Bauteile selbst von einem Parameter abhängt.
In der Praxis kommen beide zusammen. Die Bauteilfamilien liegen als iParts vor, die Baugruppe hält die Logik, welche Variante wann genommen wird. Das ist auch der Grund, warum sich die Reihenfolge im Ablauf lohnt: Eine Regel, die auf eine saubere Tabelle zeigt, ist kurz und lesbar. Eine Regel, die die Tabelle ersetzt, wird lang und wird zu dem, was niemand mehr anfasst.
Warum Regeln an Namen hängen und was das für dich heißt
Eine iLogic-Regel spricht Parameter über ihren Namen an. Bei internen Regeln stehen die Parameternamen unmittelbar als Visual Basic-Variablen zur Verfügung: Beim Ausführen überträgt iLogic die Werte aus dem Modell in die Regel, beim Beenden schreibt es die geänderten Werte zurück. Wer die Änderung schon vorher im Modell haben will, ruft die Funktion RuleParametersOutput auf. Das ist der Grund, warum ein Modell mit benannten Parametern deutlich leichter zu automatisieren ist als eines mit den Vorgabenamen aus der Skizze.
Bei externen Regeln liegt der Fall anders, und dieser Unterschied kostet regelmäßig Zeit. Externe Regeln werden in Text- oder VB-Dateien außerhalb des Dokuments gespeichert und laufen bei einer Parameteränderung nicht automatisch los. Vor allem stehen die Parameternamen dort nicht als Variablen bereit, du greifst stattdessen über die Parameter-Funktion zu. Dafür lässt sich dieselbe externe Regel auf allen Bauteilen anwenden, die dieselben Parameternamen tragen, und genau darin liegt ihr Wert für ein Team mit einer festen Namenskonvention.
Dasselbe gilt für Objekte, nicht nur für Parameter. Elemente, Skizzen, Arbeitselemente, Anordnungen, Abhängigkeiten und iMates bekommen bei der Erstellung einen Vorgabenamen, und die Dokumentation weist ausdrücklich darauf hin, diese Namen zu ändern, bevor sie in einer Regel verwendet werden. Wer das überspringt, baut eine Regel, die beim nächsten Umbau des Modells auf ein Element zeigt, das inzwischen etwas anderes ist.
Modellzustände, Ersatzobjekte und die Grenze zur Variante
Modellzustände sind ein eigenständiges Konzept und lösen eine andere Aufgabe. Sie steuern innerhalb eines Dokuments, welche Elemente und Komponenten aktiv sind, und eignen sich damit für Rohteil und Fertigteil, für Zustände vor und nach dem Schweißen oder für eine Baugruppe, die in einer übergeordneten Konstruktion vereinfacht erscheinen soll. Jedes Dokument hat einen primären Modellzustand, der weder umbenannt noch gelöscht werden kann.
Für die Variantenfrage ist besonders die Stücklistenwirkung wichtig, weil sie leicht übersehen wird. Eine unterdrückte Komponente erscheint im primären Modellzustand und in benutzerdefinierten Modellzuständen, die kein Ersatzobjekt sind, nicht in der Stückliste. Für Ersatzobjekt-Modellzustände und für migrierte Detailgenauigkeiten, die nicht die primäre sind, gilt eine delegierte Stückliste, und dort wirkt das Unterdrücken anders. Wer Ausführungen über Modellzustände abbildet, bekommt genau an dieser Stelle Stücklisten, die nicht zusammenpassen.
Eine praktische Einschränkung kommt dazu: Modellzustände müssen in der Datei erstellt werden, zu der sie gehören. In einer übergeordneten Baugruppe kannst du einen vorhandenen Modellzustand einer eingebauten Komponente aktivieren, aber keinen neuen für sie anlegen. Für Ersatzobjekte gilt außerdem, dass sie ein eigenes Dokument verwenden und die iLogic-Regeln und Formulare der Quellbaugruppe nicht übernehmen. Beides sind gute Gründe, Ausführungen dort abzubilden, wo sie hingehören, und Modellzustände für Zustände zu reservieren.
Was der Umbau kostet und wann er sich rechnet
Der Aufwand liegt fast vollständig in den ersten beiden Schritten, also im Aufnehmen des Bestands und im Benennen der Maße. Das ist unspektakuläre Arbeit, sie lässt sich schlecht schätzen, und sie wird deshalb regelmäßig unterschätzt. Der Bau der Tabelle selbst und das Schreiben der ersten Regeln sind vergleichsweise schnell erledigt, weil die Entscheidungen bis dahin schon gefallen sind.
Gerechnet wird der Nutzen nicht an der Zeit für die nächste Anfrage, sondern an der Zeit für die nächste allgemeine Änderung. Wenn eine Norm oder ein Zukaufteil wechselt, ist die Frage, ob jemand eine Datei anfasst oder zwanzig. Diese Rechnung wird sichtbar, sobald du die Zahl der Kopien einer Baugruppe im Dateisystem einmal ehrlich zählst. In den meisten Häusern ist sie höher, als die Schätzung im Raum es vorher war.
Nicht rechnen tut sich der Umbau bei echten Einzelstücken. Wenn jede Anlage anders ist und keine Ausführung ein zweites Mal vorkommt, ist eine Variantenkonstruktion nur ein zusätzliches Bauwerk, das gepflegt werden will. Die ehrliche Grenze verläuft ungefähr dort, wo dieselbe Konstruktion zum dritten Mal mit anderen Zahlen gebraucht wird. Bis dahin ist die Kopie in Ordnung, danach nicht mehr.
Dazu passende Kurse
Wenn im Dateisystem inzwischen mehr Kopien als Konstruktionen liegen, sind Inventor-Kurse zur gesteuerten Variantenkonstruktion der Punkt, an dem sich das umdrehen lässt.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Toller Coach, perfekt abgestimmte Themen. Sehr viel Freiraum für "unsere" Themen und Fragen. Alles sehr rund und perfekt.
Häufige Fragen
Brauche ich für iLogic Programmierkenntnisse?
Was ist der Unterschied zwischen iPart und iAssembly?
Kann ich die Varianten aus Excel steuern?
Was passiert mit den bestehenden Kopien?
Lohnt sich eine Variantenkonstruktion auch für Zukaufteile?
Quellen
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem CAD & Grafik-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die eigene Größenreihe einmal durchbauen
Im Kurs zur Variantenkonstruktion bei cmt bringst du eine Baugruppe aus dem eigenen Haus mit und baust sie von der Parameterbenennung bis zur Tabelle und zur ersten Regel um. Danach ist entschieden, welche Stufe für euch die richtige ist, und das an einem echten Beispiel statt an einer Demo.
Passt dazu
- Inventor-Baugruppe klemmt: Abhängigkeiten, Freiheitsgrade und überbestimmte Bauteile
- Große Baugruppen in Creo werden zäh: Darstellungen, Envelopes und Ladeoptionen
- Eigene CAD-Skripte im Team verteilen und pflegen, ohne dass Wildwuchs entsteht
- Eigene AutoLISP-Routine für AutoCAD schreiben und im Zeichenalltag aufrufen