Was ist iLogic?

Wer mit irgendeiner Desktop-Anwendung arbeitet, versteht im Wesentlichen, was Automatisierung ist. Wenn Sie mit Microsoft Excel arbeiten, haben Sie vielleicht schon einmal von Makros gehört – Tools, die innerhalb von Excel entwickelt und erstellt werden, um eine bestimmte Aufgabe durchzuführen. Inventor Automation funktioniert im Wesentlichen genauso: Denn Automatisierung kann zwar vielerlei Gestalt annehmen, aber im Grund handelt es sich um ein Tool oder eine Reihe von Tools, die eine bestimmte Aufgabe, einen bestimmten Prozess oder eine bestimmte Funktion automatisch ausführen. iLogic ist eine Form von Inventor Automation.

iLogic ist eine Funktion in Inventor, mit der Benutzer und Administratoren Logik für die Ausführung von Aufgaben im VB.net-Format erstellen können. Dazu werden Regeln aufgestellt und mit Snippets und anderen Anweisungen zum Schreiben von Codes organisiert, um einige der Arbeitsschritte von Ingenieuren und Konstrukteuren zum gegebenen Zeitpunkt nach demselben Verfahren auszuführen.

Sie können eine Reihe von iLogic-Regeln entwickeln, um Vorgänge wie die Aktualisierung von iProperties auf Grundlage verschiedener Modellkriterien oder den Austausch von Komponenten in einer Baugruppe auf Grundlage der in einem iLogic-Formular ausgewählten Optionen auszuführen, oder sogar um Textblöcke innerhalb einer zugehörigen Zeichnung zu aktualisieren. Die Liste der Möglichkeiten von iLogic ist lang. Fragen Sie sich, was es für Sie leisten kann.

Welche Gründe sprechen für iLogic?

Nachdem wir jetzt verstanden haben, was iLogic ist, wollen wir uns damit beschäftigen, warum die Einbeziehung von iLogic in Ihren Konstruktionsprozess sinnvoll sein kann.

Erstens: Nach meiner Erfahrungen bei der Zusammenarbeit mit Industrieunternehmen der verschiedensten Größen in allen Teilen der Welt, die viele verschiedene Arten von Produkten herstellen und fertigen, trifft eine Sache immer zu: In jeder Umgebung gibt es Muster und sich wiederholende Abläufe. Der Schlüssel liegt darin, diejenigen zu identifizieren, bei denen iLogic helfen kann. Diese einfache Aufgabe erfordert eine genaue Kenntnis aller Stellen, an denen Inventor in Ihrem Prozess eine Rolle spielt.

Nehmen wir zum Beispiel an, Sie haben ein bestimmtes Format für die iProperty-Beschreibung Ihrer 3D-Modelle oder der zugehörigen iPropertys. Wenn die Formatierung vorhersehbar und standardisiert ist, kann iLogic eine große Hilfe sein. Sie könnten eine Logik entwickeln, um Informationen aus dem Modell zu sammeln, diese umzuwandeln und die iPropertys dann mit den korrekten, neu formatierten Informationen zu überschreiben. Die Logik funktioniert immer fehlerfrei, sie funktioniert immer gleich und unterbrechungsfrei.

Weitere Informationen zu diesem Thema: Taking It to the Next Level: Drawing Automation with Autodesk Inventor mit Thomas Fitzgerald (in englischer Sprache)

Konfigurieren von Inventor für die Verwendung von iLogic

Wie kann man Inventor iLogic effektiv nutzen?

iLogic ist in Inventor bereits enthalten, und Sie können mit iLogic sofort loslegen. Aber es ist sinnvoll, erst einmal bestimmte Einstellungen kennenzulernen, die Sie konfigurieren sollten, um iLogic optimal nutzen zu können. Über die Schaltfläche zum Konfigurieren von iLogic können Benutzer verschiedene Einstellungen konfigurieren, um festzulegen, wo Inventor unterstützende Informationen finden soll.

Konfiguration

Benutzer und Administratoren können diese Einstellungen bearbeiten, um zu steuern, wo Inventor externe Regelverzeichnisse findet und die Prioritätsreihenfolge für diese Verzeichnisse festzulegen. Die Benutzer können auch definieren, an welchem Speicherort Inventor die DLLs (Dynamic Link Libraries) findet. DLLs werden von Microsoft Visual Studio für die Entwicklung benutzerdefinierter Schnittstellen ausgegeben, um iLogic-Regeln und andere Logiken zu steuern und auszulösen.

Im Dialogfeld für die Einstellungen können Benutzer festlegen, mit welcher Dateiendung externe Regeln gespeichert werden sollen, und auf welcher vorgabemäßigen Protokollebene Debugging-Informationen generiert werden können. Es gibt auch einige Einstellungen für Sicherheitsoptionen. Diese dienen dem Schutz der Computer- und Netzwerksysteme vor der Ausführung potenziell gefährlicher Codes in der Inventor-Umgebung. Weitere Informationen über externe Regeln und Debugging werden weiter unten in diesem Dokument behandelt.

Interne im Vergleich zu externen Regeln

Welche Option sollte man wann verwenden?

Es gibt zwei Arten von iLogic-Regeln: interne Regeln und externe Regeln. Die Erstellung beider Arten von Regeln innerhalb des Kontexts von Inventor im iLogic-Browser ist ähnlich.

Browser

Interne Regeln sind Regeln, die innerhalb des Kontexts einer Datei erstellt und gespeichert werden. Bauteil-, Baugruppen- und Zeichnungsdateien haben alle die Fähigkeit, Regeln zu speichern, zu kompilieren und auszuführen, die sich auf die jeweiligen Dateien unterschiedlich auswirken. Externe Regeln funktionieren im Wesentlichen genauso, werden aber nicht innerhalb von Inventor-Dateien gespeichert. Da interne Regeln innerhalb der Dateien gespeichert werden, sind sie für diejenigen Benutzer, die eine Zugriffsberechtigung für die betreffenden Dateien haben, sichtbar und zugänglich. Externe Regeln werden in einem lokalen Verzeichnis, in einem Verzeichnis auf einem Benutzersystem oder in einem standortunabhängigen zentralen Verzeichnis auf einem Server gespeichert.

Da externe Regeln in einem Ordner außerhalb der Dateien gespeichert werden, ist für diese Regeln eine höhere Sicherheitsstufe möglich. Zwar können die Benutzer den Regelcode öffnen und anzeigen, aber Systemadministratoren können den Zugriff und die Bearbeitungsberechtigungen steuern, indem sie Ordnerberechtigungen für den Ordner mit den externen Regeln festlegen. Darum sind externe Regeln in einer Unternehmensumgebung zu bevorzugen, in der zahlreiche Benutzer im Konstruktionsprozess Codes ausführen möchten. Wenn die Bedingungen keine Berechtigungssteuerung erfordern oder sofern die Regellogik nicht von mehreren Benutzern gleichzeitig verwendet werden muss, sind interne Regeln möglicherweise ausreichend.

Beide Arten von Regeln sind im iLogic-Browser sichtbar, wie in den Abbildungen unten zu sehen ist.

Regeln

Mit einem Rechtsklick auf einen der beiden Regeltypen können Sie bestimmte Funktionen steuern, zum Beispiel können Sie Regeln unterdrücken, die Unterdrückung von Regeln aufheben, oder steuern, wann sie ausgelöst werden, Regeln löschen oder aus der Liste entfernen.

Parameter und Eigenschaften

Wie sollte man sie verwenden?

Autodesk Inventor ist eine „Anwendung für die parametrische 3D-Konstruktion“.Was ist damit gemeint? Parameter sind benannte Platzhalter für eine bestimmte Art von Werten. Die meisten Parameter in Inventor sind numerisch und Bemaßungen zugeordnet, welche die Geometrie steuern. Wenn sich die Parameterwerte ändern, ändern sich auch die diesen Parametern zugeordneten Bemaßungen. Die Modelle werden dadurch grafisch aktualisiert. In Inventor gibt es im Wesentlichen vier Arten von Parametern:

1) Modellparameter

2) Benutzerparameter

3) Referenzparameter

4) Verknüpfte Parameter

Modellparameter sind die durch normales Verhalten von Inventor erstellten Parameter. Im Dialogfeld „Parameter“ werden diese automatisch benannt, also d0, d1, d2 usw. Modellparameter werden durch Inventor gesteuert. Das bedeutet, dass sie je nach Bedarf vom System erstellt und gelöscht werden.

Benutzerparameter sind von Benutzern erstellte Parameter. Die möglichen Parametertypen sind Numerisch, Text oder Zeichenfolge, Wahr/Falsch (True/False) oder Boolesche Werte. Benutzerparameter sind besonders wichtig, da sie von Benutzern erstellt, von zahlreichen verschiedenen Funktionen sowie von iLogic-Code verwendet werden und nicht durch das normale Inventor-Verhalten erstellt oder gelöscht werden.

Anmerkung: Die bevorzugte Methode für die Verwendung von Parameterinformationen in iLogic-Regeln ist das Erstellen von Benutzerparametern durch Anwenden einer Benennungskonvention und eines Typs. Man kann Modellparameter zwar umbenennen, aber diese Methode ist zu vermeiden.

Referenzparameter werden erstellt, wenn Inventor eine getriebene Bemaßung definiert. Falls Sie dieses Dialogfeld bei der Arbeit in der Skizzierumgebung jemals gesehen haben:

Skizze

Wenn Sie in dieser Situation Akzeptieren auswählen, können Sie einen Referenzparameter erstellen. Im Dialogfeld „Parameter“ sehen Sie den Parameternamen und -wert, aber Sie können den Wert nicht ändern. Sie können den Namen ändern, was bei der Verwendung des Werts im iLogic-Code hilfreich ist.

Verknüpfte Parameter sind Parameter, die mit Inventor von einer Excel-Tabelle oder Ähnlichem aus verknüpft werden. Wenn ein Benutzer die Namen und Werte in der Excel-Tabelle aktualisiert, schlagen sich diese Änderungen in Inventor nieder und steuern die Bemaßungswerte, kontrollieren Funktionen, verwalten Baugruppen usw.

Eigenschaften bzw. iProperties in der Terminologie von Inventor, sind zusätzliche Deskriptoren oder sonstige nützliche Informationen zu Ihren Dateien. Dies wird manchmal auch als Metadaten bezeichnet. Eigenschaften sind nichts Neues und können ausgesprochen nützlich sein, wenn man viele Daten über Dateien erfassen möchte. Dateiname, Dateigröße, Autor, Bearbeitungsdatum: All dies sind Eigenschaften. Meistens sind Dateiname und Dateipfad die beiden Eigenschaften, mit denen Sie bei der Arbeit mit iLogic und Inventor-Dateidaten zu tun haben. Weitere beliebte Eigenschaften sind Bauteilnummer, Bestandsnummer, Beschreibung, Gewicht, Kosten und benutzerdefinierte Eigenschaften. Alle Eigenschaften sind lesefähig, die meisten Eigenschaften sind auch schreibfähig.

Deklarieren von Variablen, Typumwandlung und gemeinsam genutzte Variablen

Wie wichtig ist es, diesen Programmierjargon zu verwenden?

iLogic ist schlicht und einfach Code. Man braucht zwar kein Programmierer zu sein oder sich mit dem Schreiben von Codes auszukennen, aber wenn Sie einige grundlegende Best Practices für das Schreiben von Codes beachten, kommen Sie recht weit. Denn es gibt bestimmte Standards, die jeder Programmierer versteht. Das Deklarieren von Variablen und die Typumwandlung gehören zu diesen Standards. Warum ist dies wichtig? Es ist wie bei natürlichen Sprachen: Wenn man einen Standard hat, kann man beim Schreiben der Logik einige Verwechslungen vermeiden.

Deklarieren von Variablen und Typumwandlung

Das Deklarieren von Variablen ist im Grunde ausgesprochen einfach. In iLogic brauchen Sie nur einen Namen zu schreiben und ihm einen Wert zuzuweisen:

Länge = 20

Nachdem eine Variable erstellt wurde, lässt sie sich vielseitig nutzen. Man kann den Wert lesen und in einer Berechnung verarbeiten, oder man kann etwas hinzufügen, um etwas anderes zu aktualisieren. Ein Name-Wert-Paar einzugeben ist in iLogic akzeptabel. Eine bessere Möglichkeit – eine Best Practice beim Schreiben von Codes – ist jedoch, wenn wir den Namen eingeben, ihm einen „Typ“ zuweisen und dann einen Wert angeben:

Dim Length As Double = 20

Dadurch wird iLogic angewiesen, eine Variable zu erstellen, die nur einen „Doppelwert“ annimmt, und dann den Wert anzugeben. Diesen Vorgang bezeichnet man als Typumwandlung. Er sorgt dafür, dass nur ein bestimmter Wert für die Variable angegeben werden kann. Wenn ich versuchen würde, einen Zeichenfolgen- oder Textwert für die Variable „Länge“ (bzw. „Length“) anzugeben, würde mein Code fehlschlagen. Ich habe festgestellt, dass ich durch die Angabe eines Typs wesentlich kompliziertere Codes in meinen Regeln verwenden kann. Außerdem kann ich dadurch den Fluss der Informationen nachvollziehen und visualisieren. Ein Beispiel: Wenn ich eine Anweisung in einer Regel schreibe, die eine mathematische Berechnung durchführt, und einen Fehler erhalte, dann weiß ich, dass meine Variablen vom Typ „Zeichenfolge“ richtig funktionieren.

Die folgenden Beispiele veranschaulichen verschiedene Möglichkeiten zum Deklarieren von Variablen und zur Typumwandlung:

Dim cylinderHeight As Double = Parameter("CylinderHeight")
Dim fileName As String = "This is a string value!"
Dim holeCount As Integer = 2
Dim occurrenceName As String = String.Empty
Dim plateWidth As Double = Nothing

Sie werden feststellen, dass ich in den letzten beiden Beispielen keinen Wert angegeben habe, sondern vielmehr einen leeren Wert bzw. nichts. Es wird gelegentlich vorkommen, dass Sie eine Variable deklarieren müssen, aber vielleicht ist Ihnen der Wert nicht gleich bekannt. In diesem Fall können Sie die Konsistenz wahren, indem Sie die Variable deklarieren, die Typumwandlung durchführen und dann etwas auf der anderen Seite des Gleichheitszeichens angeben. Dies ist auch hilfreich beim Debuggen von Code, weil Sie so feststellen können, ob ein Wert programmgesteuert angegeben wird oder nicht.

Wenn Sie genau hinsehen, werden Sie außerdem feststellen, dass im ersten Beispiel, in dem ich eine Variable deklariert und die Typumwandlung durchgeführt habe, einen Wert festgelegt habe, der gleich dem Wert eines Benutzerparameters ist. Diese Methode wird nützlich beim Konstruieren der für Berechnungen benötigten Logik, beim Übergeben von Werten an andere Konstrukte und beim Bearbeiten weiterer Parameter sein. Sie ist außerdem nützlich, wenn Sie den Wert des Benutzerparameters sofort zu dem Zeitpunkt abrufen oder festlegen müssen, wenn der Code ihn braucht. Darum erleben neue iLogic-Benutzer Probleme beim Ausführen von Regeln, denn sie erwarten ein bestimmtes Verhalten, aber Inventor scheint einem Schritt „hinterher zu hinken“. Sehen Sie sich die folgenden Beispiele an:

cylinderHeight = CylinderHeight
Dim cylinderHeight As Double = Parameter("CylinderHeight")

Beide Anweisungen bewirken ähnliche Dinge, sind aber doch nicht identisch. Das erste Beispiel deklariert eine Variable, die von beliebigem Typ sein könnte, mit einem Wert gleich dem Benutzerparameter. Da die Textfarbe Blau ist, erkennt Inventor den Benutzerparameter. Da Inventor den Benutzerparameter erkennt, wird jede Regel, deren Unterdrückung bei Verwendung dieses Formats aufgehoben wird, automatisch ausgeführt. Vielleicht wünschen Sie, dass Regeln in dieser Weise ausgeführt werden, oder auch nicht.

Das bedeutet auch, dass die Variable auf den Wert des Benutzerparameters zum Zeitpunkt der letzten Aktualisierung gesetzt wird. Wenn die Logik den Benutzerparameterwert zwischen dem Zeitpunkt, zu dem die Variable den Wert benötigt, und der letzten Aktualisierung geändert hätte, wäre der Benutzerparameterwert veraltet. Darum ist eine Aktualisierung erforderlich. Manchmal scheinen sogar zahlreiche Aktualisierungen erforderlich, um das gewünschte Ergebnis zu erhalten.

Es gibt zwei Möglichkeiten, wie Sie damit umgehen können. Erstens können Sie die zweite Anweisung verwenden. Durch das Deklarieren der Variablen, die Typumwandlung und Verwendung der Funktion „Parameter“ legen Sie die Variable direkt auf den Wert des Benutzerparameters fest. Dadurch stellen Sie sicher, dass der Wert auf dem neuesten Stand ist. Darüber hinaus können Sie so besser steuern, wann die Regeln ausgeführt werden. Zweitens können Sie das iLogic-Snippet „RuleParametersOutput()“ verwenden. Dadurch bleiben alle Benutzerparameter immer auf dem neuesten Stand. Führen Sie dann eine Aktualisierung durch, damit die zugeordneten Modelle ebenfalls auf den neuesten Stand gebracht werden.

Gemeinsam genutzte Variablen

Vorhin haben wir Codepraktiken über Variablen erörtert, aber gemeinsam genutzte Variablen sind eine Funktion von iLogic. Wenn wir eine Variable in einer iLogic-Regel deklarieren, ist die betreffende Variable nur innerhalb des Kontexts dieser Regel zugänglich. Wenn Sie eine Variable erstellen und ihren Wert für die Verwendung mit zahlreichen Regeln festlegen müssen, sind gemeinsam genutzte Variablen die richtige Option.

Im Bereich der iLogic-Snippets im iLogic-Regeleditor finden Sie die Funktionen für gemeinsam genutzte Variablen unter dem Variablen-Index.

Zur Verwendung von gemeinsam genutzten Variablen werden wir ähnlich vorgehen wie beim Deklarieren anderer Variablen. Zuerst deklarieren wir die gemeinsam genutzte Variable, definieren einen Namen für sie und geben dann einen Wert an. Dabei kann es sich um einen statischen Wert handeln oder um den Wert einer anderen Variablen, eines Parameters oder einer Eigenschaft.

SharedVariable("VariableName") = "This is the value" SharedVariable("cylinderHeight") = Parameter("CylinderHeight")

Nachdem eine gemeinsam genutzte Variable deklariert und ein Wert für sie angegeben wurde, kann sie nach Bedarf verwendet und aktualisiert werden.

Dim cylinderHeight As Double = SharedVariable("cylinderHeight")

Verwenden Sie die anderen Funktionen für gemeinsam genutzte Variablen, um zu überprüfen, ob eine gemeinsam genutzte Variable vorhanden ist, oder um einzelne oder alle gemeinsam genutzten Variablen aus dem Speicher zu löschen.

Bedingte Ausdrücke und Schleifen

Muss immer der Mensch die Entscheidung treffen?

Bei der normalen Interaktion mit Inventor haben wir den Luxus, dass wir das Grafikfenster betrachten und eine Geometrie auswählen können, um zu entscheiden, was wir damit anstellen möchten. Wir verstehen, wie die Komponenten in einer Baugruppe miteinander zusammenhängen. Wenn wir iLogic-Regeln betrachten, müssen wir manchmal den Entscheidungsweg definieren. Dazu müssen wir die verschiedenen Bedingungen kennen, die bei einer Konstruktion gegeben sein können. Die Verwendung von Ausdrücken, die die verschiedenen Bedingungen definieren, ist eine Möglichkeit, wie Benutzer von iLogic diese Aufgaben erledigen können.

Der häufigste bedingte Ausdruck ist der Wenn-Dann-Ausdruck (If Then). Dieser sieht ungefähr so aus:

If someValue = True Then
'Do Something
Else
'Do Something Else
End If

Im Code achten wir darauf, ob eine Bedingung vorhanden ist. Falls ja, wird der Code eine Aktion auslösen. Wenn die Bedingung nicht vorhanden ist oder wenn eine andere Bedingung vorliegt, wird der Code eine andere Aktion auslösen. Wir können diese Funktion erweitern, um zahlreiche Bedingungen zu berücksichtigen, zum Beispiel:

If someValue = True Then
'Do Something
ElseIf someValue = False Then
'Do Something Else
ElseIf someValue = Nothing Then
'Yet Do Something Else
End If

Dies sieht alles einfach aus und ist völlig einleuchtend. Doch es gibt eine Grenze. Man könnte leicht erwarten, dass die Bedingungen unendlich weitergehen, aber nach einem bestimmten Punkt lässt sich nicht mehr nachvollziehen, was wirklich geschieht. Das gilt vor allem dann, wenn Sie weitere Operatoren hinzufügen. Meiner Ansicht nach sollten Sie es bei drei oder vier Bedingungen belassen. Was darüber hinausgeht, lässt sich mit anderen Methoden besser bewältigen.

Ein weiterer häufiger bedingter Ausdruck ist die Select Case-Methode. Sie funktioniert ähnlich, aber meiner Ansicht nach ist dieser Ausdruck wesentlich leichter zu lesen und zu verstehen, ganz abgesehen davon, dass auch weniger Code geschrieben werden muss. Select Case sieht wie folgt aus:

Select Case someValue
Case True
'Do Something
Case False 'Do Something Else
Case Nothing
'Yet Do Something Else End Select

Und wie Sie sehen, ist diese Methode etwas leichter zu verstehen und kann sehr einfach für die Anzahl der Bedingungen, die Sie womöglich berücksichtigen müssen, skaliert werden.

Eine der grundlegendsten Methoden, die beim Schreiben von Codes angewandt wird, sind Schleifen. Bei dem Beispiel der Iteration durch eine Baugruppe, um die Namen der Instanzen abzurufen, können wir mithilfe von Schleifen alle Instanzen durchgehen, ohne wissen zu müssen, wie viele Instanzen es gibt. Beim Konstruieren von Code und beim Entwickeln von Logik dreht sich alles um die Kenntnis von Mustern, Konsistenz und Vorhersagbarkeit. Es kann gelegentlich Methoden geben, die zur Berücksichtigung von Unvorhersagbarkeiten verwendet werden können. Hierbei handelt es sich um Schleifen. Hier sehen Sie ein Beispiel für „For Next Loop“:

Dim counter As Integer = 3
For t As Integer = 1 To counter
MessageBox.Show("Number of Iterations: " & t)
Next

Im Beispiel haben wir den Ausgangspunkt der Schleife definiert, Nummer 1. Außerdem haben wir den Endpunkt der Schleife definiert, den Zähler mit der Einstellung 3. Das bedeutet, dass die Schleife drei Mal iteriert, um ein Nachrichtenfeld hervorzubringen. Wenn wir den Endpunkt für die Schleife nicht kennen, könnten wir die Elemente in einer Sammlung zählen und dies zu unserem Endpunkt machen. Sehen Sie sich dazu dieses Beispiel an:

Dim items As New List(Of String)
items.Add("Pizza")
items.Add("Sandwich")
items.Add("Milk")
items.Add("Eggs")

For i = 0 To (items.Count - 1)
MessageBox.Show(items(i))
Next

Im Beispiel haben wir eine Sammlung erstellt, diese mit Werten gefüllt und dann die Schleife informiert, dass sie so oft iterieren soll, wie sich Elemente in der Sammlung befinden. Wie Sie sehen, beginnen wir die Schleife bei 0 und beenden sie bei der Anzahl minus 1. Dies ist eine der Situationen, in denen ein Verständnis von der Indexierung wichtig ist. Die Indexierung ist nichts weiter als die Identifizierung eines Ausgangspunkts. In der Regel ist dies entweder 0 oder 1. In dieser Art der Sammlung beginnt das erste Element in der Liste tatsächlich bei 0, nicht bei 1.

Thomas Fitzgerald ist Senior Implementation Consultant und auf Inventor Automation und Data Management spezialisiert. Thomas hat zahlreiche Unternehmen mit IT-Abteilungen ganz unterschiedlicher Größen beraten. Er hat mehr als 20 Jahre Erfahrung in der Anwendung zahlreicher Autodesk-Produkte in der Konstruktionsbranche für Mechanik und Maschinenbau und in der Fertigungsbranche. Thomas ist Autodesk Certified Instructor und Microsoft Certified Systems Administrator.

Sie möchten mehr erfahren? Laden Sie das komplette Handout unter full class handout herunter, um mehr zu lesen.