---

Hallo zusammen,

gerne würde ich automatisch die Komplexität von Bauteilen (Dreh- und Frästeile) ermitteln. Grundgedanken hierzu sind über folgende Eigenschaften die Komplexität in mehrere Stufen zu gruppieren:

Anzahl Bohrungen
Anzahl Gewinde
Anzahl unterschiedliche Gewinde
Anzahl Features
Anzahl Kanten
Kantenlänge gesamt
Rohvolumendifferenz

Natürlich wären auch andere Eigenschaften/ Angaben aus den iProperties denkbar. Für Ergänzungen und Anregungen hierzu wäre ich natürlich dankbar.
Vielleicht hat außerdem schon jemand ein ähnliches Projekt bearbeitet und hat noch einige Gedanken oder Anregungen, wie dieses Problem an sich zu lösen ist.

Vielen Dank im Voraus und viele Grüße
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Etwas ähnliches finden Sie hier:
https://www.cadforum.cz/en/ipart-display-information-about-complexity-of-an-inventor-part-tip13040

V.Michl, www.arkance-systems.cz - www.cadforum.cz

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Klasse! Das geht schon in die richtige Richtung. Einiges davon habe ich auch schon umgesetzt. Danke für den Link.

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@Chris:

Erachtest Du eine Platte mit 500 Gewindebohrungen als komplex?
Wenn ja beschleicht mich das Gefühl das der Begriff "Komplexität" an dieser Stelle unglücklich gewählt ist.
Vielleicht trifft es eher "bearbeitungsintensiv" oder so....

Ich habe vor kurzem in meiner Masterarbeit die Komplexität von 3D-Modellen mathematisch quantifiziert. Hier spielen aber andere Aspekte eine Rolle als beispielsweise die Anzahl der Gewindebohrungen.

Danke und Grüße
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wie so oft im Leben: kommt ganz drauf an 

Wenn es 500 identische Gewindebohrungen sind, ist es bearbeitungsintensiv, allerdings nicht sehr komplex. Je mehr unterschiedliche Gewinde vorhanden sind, desto komplexer wird das Ganze dann.

Welche Kriterien hast du in deiner MA für die Komplexität zugrunde gelegt? Besteht die Möglichkeit an deine MA zu kommen?

Danke im Voraus 

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Chris0804:
Wie so oft im Leben: kommt ganz drauf an  

Wenn es 500 identische Gewindebohrungen sind, ist es bearbeitungsintensiv, allerdings nicht sehr komplex. Je mehr unterschiedliche Gewinde vorhanden sind, desto komplexer wird das Ganze dann.

Welche Kriterien hast du in deiner MA für die Komplexität zugrunde gelegt? Besteht die Möglichkeit an deine MA zu kommen?

Danke im Voraus 

---

@Chris:
Die MA darf ich nicht rausgeben, da sie einen Sperrvermerk hat...
Die Ermittlung der Geometriekomplexität war im Endeffekt ein kleiner Unterpunkt. Der Code läuft jedoch in JavaScript im node.js Framework, so dass es wahrscheinlich sehr schwer ist, es in "Inventor-VBA" zu adaptieren.

Aber inhaltlich kann ich Dir sehr gerne Auskunft geben. Vllt. kannst Du dann selbst davon für Dich relevanten Code extrahieren 

Ein paar Kriterien anhand deren man die "menschlich wahrgenommene" Geometriekomplexität quantifizieren kann:

- Annzahl tangentialer Flächenüberschneidungen
» Je mehr tangentiale Flächenüberschneidungen, desto komplexer

- Oberflächenvariation
» Je mehr Oberflächenvariationen, desto komplexer

- Anzahl der wahrnehmbaren unterschiedlichen Elemente (Kugel - Kaktus - Handrad - Auto)
» Je mehr wahrnehmbare unterschiedlich Elemente, desto komplexer !Wobei unterschiedliche Gewindebohrungen, die Komplexität nicht steigen lässt, da nur ein bis zwei Parameter variieren!

- Anzahl der Symmetrieebenen (Kugel - Handrad - Mensch)
» Je weniger Symmetrieebenen, desto komplexer

- Geometrische Primitive dominierend (Welle - quaderförmiges Fräsgehäuse - Karosserie)
» Je mehr geometrische Primitive die Gesamtgeometrie dominieren, desto geringer ist die Komplexität

- Notwendiger Polynomgrad für die Beschreibung der Kontur
» Je höher der Polynomgrad, desto komplexer

Ein paar Sachen sind vermutlich einfach in VBA zu ermitteln und andere Sachen nur sehr schwer...
*************************************************************************************************

Einen Surrogatparameter, den Du vermutlich leicht ermitteln kannst, wäre die Anzahl der Vertices der Geometrie:
- Körper in ein indiziertes 3D-Netz transformieren, also zum Beipspiel ins OBJ-Format ausleiten
- OBJ-Format einlesen und Anzahl der Vertices auslesen
- Anhand von selbst definierten Schwellenwerten die Geometrie Kategorisieren

Die Oberflächenvariation bekommst Du ebenfalls indirekt über die kategorisierten Linienzüge raus.
Bei gekrümmten Linienzüge kannst Du ermitteln, welchen Ploynomgrad Du benötigst, um diesen mathematisch zu beschreiben.
Stichwörter hierzu NURBS, Gewichtung, Stützstellen
» Falls Du in Sachen NURBS etc. fit bist, kannst Du die Geometrie extrem gut mathematisch quantifizieren!!!

Bei der Anzahl der Symmetrieebenen würde ich vorab prüfen, ob der Massenschwerpunkt weit entfernt vom Nullpunkt ist.
Ist er halbwegs nah dran, kannst Du einfach den Körper entlang der Hauptebenen beschneiden und dann spiegeln. Dann prüfst Du, ob sich der Massenschwerpunkt verschoben hat, Änderung des Gewichts, Änderung der BoundingBox-Größe, etc.
Ist nicht perfekt, aber davon kann man schon was ableiten 

Zusätzlich kannst Du die einzelnen Flächen analysieren... Sind diese im größerem Maße sehr ähnlich (Größe etc.) stellen sie sehr wahrscheinlich ähnliche geometrische Formen dar.

So oder so bleibt Dir eine Segmentierung des Körpers nicht erspart 

Falls Du weitere Fragen hast, beantworte ich Dir die sehr gerne.

Danke und Grüße
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Die MA darf ich nicht rausgeben, da sie einen Sperrvermerk hat...

---

Schade, wär für mich ganz interessant zu lesen 

Danke für deine Hinweise schon einmal. Allerdings ist eine Voraussetzung für die Komplexitätsermittlung für mich, dass das 3D-Modell nicht erst in ein anderes Format exportiert werden soll.

Gerade habe ich aber gesehen, dass ich die Anzahl der Vertices auch mit VBA auslesen kann, meinst du ich kann hiermit schon näher auf die Komplexität schließen?

Die Bauteile sollen auch lediglich in 3 unterschiedliche Komplexitätsklassen im Hinblick auf die Fertigung (Drehen und Fräsen) kategorisiert werden. Von daher ist eine allzu exakte Bestimmung der Komplexität wahrscheinlich auch nicht notwendig.

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@Chris:
Natürlich kannst Du mit der Anzahl der Vertices in VBA auch etwas anfangen.
Analysiere einfach ein paar Teile dann bekommst Du ad hoc ein Gefühl, ob Du mit der Zahl etwas anfangen kannst oder nicht.

Wie willst Du in VBA ermitteln, ob es ein Dreh- oder Frästeil ist?

Kannst Du auch auf andere Daten zugreifen?
Bei uns sind die CNC-Programme in der Datenbank hinterlegt, so dass man diese auch analysieren könnte. Ggf. kann man hier Aussagen ableiten:
- Anzahl der notwendigen Werkzeugwechsel
- ...

Oder ist es da schon zu spät?

Schließe das Konvertieren in ein anderes Format nicht kategorisch aus!
Das geht meist sehr schnell und bringt schon Anhaltswerte.
Insbesondere ASCII-Formate sind hier von besonderem Interesse, da Du sie analysieren kannst...
- Evtl. in STEP ausleiten und die Zahl der Zeilen auslesen
- Evtl. in OBJ ausleiten und die Zahl der Gruppierungen auslesen

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@mb-ing:
Danke für den Hinweis mit den Vertices, das ist tatsächlich ganz hilfreich.

Die Entscheidung ob gedreht oder gefräst wird, macht nacher der Bediener. Auf andere Daten kann ich leider nicht zugreifen, da die zum gewünschten Zeitpunkt noch nicht vorhanden sind.

Mit dem Konvertieren in andere Formate bin ich tatsächlich noch etwas skeptisch. Könnte man dies soweit automatisieren, dass der Bediener nichts umwandeln muss? Also das Umwandlung und Auswertung automatisch passieren? Wenn das so wäre, könnte ich mir das vorstellen, ansonsten wird das eher schwierig.

Auch hierzu, was meinst du wenn du schreibst bei STEP die zahl der Zeilen auslesen? Was geben die Zeilen denn an? Ähnlich ratlos bin ich bei Gruppierungen von OBJ-Dateien   

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Chris0804:
@mb-ing:
Danke für den Hinweis mit den Vertices, das ist tatsächlich ganz hilfreich.

Die Entscheidung ob gedreht oder gefräst wird, macht nacher der Bediener. Auf andere Daten kann ich leider nicht zugreifen, da die zum gewünschten Zeitpunkt noch nicht vorhanden sind.

Mit dem Konvertieren in andere Formate bin ich tatsächlich noch etwas skeptisch. Könnte man dies soweit automatisieren, dass der Bediener nichts umwandeln muss? Also das Umwandlung und Auswertung automatisch passieren? Wenn das so wäre, könnte ich mir das vorstellen, ansonsten wird das eher schwierig.

Auch hierzu, was meinst du wenn du schreibst bei STEP die zahl der Zeilen auslesen? Was geben die Zeilen denn an? Ähnlich ratlos bin ich bei Gruppierungen von OBJ-Dateien    

---

@Chris:
Das Konvertieren in andere Formate und die anschließende Analyse soll natürlich voll automatisiert erfolgen.
Hierzu wirst Du einiges an Code im Internet finden, welchen Du mit moderatem Aufwand an Deine Bedürfnisse adaptieren kannst.

Auf eine einfache Ebene herunter gebrochen, musst Du Metriken finden oder Dir selbst überlegen, mit denen Du Deine Kategorisierung der Bauteile vollführen kannst.
Ich habe mich vor kurzem mit Quellcode-Metriken befasst und hier unter anderem mit dem Maintainability Index. Der Index ist ein zusammengesetzter KPI, bei dem auch die Zeilen an Code gewertet werden...

So jetzt die Brücke zu STEP und der Anzahl der Zeilen der STEP-Datei.
Wenn ich eine STEP-Datei mit vielen Zeilen (Schwellenwert musst Du selbst bestimmen) habe, benötige ich viele Informationen, um die Geometrie zu beschreiben. Dies gibt im gewissem Maße einen Rückschluss, ob es sich um eine komplexe Geometrie handeln könnte.
Analysiere ich zusätzlich noch die Gruppen in der OBJ-Datei, kann man zusätzlich Schlussfolgern, dass sich Flächenelemente "wiederholen".

Stell Dir einfach vor, dass Du eine Geometrie einen Blinden erklären sollst.
Umso mehr Worte Du für die Beschreibung benötigst, umso komplexer ist die Geometrie.
Wobei natürlich eine Platte mit 500 Bohrungen mündlich schnell beschrieben ist, aber die STEP-Datei viele Zeilen haben wird.

Am besten Du nimmst je zwei Modelle von den drei Kategorien und leitest diese im STEP und OBJ Format aus. Den ASCII-Code kannst Du ja dann auf Muster hin untersuchen.
Natürlich gehen auch andere Formate 
Das sind alles nur Anregungen...

VG
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich bin gerade deinem Hinweis gefolgt die Dateien ins Step-Format zu exportieren und habe mir den ASCII-Code angeschaut. Tatsächlich lässt sich ein guter Unterschied für die Komplexität in der Anzahl der Zeilen erkennen. Ich werde hier noch einmal ein paar mehr Bauteile durchgucken und hoffe, dass dies so bleibt. Zum Glück haben wir hier eher weniger Bauteile mit 500 Bohrungen 

Gerade kämpfe ich allerdings wieder mit VBA... zumindest den Export in eine STEP-Datei habe ich schon einmal hinbekommen. Gibt es eine Möglichkeit die STEP-Datei im Hintergrund zu öffnen, die Zeilenanzahl des ASCII-Code auszulesen und mir in eine Variable zu schreiben? Hierzu habe ich im Netz leider bisher nichts gefunden.

Danke bis hierher erst einmal 

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Chris0804:
Ich bin gerade deinem Hinweis gefolgt die Dateien ins Step-Format zu exportieren und habe mir den ASCII-Code angeschaut. Tatsächlich lässt sich ein guter Unterschied für die Komplexität in der Anzahl der Zeilen erkennen. Ich werde hier noch einmal ein paar mehr Bauteile durchgucken und hoffe, dass dies so bleibt. Zum Glück haben wir hier eher weniger Bauteile mit 500 Bohrungen  

Gerade kämpfe ich allerdings wieder mit VBA... zumindest den Export in eine STEP-Datei habe ich schon einmal hinbekommen. Gibt es eine Möglichkeit die STEP-Datei im Hintergrund zu öffnen, die Zeilenanzahl des ASCII-Code auszulesen und mir in eine Variable zu schreiben? Hierzu habe ich im Netz leider bisher nichts gefunden.

Danke bis hierher erst einmal  

---

Zum Ermitteln der Zeilenanzahl der STEP-Datei musst Du diese bzw. die Geometrie nicht im Inventor öffnen.

Suche mal in die Richtung:

Code:

---

Set fso = CreateObject("Scripting.FileSystemObject")
Set theFile = fso.OpenTextFile("C:\Test.stp", 8, True)
WScript.Echo theFile.Line
Set Fso = Nothing

---

Im Endeffekt öffnest Du die Textdatei in einem Editor und zählst die Zeilen...

VG
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Diese alternative Methode wurde in den Tipp aufgenommen:
https://www.cadforum.cz/en/ilogic-display-information-about-complexity-of-an-inventor-part-tip13040

Vladimir Michl, www.arkance-systems.cz - www.cadforum.cz

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@Chris:
Hast Du Dir auch schon das Wavefront OBJ-Format angeschaut?

Der offiziellen Syntax nach gibt es Gruppierungen, um redundante Strukturen zu reduzieren. Daraus könnte man ggf. auch Rückschlüsse ziehen...

Kannst Du mit VBA die Flächennormalen auslesen?

Gibt es bei Euch methodische Vorgaben, dass der Körper nach Möglichkeit symmetrisch in Bezug auf die Basisebenen aufgebaut werden soll?

VG
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@MB-Ing:
Das Auslesen der Zeilen im Step-Format klappt nun, außerdem bildet dieser Wert wirklich schon sehr gut die Komplexität ab. Das werde ich jetzt anhand einer etwas größeren Menge an Bauteile versuchen zu bestätigen. Ggf. reicht diese Angabe für meine Zwecke auch schon aus.

Nichtsdestotrotz werde ich mir auch demnächst das Wavefront OBJ-Format anschauen. Ist die Vorgehensweise hier analog zu dem Auslesen des Step-Dateien? Also auch wieder als Textfile öffnen und die Syntax auswerten?

Bzgl. der Flächennormalen habe ich leider noch nichts gefunden, werde aber auch hier noch weiter probieren. Was genau wäre hier für mich interessant?

Deine Hinweise sind echt Gold wert. Tausend Dank!

Auch Danke an VMichl, zur Formulierung der Lösung war der Verweis in das KonkurrenzForum gut!

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Chris0804:
@MB-Ing:
Das Auslesen der Zeilen im Step-Format klappt nun, außerdem bildet dieser Wert wirklich schon sehr gut die Komplexität ab. Das werde ich jetzt anhand einer etwas größeren Menge an Bauteile versuchen zu bestätigen. Ggf. reicht diese Angabe für meine Zwecke auch schon aus.

Nichtsdestotrotz werde ich mir auch demnächst das Wavefront OBJ-Format anschauen. Ist die Vorgehensweise hier analog zu dem Auslesen des Step-Dateien? Also auch wieder als Textfile öffnen und die Syntax auswerten?

Bzgl. der Flächennormalen habe ich leider noch nichts gefunden, werde aber auch hier noch weiter probieren. Was genau wäre hier für mich interessant?

Deine Hinweise sind echt Gold wert. Tausend Dank!

Auch Danke an VMichl, zur Formulierung der Lösung war der Verweis in das KonkurrenzForum gut!

---

@Chris:

Der Code zum Auslesen der OBJ-Datei ist nahezu identisch, wie der für die STEP-Datei. Du musst theoretisch nur die Dateiendung von *.stp auf *.obj ändern.

Syntax Wavefront OBJ:
https://www.loc.gov/preservation/digital/formats/fdd/fdd000507.shtml
https://www.fileformat.info/format/wavefrontobj/egff.htm

Inventor kann auch andere ASCII-Formate ausleiten, wie beispielsweise IGES, STL etc.. Vllt. kann man aus diesen Formaten ebenfalls Metriken ableiten. Aber mit deren Syntaxen bin ich nicht firm 

Kannst Du mit VBA asynchrone Filestreams erzeugen und verarbeiten?
Ich habe damals die Analyse der ASCII-Formate mit asynchronen Funktionen parallelisiert, was die benötigte Zeit erheblich reduziert hat. Das kann ich Dir wirklich nur empfehlen 
Stichwörter hierzu sind async, await, promise.all

Zusätzlich hatte ich ein Strategiemuster (Strategy-Pattern) implementiert, so dass ich meine "Strategie" / Vorgehensweise zur Laufzeit ohne erneute Kompilierung an den jeweiligen Fall dynamisch adaptieren konnte.
Insbesondere bei der Massenverarbeitung auf Servern ist dies ratsam.

Vielleicht noch als kleine Anregung...
Wenn Dein Algorithmus gute Resultate liefert, werden die Anforderungen rasch ansteigen. Für mein persönliches Dafürhalten wird hier VBA schnell an seine Grenzen kommen und die Zukunftsfähigkeit von VBA ist ebenfalls zu hinterfragen.
Für das .NET-Framework gibt es gute Boilerplate-Codes, die Du als Blaupause verwenden kannst, so dass der Umstieg hierauf mit geringem Aufwand machbar sein sollte. Ob Du dann C# oder VB verwendest ist meines Erachtens völlig sekundär 
Wobei VBA und VB von der Syntax wirklich sehr ähnlich sind. (C# ist nur meine persönliche Vorliebe...)

Ich habe aber bis jetzt nicht richtig verstanden, was Du mit der Ermittlung der Komplexität erzielen willst!?
Willst Du "bearbeitungsarintensive" Teile für die Kalkulation erkennen?
Wenn mir das klarer wäre, könnte man ggf. auch anderen zielführende Ansätze diskutieren 

Es freut mich, dass Dir meine Ausführungen helfen.
Für Fragen stehe ich gerne zur Verfügung.

Danke und Grüße
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Ich habe aber bis jetzt nicht richtig verstanden, was Du mit der Ermittlung der Komplexität erzielen willst!?
Willst Du "bearbeitungsarintensive" Teile für die Kalkulation erkennen?
Wenn mir das klarer wäre, könnte man ggf. auch anderen zielführende Ansätze diskutieren 

---

Ich schreibe gerade meine Masterarbeit in einem Unternehmen. Unter anderem ist die Aufgabe bearbeitungsintensive Bauteile zu einem frühen Zeitpunkt der Entwicklung automatisiert zu ermitteln, sodass mögliche konstruktive Änderungen frühzeitig angeregt werden können und um später auch eine Kostenabschätzung mithilfe dieses Komplexitätsgrads machen zu können.

Ich habe auch schon darüber nachgedacht auf andere Programmiersprachen umzusteigen, allerdings bin ich dazu nicht tief genug in der Materie drin um eine Kosten-Nutzen-Abschätzung zu machen. Mein Projekt wird in knapp zwei Monaten abgeschlossen, sodass ich nicht weiß, ob sich ein Umstig (für mich) noch lohnt. Andererseits wäre es für nachfolgende Bearbeiter dieser Aufgabe vielleicht einfacher...
Ein weiteres Arbeistpaket in meinem Projekt ist, eine möglichst anwenderfreundliches Ergebnis zu entwicklen. Also falls ich irgendwann nicht mehr als Ansprechpartner hier vor Ort bin, soll das Programm einigermaßen verständlich und wartungsfreundlich sein. Vielleicht kannst du mir auch hier einen Ratschlag geben, ob sich ein Umstieg im Hinblick auf diese Aspekte doch noch lohnt. 

------------------
Gruß
Chris

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@Chhris:

Wer konstruiert die Teile?

Der MA in der KO kann ja am besten beurteilen, ob es sich um ein "bearbeitungsarintensives" Teil handelt!?
Kann der Mitarbeiter diese Attribut nicht ad hoc in die Meta-Daten schreiben bzw. schreiben lassen!?
Ein Knopf erstellen, der mittels einem Mini-Programm ein I-Property befüllt.
Die I-Properties kannst Du dann entweder in einer DB analysieren oder man durchforstet mit dem Apprentice-Server Verzeichnisse nach den I-Properties.

Ich dokumentiere meinen Quellcode mit DocFX. Das erzeugt mittels XML-Tags statische HTML-Seiten, in denen man komfortabel navigieren kann. Zusätzlich wird die Dokumentation in IntelliSense integriert, was wirklich super und mega hilfreich ist! Das möchte ich nicht mehr missen 
https://dotnet.github.io/docfx/tutorial/docfx_getting_started.html

Dein Projekt hast Du ja normalerweise in einem versionsgeführten Repository, welches man beispielsweise mit einer Bash-Emulation ansteuert. Hier gibt es üblicherweise eine *.md (MarkDown) Datei mit einer rudimentären Gesamt-Doku, die mehr oder weniger gut gepflegt ist 

Meines Erachtens ist die saubere Dokumentation direkt im Quellcode am wichtigsten. Zusätzlich erstellt man oftmals UML-Diagramme und ein Ablaufdiagramm... Das reicht meistens. Die Historie der Codeänderungen kann man im ausreichendem Maße über die Commits im repos nachvollziehen.

VG
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Theoretisch könnte man indirekt das Zerspanvolumen ermitteln.
Die Bounding-Box auslesen und deren Volumen berechnen. Hiervon das Volumen des Bauteils abziehen. Ein große Differenz kann auf ein großes Zerspanvolumen hindeuten.
Ist natürlich ein sehr vereinfachter Ansatz, aber wäre mal lustig, das für einige Bauteile zu ermitteln... 

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja, der MA kann das schon beurteilen, allerdings wäre es schön, wenn das Programm automatisch eine Vorauswahl zur Komplexität gibt und der MA dann ggf. manuell nachsteuern kann.

Zur Dokumentation: funktioniert DocFX auf mit VBA? Dazu konnte ich leider noch nichts finden. Bisher habe ich auch mMn ganz gut im Quellcode kommentiert (am Anfang hauptsächlich für mich, sodass ich den Code auch als Laie später noch lesen kann  

Kannst du mir zu den UML-Diagrammen bzw. Ablaufdiagrammen zufällig Literatur oder eine gute Quelle empfehlen?

Zitat:

---

Theoretisch könnte man indirekt das Zerspanvolumen ermitteln.
Die Bounding-Box auslesen und deren Volumen berechnen. Hiervon das Volumen des Bauteils abziehen. Ein große Differenz kann auf ein großes Zerspanvolumen hindeuten.
Ist natürlich ein sehr vereinfachter Ansatz, aber wäre mal lustig, das für einige Bauteile zu ermitteln... 

---

Genau das mache ich auch schon. Die Idee ist, über das Zerspanvolumen bzw. die Rohvolumendifferenz eine Kostenabschätzung zu machen und diese wiederum mit der Komplexität und einigen anderen Faktoren zu verknüpfen.

------------------
Gruß
Chris

[Diese Nachricht wurde von Chris0804 am 01. Sep. 2021 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Chris0804:
Ja, der MA kann das schon beurteilen, allerdings wäre es schön, wenn das Programm automatisch eine Vorauswahl zur Komplexität gibt und der MA dann ggf. manuell nachsteuern kann.

Zur Dokumentation: funktioniert DocFX auf mit VBA? Dazu konnte ich leider noch nichts finden. Bisher habe ich auch mMn ganz gut im Quellcode kommentiert (am Anfang hauptsächlich für mich, sodass ich den Code auch als Laie später noch lesen kann   

Kannst du mir zu den UML-Diagrammen bzw. Ablaufdiagrammen zufällig Literatur oder eine gute Quelle empfehlen?

Genau das mache ich auch schon. Die Idee ist, über das Zerspanvolumen bzw. die Rohvolumendifferenz eine Kostenabschätzung zu machen und diese wiederum mit der Komplexität und einigen anderen Faktoren zu verknüpfen.

---

DocFX kann über den NuGet Package Manager in Visual Studio bezogen werden. Wobei ich nicht weiß, ob man in Visual Studio VBA-Code für Inventor debuggen kann  Aber ich glaube eher mal nicht...
Wenn VS die VBA Syntax unterstützt, könnte man VS für die Doku nachträglich missbrauchen. Weiterhin kann man mit VS Quellcodemetriken ermitteln lassen, was sehr interessant sein kann...

Zum schnellen Einstieg ist für UML-Diagramme etc. das Buch "Die UML-Kurzreferenz 2.5 für die Praxis kurz, bündig, ballastfrei" von B. Österreich und A. Scheithauer zu empfehlen.

Ich würde in der DB auch das Feld "Kopie von" auslesen und dessen berechneten Index heranziehen. Es wird schon einen Grund haben, warum das Modell kopiert worden ist!?
~70-80% sind Variantenkonstruktionen, oder?
Also sollte man bereits validierte Ergebnisse nicht außer Acht lassen...

VG
MB-Ing.

------------------
Wissen ist Macht. Nichts wissen macht auch nichts 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP