OS - CAD

Hallo Allerseits

An dieser Stelle möchte ich mal eine kleine Diskussion zum Thema CAD anstoßen, weil ich bislang keine Aussage finde, wie wir bezüglich CAD umgehen sollen. Mir fehlt da bislang eine gewisse Vereinbarung auf einen Standard, sowie eine Art Anleitung, wie ich als Newbee vorgehen kann um …

  1. das richtige Programm bzw. Format zu verwenden, damit andere Entwickler meine Teile und Konstruktionen auch selbst verwenden können (OS-Gedanke) → Ansatzpunkt evt. FreeCAD (.step) ??

  2. vielleicht bereits vorhandene Teile finden zu können, um Doppelarbeit zu verhindern → Ansatzpunkt evt. Teile im Wiki unter einen extra-Namensraum hochladen und dadurch eine Art Library zu erstellen, mit einfacher Kategorisierung sowie bildlichen Darstellungen.

  3. finde ich kein passendes Teil, wie ich Teile selbst und möglichst genau und nachvollziehbar erstellen kann → Ansatzpunkt evt. Makro/Scripts nutzen, Scripts für bestimmte Objekte als Beispiel vorgeben?

  4. wo ich nützliche Informationen / Tipps und Tricks zum vereinbarten CAD-Tool finden kann. → Verlinkung zu Hilfeseiten, Tutorials, usw.

  5. welche Möglichkeiten es gibt, wenn man andere (kommerzielle) CAD-Tools nutzen möchte → Ansatzpunkt Import-/Exportfunktionalitäten, Konvertierungsmöglichkeiten, usw.

Was mir vorschwebt ist eine Seite im Wiki, welches einen gewissen Standard definiert und als Anlaufpunkt für alle CAD-Nutzer dient.
Das muss an sich nicht zu kompliziert sein, sondern einfach eine klare Aussage und Anlaufstelle zum Thema CAD sein, denn momentan weiß ich nicht, wie ich mit dem Thema CAD umgehen muss, worauf ich achten muss und wo ich meine Teile ablegen sollte, so dass sie auch gefunden werden können (nicht nur auf der Seite, wo sie verwendet werden).

TF

Hi Sebastian,

Ein sehr berechtigte Anstoß !

Ich hab dazu insbesonders in den letzten Wochen und Monaten einige Erfahrungen sammeln können (read: bin durch die Hölle gegangen :wink:) und möchte hier meinen bisherigen Eindruck von der Sache wiedergeben. Erstmal vorweg: Es existiert bislang noch keine umfassende Gesamtlösung und die Sache ist etwas komplexer, als es auf den ersten Blick den Anschein hat. Wobei ich noch voraussetzen möchte, dass sich das nachfolgende explizit auf OpenSource bezieht.

Anfänglich hatte ich Sketchup verwendet, weil das relativ easy für Anfänger zu sein und somit eine schnelle Umsetzungsmöglichkeit grad für den Anfänger zu sein schien. Aber damit hatte ich ein „ideologisches“ Problem, denn Sketchup ist Google (read: dark evil forces :wink:), nicht Open Source und nicht als Linux-Version verfügbar. Immerhin kann man es dennoch mit Wine-Emulation unter Linux relativ gut nutzen - gaaanz selten gibts mal nen Absturz, aber das bleibt im Rahmen des Erträglichen.

Das man mit Sketchup sehr gute und ansprechende Ergebnisse erzielen kann, wurde im Netz bereits zig-fach bewiesen, exemplarisch seien hier folgende Links aufgeführt:

  1. Die ganzen Baupläne auf woodgears.com, siehe zB. folgender Link:
    http://woodgears.ca/sander/plans/index.html

  2. ein 3D-Drucker namens Lautr3k (und nebenbei ein Beispiel für was ich als wirklich gute Dokumentation erachte - soo sollten m.E. alle OSEG-Projekte dokumentiert sein!!!) :
    http://reprap.org/wiki/Lautr3k_Build_Manual

Soweit so nice, wenn da nicht auch unsere Ideologie als OpenHardware-Truppe wäre :wink: Interessanterweise scheint OSE-US vor dem gleichen Dilemma zu stehen; da die natürlich wesentlich pragmatischer sind wurde dort bislang das Meiste mit Sketchup gemacht - und obwohl ich das anfangs etwas überheblich belächelt habe kann ich inzwischen sehr gut nachvollziehen wiso … allerdings, soweit für mich erkennbar, würden die eigentlich auch lieber und vermutlich aus den gleichen Gründen wie wir zu FreeCad und Co. wechseln und tuen m.E. auch ihr Bestes um sich dem stärker zu öffnen. Eigentlich liegt für uns die Zukunft darin - theroetisch zumindest, aber kommen wir nun zum Eingemachten :wink:

  1. das richtige Programm bzw. Format zu verwenden, damit andere Entwickler meine Teile und Konstruktionen auch selbst verwenden können (OS-Gedanke) → Ansatzpunkt evt. FreeCAD (.step) ??

Theoretisch ja, d.h., ja zu FreeCad (dazu gleich mehr) und auch ja zu .step, welches von allen möglichen Formaten noch am ehesten eine halbwegs „naturgetreue“ Wiedergabe (beim ex- und importieren in andere Programme) zu gewährleisten scheint - erste Erfahrungen konnte ich dazu mit den von Mike (vermutlich mit einem kommerziellen CAD-Programm) erstellten UniProKit-Library-Teilen machen - .step war auch imstande, die Farben zu transportieren, demgegenüber die .igs-Variante aber nicht. Dieser Anfangsverdacht hat sich bei mir inzwischen auch bei anderen „Verrenkungsübungen“ bestätigt.

Das mag was damit zu tun haben, das .step sozusagen ein „strukturiertes“ Dateiformat ist - etwa im Gegensatz zu einem rein „Mesh“- orientierten (also ein simples Array aus Punkten, Kanten und daraus resultierenden Flächen) wie .stl. Bezüglich „strukturiert“ und „naturgetreu“ habe ich mit .wrl (sprich VRML-Dateiformat) allerdings noch bessere Erfahrungen gemacht, (also z.B. beim übertragen von FreeCad-Dateien nach Blender) aber das mag subjektiv sein; ich bin ein alter VRML-Fan, weil ich darüber mal ein Buch geschrieben habe (und auch aus anderen Gründen :wink:), jedenfalls speichere ich in der Praxis, wenns sich um eine wirklich wichtige Datei handelt, die ich (etwa nach Blender) übertragen möchte standardmässig in folgenden Formaten ab: .step, .stl, .wrl und speziell im Hinblick auf Blender manchmal noch im .obj-Format - wobei bei zumindest mir bislang in Härtefällen .wrl meist der Sieger war :wink:

Was mich auch nicht soo sonderlich wundert.

Bei Blender weiss ichs nicht so genau, aber zumindest bei FreeCad definitiv: Diesen Programmen liegt die ursprünglich von SGI (Sillicon Graphics) entwickelte (Open-)Inventor-Technologie zugrunde (die sich etwa in der „Coin“-Library manifestiert) und letztlich auf einem sogenannten „Scene-Graph“-Konzept basiert, welches (lass mich nicht lügen) übrigends auch dem OpenGL entspricht, also dem „Hardware-Layer“, welches z.B. in den 3D-Beschleunigern der ganzen Grafik-Karten implementiert ist, zugrunde liegt.

Dabei handelt es sich (im Gegensatz zu einem Mesh-Format) um eine abstrahierte und damit wesentlich Daten-reduzierte (und objektorientierte) Darstellungsweise eines Objektes (respektive einer ganzen virtuellen Welt), d.h., ich kann einen Würfel mit 8 x 3 = 24 Daten beschreiben, nämlich Anzahl Eckpunkte mal x, y, und z-Koordinate, oder in abstrahierter Form mit lediglich 3 Daten, nämlich Länge x Breite x Höhe.

Kein großes Wunder also, das VRML (bzw. das .wrl-Format) hier die Nase vorn hat, es wurde nämlich ursprünglich als Datenformat zur Übertragung von virtuellen Welten via Web (also durch einen schmalen Bandbreiten-Kanel ==> damals! und auf (ebenfalls damals!) noch nicht so hochentwickelten 3D-Grafikkarten) entwickelt und orientierte sich dabei massiv an Inventor bzw. dem Scene-graph-Konzept.

OK, ich hab mich grad etwas im Detail verloren, bezüglich der Praxis speichere ich es jedenfalls in den genanten Formaten (.step, .stl, .wrl und ev. noch .obj für Blender ab) und schau dann, welches nach dem Re-Import am ehesten den Tatsachen entspricht.

Kommen wir nun zum Eingemachten, nämlich FreeCad.

Von der Ideologie, also dem OpenSource-Gedanken her, unzweifelhaft DAS Mittel der Wahl.

In der Praxis siehts allerdings eher „Mau“ aus, wobei allerdings auch dies nicht ganz ohne Einschränkung.


Die Krux ist in etwa folgende:

FreeCad basiert im Kern auf OpenInventor und dieser Kern ist, da langjährig und professionell entwickelt, valide.


FreeCad selbst kann man also am ehesten als eine Art graphischen Front-Ends betrachten, welches bestimmte Aktionen oder Manipulationen auf diesem Kern (bzw. dem Scene-Graph oder einem darin enthaltenen Objekt) executed.,

Dazu bedient es sicht zumeist der Python-Script-Sprache, d.h., wenn Du einen Button klickst, dann wird intern eine Aktion performed, welche ein entsprechendes Python-Script triggert, das wiederum auf den validen OpenInverntor-Kern zugreift und die Sache in die Tat umsetzt.
Ich schätze, die ursprüngliche Idee hinter FreeCad war, das wenn diese Art von Python_scripting sehr gut unterstützt würde, so nach und nach eine motivierte Community alle für ein gutes CAD-Prg. benötigten Funktionen implementieren würde. D.h., das Scripting ist wirklich sehr gut unterstützt, Du hast zB. ein Command-Line-Interface plus einige Optionen um spezifische Scripte, sprich Makros, gut zu verwalten. Oder anders gesprochen: Der User bastelt sich für eine häufig benötigte Funktion ein Makro/Python-Script, fügt früher oder später ein passendes Icon/Button hinzu, und - schwupps - hat FreeCad eine neue Funktionalität. :wink:
Nett gedacht und gut in die Tat umgesetzt - dennoch, die Praxis sieht leider anders aus. Zum einen vermute ich, dass die Entwicklung nachwievor lediglich auf einigen wenigen Schultern ruht und der beabsichtigte Selbstläufer-Effekt sozusagen ausblieb. Zum andern sind zumindest die komplexeren Sachverhalte eines Scene-graph-Konzeptes nicht immer ganz so easy (oder gar völlig unmöglich) in ein einfaches Script zu pressen.

Kein Zweifel: FreeCad wird seinen Weg machen - einfach schon, weil es keine brauchbare Alternative gibt (im OpenSource- bzw. Linux-Bereich). Aber ebenso sicher bin ich, das dies wohl noch etliche Jahre dauern wird ehe was halbwegs stimmiges/komfortables dabei rauskommt - wobei ich hinzufügen möchte das CAD-Programme allgemein eine uuunglaublich komplexe Materie darstellen. Und das im Linux-Bereich sowas bitter dringend benötigt wird - ansonsten gibts ja so ziemlich für alles eine - meist bessere OpenSource-Alternative - nur eben hier grade nich :wink:

Um dies alles quasi auf den Punkt zu bringen:

FreeCad ist (bislang) ein mehr oder weniger lausiges graphisches Front-End, für einen aber ansonsten absolut stabilen graphischen Kern.

Was in der Praxis bedeutet: Du hast ne durchaus realistische Chance, brauchbare Resultate rauszukriegen, solange Du direkt auf den Kern zugriefst, nämlich via Python-Scripting. Das ist auch der einzige Grund, warum man das Ding nicht gleich vollends in die Tone tritt. :wink:

Aber wenn Du Dich auf das Front-End verlässt, bist Du verratzt und verraten. Einge große Anzahl von Dingen funktionieren einfach nicht wie sie sollen - oder was sie dem „Verpackungsaufdruck“ nach zu versprechend scheinen - oder eben nur auf der Ebene einfachster graphischer/primitiver Objekte - aber sobald es sich um komplexere Operationen oder Sachverhalte handelt - Fehlanzeige. Wir sprechen hier von Dingen wie Assembly- oder auch Grouping-Funktionalität, wenn man im Kleingedruckten nachliest, geben die Entwickler auch zu das sowas bislang noch nicht unterstützt wird, gleichwohl die entsprechenden Buttons oder Icons aber bereits vorehanden sind (was nicht unbedingt negativ gemeint ist - man weiss wo man hinwill :wink:)

Was, um das Maß vollzumachen, die Sache noch zusätzlich erschwert: FreeCad ist, obwohl es auf den ersten Blick anders zu sein scheint - wirklich lausig dokumentiert. Was ich als selbst Entwickler durchaus nachvollziehen kann, aber es erschwert die Sache für Otto-Normaluser halt unendlich.
Und das schliesst insbesondere die Api-Dokumentation mit ein, soll heissen, selbst wenn ich gutwillig bin und mich auf Ebende des Python-Scripting (also auf der relativ sicheren Seite) bewegen möchte, hab ich kaum eine wirkliche Chance, ausser ich bin OpenInventor/Coin-Experte.

OK. Nach all dem Negativen (hat vielleicht auch bei mir was mit Frust ablassen zu tun) jetzt noch etwas Konstruktives/Praktikables (denn ich WILLL ja eigentlich FreeCad ausdrücklich NICHT in die Tonne treten):

Was sich in der Praxis als halbwegs brauchbarer Workflow erwiesen hat, ist folgendes:

\

  1. FreeCad ist halbwegs brauchbar zur Erstellung von Einzel-Objekten (mit ein paar Abstrichen)

  2. Ex- und Im-portiere diese als .step, .stl, .wqrl oder .obj-Datei nach Blender - vielleichtr hast du Gkück und es klappt :wink:

  3. Vermeide dabei "Boolsche-Operationen. Wenn Du ein Bohrloch erzeugen willst, substrahiere NICHT einen Zylinder vom zu bohrenden Objekt - das wird beim Re-Import garantiert nicht funktionieren. Erzeuge stattdessen auf der jeweiligen Fläche ein Sketch und erzeuge das Loch mittels Sketch–>Circle und mittels „Tasche“ oder „Pad“ - und erzeuge für jede Fläche jeweils ein eigenes oder besser noch mehrere Sketches. Auch ist es sinnvoll, wenn das Objekt ursprünglich als Sketch mittels Austragung erzeugt wurde, anstatt etwa einen soliden Körper zu verwenden und auf dessen Flächen Sketches zu projizieren - das ist noch zu buggy.

  4. Wenn Du Dich auf der sicheren Seite bewegen willst, erzeuge Deine Objekte per Skript/Macro. Das ist zwar etwas aufwendiger und zeitraubender, aber hat den Vorteil, dass du direkt auf den (validen) Kern zugreifst. Desweiteren ist es „parametrisch modifizierbar“, d.h., wenn Du z.B. diverse Winkelprofile für die UniProKit-Library erstellen möchtest, kannst Du hier die Sache so gestalten/programmieren, dass Du lediglich die Anzahl der Löcher vorgibst - und es erzeugt Dir das entsprechende Bauteil.

  5. Dies setzt natürlich grundlegende Programmier-Kenntnisse voraus, aber beschleunigt und flexibilisiert mache Aufgaben enorm - besonders wenns um mehrere Varianten von einunderselben Sache geht.

  6. Exportiere zum assemblieren Deine Objekte nach Blender. Vorzugsweise im .stl-Format (da Blender stark Mesh-orientiert ist), alternativ als .step, .wrl oder .obj-Format - je nachdem was die besseren, sprich naturgetreueren Ergebnisse zeigt. Bonus: In Blender kannst Du auch ein schickes Rendering realisieren.

  7. Dimensionierungen/Bemaßungen für eine Fertigungszeichnung sind in FreeCad prinzipiell möglich, indem sie interaktiv in der passenden Ebene generiert werden, aber erfordern ev. noch „manuelle“ Einzelanpassungen, welche wiederum einfacher möglich sind, wenn Du Dich auf der Python-Scripting-Seite bewegst. Alternativ dazu kannst Du noch die (automatischen) Bemaßungs-Funktionen eines Sketches nutzen (und dann davon einen Screenshot machen), wobei diese den Nachteil haben, dass sie stark redundant sind. Du kannst diese Redundanz etwas durch Dragging der Maßpfeile reduzieren. Das Ganze sieht dan optisch nichjt besonders toll aus und ist kein Vergleich mit einer richtigen 2D-Fertigungszeichnung, aber man kann in der Praxis damit arbeiten.

  8. Die einzelnen Objekte dann am besten nach Blender importieren und dort die Assemblierung vornehmen. Assembly- und Grupperungs-Funktionen sind in Freecad zwar schon vorgesehen aber funktionieren dort noch nicht.


    OK, soviel, um einen ungefähren Eindruck zu geben, die ganzen Verrenkungen kann man sich natürlich sparen, indem man gleich Sketchup verwendet, es lohnt sich aus meiner Sicht also, beide Wege zu lernen. Ich weiss nicht genau wie es bei Sketchup mit den Export-Funktionen aussieht, die gibt es zwar, aber ich glaube nur in der kommerziellen Sketchup-Version. Für .stl- gibts m.E. auch freie Export-Module aber bei den anderen Formaten weiss ichs nicht.

FreeCad könnte in der Zukunft mal brauchbar werden, imMoment ists stark davon abhängig, was man da jeweils genau machen will. Wenn man das Programm gut kennt hat man ne gewisse Chance, vorab einschätzen zu können was geht, aber wenn nicht wird man oft erleben, das eine Funktion zwar bereits vorhanden ist, aber einfach nicht das hält was sie verspricht bzw. schlichtweg fehlerhaft ist - was aber m.E. ausschliesslich am Frontend liegt, der Kern dürfte wie oben erläutert ok sein - was wiederum eine gewisse Hoffnung für die Zukunft unterstützt.

Soweit meine Eindrücke und Einsteiger-Erfahrungen, die natürlich sehr subjektiv sind, vielleicht kann jemand anders hier, der auch schon mit FreeCad gearbeitet hat (z.B. Achmed?) das bestätigen - oder auch nicht. :wink: Ich werde aber auch weiterhin versuchen, die Kombination FreeCad/Blender zu verwenden und hoffe, das es mit der Zeit besser wird, wenn ich mich da noch besser reinfinde. Aber desweiteren wird für mich auch Sketchup, dem ich eigentlich innerlich schon fast „Tschüss“ gesagt hatte, eine ernstzunehmende Option bleiben, zumindest solange sich FreeCad noch in diesem frühen Entwicklungsstadium befindet.


  1. vielleicht bereits vorhandene Teile finden zu können, um Doppelarbeit zu verhindern → Ansatzpunkt evt. Teile im Wiki unter einen extra-Namensraum hochladen und dadurch eine Art Library zu erstellen, mit einfacher Kategorisierung sowie bildlichen Darstellungen.

Diesen Satz verstehe ich nicht ganz, bzw. das ist doch eigentlich genau das was die UniProKit-Library erfüllen soll ?


  1. finde ich kein passendes Teil, wie ich Teile selbst und möglichst genau und nachvollziehbar erstellen kann → Ansatzpunkt evt. Makro/Scripts nutzen, Scripts für bestimmte Objekte als Beispiel vorgeben?

Diesen Satz verstehe ich auch nicht ganz :wink: hast Du Dich vertippt und meintest „finde ich kein passendes Tutorial“ ? Ansonsten kann ich dazu noch sagen, das das Phython-Scripting in FreeCad/Blender meiner meinung nach allererste Wahl ist um Library-Bauteile zu erstellen, denn zum einen kannst Du sie leicht modifizieren im Falle von Fehlern oder nachträglichen Verbesserungen eines Bauteils und zum anderen kannst Du damit auch sehr schön Bauteil-Serien programmieren, also sowas wie z.B. die gelochten Alu-Winkel: Eigentlich immer das gleiche Teil, aber halt unterschiedliche Längen und Anzahl Löcher. Mit einem Skript kannst Du hier viel Zeit sparen als wenn Du die teile alle einzeln und händisch konstruieren würdest. Ebenso kannst viel Zeit sparen indem Du für ein neues Objekt auf ein Skript eines und sei es auch nur teilweise ähnlichen (bereits vorhandenen) Objektes zugreifst und das modfizierst. Allgemein ist das Skripting aber natürlich deutlich zeitaufwendiger als das händische und interaktive Konstruieren. Postiv ist desweiteren noch, dass Du Dich dabei, wie oben schon erläuterst, auf der Seite des validen Kerns bewegst und die oben geschilderten Probleme beim interaktiven konstruieren damit entfallen.


  1. wo ich nützliche Informationen / Tipps und Tricks zum vereinbarten CAD-Tool finden kann. → Verlinkung zu Hilfeseiten, Tutorials, usw.

Es gibt zu FreeCad schon ein paar Tutorials die einen gewissen Einstieg ermöglichen, aber insgesamt und vor allem wenns ans Eingemachte geht, ist die Dokumentations-Lage mehr als dürftig. Bei Blender hingegen gibts eine wirklich seeehr umfassende Dokumentation, hier ist allerdings das Problem, das sich ein Grossteil an Doku noch auf die ältere 2.4x-version bezieht und sich inzwischen wohl einige grundlegende Dinge stark verändert haben. Für die aktuelle Version gibts aber zumindest auch Einiges an Doku, zumindest wesentlich mehr, als im Vergleich mit FreeCad. Ausserdem gibts eine hochentwickelte Blender-Community - bei FreeCad eher nicht so.


  1. welche Möglichkeiten es gibt, wenn man andere (kommerzielle) CAD-Tools nutzen möchte → Ansatzpunkt Import-/Exportfunktionalitäten, Konvertierungsmöglichkeiten, usw.

Ein paar Namen die mir einfallen sind AutoCAD, Solidworks, Catia, aber manmuss ich auch fragen unter welchem Betriebssystem die laufen sollen. Für mich persönlich kommen nur Linux-Programme in Frage, aber ich hab auch eh kein Geld für kommerzielle CAD-Software :wink:

Eine sehr gute Alternative scheint mir hier noch VariCAD zu sein, mit dem ich auch schonmal gearbeitet bzw. es ausprobiert habe. Obwohl kommerziell gibt es da eine freie Probe-Version, bei der lediglich der Export blockiert ist. Aber zumindest kann man sich so schonmal einen Eindruck von dem Programm machen. Und ich glaube es ist auch nicht soo teuer, insbesondere mit Studenten-Rabatt.

Achja, solange Du lediglich in 2D arbeitest wäre natürlich noch QCad zu nennen, aber m.E. ist 3D-Funktionalität heute schon irgendwie ein muss.

Eine gute Übersicht darüber was es im Linux-Bereich gibt findest Du unter http://wiki.ubuntuusers.de/CAD


Was mir vorschwebt ist eine Seite im Wiki, welches einen gewissen Standard definiert und als Anlaufpunkt für alle CAD-Nutzer dient.
Das muss an sich nicht zu kompliziert sein, sondern einfach eine klare Aussage und Anlaufstelle zum Thema CAD sein, denn momentan weiß ich nicht, wie ich mit dem Thema CAD umgehen muss, worauf ich achten muss und wo ich meine Teile ablegen sollte, so dass sie auch gefunden werden können (nicht nur auf der Seite, wo sie verwendet werden).

Tjaa, Du kannst gern dieses Posting hier von mir als Grundlage für diese WIKI-Seite verwenden :wink: Ev. gibts in manchen Punkten von Experten noch anderweitige Auffassungen, aber das kann man ja dann da einarbeiten.

Prinzipiell wichtig erscheinen mir die Dateiformate als zentrale Schnittstelle und Bindeglied zwischen beliebigen CAD-Programmen, da mag dann jeder nehmen was ihm am besten gefällt und das Ganze reduziert sich dann nur noch auf die Frage, wie gut und sauber diese File-Formate von einem jeweiligen Programm tatsächlich unterstützt werden - wozu man dann je nach Erfahrungswerten entsprechende Infos ergänzen kann, so wie ich das hier für Freecad getan habe.


Einzelbauteile sollten in der UniProKit-Library abgelegt werden und durch den Katalog sowie die BauteileNummern in BOM-Listen zu einem jeweiligen Projekt navigierbar bzw. auffindbar sein.

Assemblies / Baugruppen sollten zumindest auf der Verwendungsseite (sprich: Projektseite) und einer Beschreibungsseite des jeweiligen UniProKit-Sets enthalten sein und können je nach Komplexitätsgrad, ebenfalls in den Katalog mitaufgenommen werden, d.h., für einen universell verwendbaren Lineartrieb würde dies Sinn machen, für einen ganzen 3D-Drucker dagegen wohl eher nicht.

Gruss, Oliver

Danke Oliver für deine umfassende Berichterstattung zum Thema.

Eigentlich finde ich das Prinzip „Scripting“ gar nicht so falsch und eigentlich effektiver, wenn man die anfängliche Hürde genommen hat.
Schaue man sich u.a. LATEX an, da verwendet man wenn man so will auch Scripte um daraus ein Dokument zu generieren und was hätte ich nur ohne LATEX bei meiner Bachelorarbeit gemacht.

Meine Idee wäre es, dass man bezüglich FreeCAD eine Sammlung von Scriptbeispielen erstellt und der Anwender diese Scripte nutzen und für seine Zwecke entsprechend anpassen oder kombinieren kann. Vielleicht könnte man damit auch FreeCAD etwas mehr Dynamik verleihen, wenn man die Möglichkeiten über Scripte aktiv nutzt und dem Anwender die Hürde der anfänglichen Komplexität etwas nimmt.

Ansonsten kann man die von dir genannten Wege ja als weitere Alternative zu FreeCAD aufzählen.

Ich denke ich werde demnächst mal eine Seite erstellen und anfangen paar Informationen zusammen zu tragen.
Da ich selbst mit FreeCAD auch noch nicht so viel gemacht habe, ist es letztendlich in meinem eigenen Interesse, FreeCAD in seinen wenn auch etwas erschwerten Möglichkeiten kennenzulernen.

Das mit dem LaTex ist ein gutes Beispiel, hab zu Uni-Zeiten auch viel damit gemacht und verwende dafür, genau auch wie für html-Code, eigentlichniemals ein IDE sondern mache lieber alles von Hand, weil das für mich effektiver ist.

Das ist m.E. ein guter Ansatz und ich stelle gerne die Scripte, die ich unter
https://discourse.test.opensourceecology.de/t/automatisch-uniprokit-library-generieren/519/1 schon vorgestellt habe, dafür zur Verfügung.

Beim Scripting gibt es eigentlich nur ein unangenehmes Haupthinderniss, und das ist die extrem dürftige, unzureichende und unvollständige API-Dokumentation.

Einziger Lichtblick dabei ist die recht gut in Freecad integrierte Makro-Funktionalität und die Python Console.

Damit hast Du die Möglichkeit, quasi durch ausprobieren rauszufinden, was die die API-Referenz verschweigt. Du klickst einfach nen Button oder machst irgendeine Aktion, und im Konsole-Fenster wird Dir genau angezeigt, welcher Python-Code aus Deiner Aktion generiert wurde und von FreeCad intern ausgeführt wurde. Damit hat man ne gewisse Chance, herauszufinden und zu erraten, wie die API funktioniert.

Du kannst auch jederzeit eine Folge von Aktionen beim manuellen/interaktiven Erstellen eines Objektes als Makro aufzeichnen und dieses später beliebig wiederverwenden. Damit hätte sogar jemand der nicht Programmieren kann ein Stück weit die Möglichkeit, Scripte zu erstellen.

Ich denke ich werde demnächst mal eine Seite erstellen und anfangen paar Informationen zusammen zu tragen.

Dann schau auch mal bei OSE-US in deren Wiki, irgendwo da haben die auch schon genau so eine Seite erstellt, sogar einschliesslich eines kleinen Anfänger Tutorials, das für den ersten Einstieg ganz brauchbar ist.


Gruss, Oliver

meinst du diese Seite?
http://opensourceecology.org/wiki/FreeCAD

Kann man sicherlich im Wiki verlinken.

Ja, genau.

Und mit dem dortigen Tutorial meinte ich FreeCAD-3.pdf von Mark Norton.

Hallo Oliver, ich will dich nicht weiter stören in deinen Vorbereitungen zur MakerFair, doch wo finde ich die UniProKit-Library ?

TF

Um die 3D Modelle im Wiki & Web integrieren zu können, gibt es die Möglichkeit, diese Mithilfe Export CAD → Meshlab → LaTex in eine PDF zu bringen, welche man dann wieder im Web integrieren kann.

http://www.goermezer.de/content/view/486/616/

Was ich gerade gefunden habe ist, dass item24 im Web zu den angebotenen Teile, Profile, usw. die Möglichkeit bietet, CAD-Dateien, Bilder, 3D-PDF, usw. generieren zu können.

http://www.item24.de/produkte/produktkatalog/products/profile-und-zubehoer.html

Hier, ziemlich am Anfang der Seite:

http://wiki.opensourceecology.de/Basis-Set_Strukturelemente

Gibts einmal mit Formaten wie .stp, .igs und .dwg und zum anderen als Blender-Library.

Gruss, Oliver

Hallo,

eine Anmerkung zu der technischen Ausführung zu FreeCAD:

FreeCAD nutzt OpenOInventor/Coin, aber diese Bibliothek ist nur für die 3D-Darstellung gedacht und kann auch nichts anderes. Coin ist wie erwähnt sehr Solide und FreeCAD nutzt das in der Visualisierung zu seinem Vorteil, das hat aber absolut nichts mit den gemetrischen Algorithmen zu tun. Diese werden von OpenCascade bereitgestellt, was der einzige verfügbare OS geometrie-Kern ist der Brep Geometrie beherscht. Diese Bibliothek ist leider nicht ganz so Solide, was aber auch an der extremen Komplexität der Materie liegt. FreeCAD arbeitet im Gegensatz zu Sketchup mit Brep Geometrie, also mit Mathematisch exakt definierten Geometrien, nicht mit Dreiecksflächen. Das ist ein entscheidener Vorteil und daher kann FreeCAD auch Step (ein Format für Brep Geometrie). Auf jedenfall wird OpenCascade aktiv weiter entwickelt und die neuen Versionen versprechen deutlich mehr Robustheit.

Man muss auch klar sagen das FreeCAD mehr ist als nur ein Frontend. Es vereint viele verschiedene Bibliotheken zu einem Nutzbaren ganzen und fügt sehr viele eigene Erweiterungen hinzu. Der Sketcher zum Beispiel ist eine Eigenentwicklung und ein sehr zentraler Bestandteil.

Der Workflow ist natürlich auch noch nicht wirklich gut ausgebaut und mann muss schon ziemlich viele Dinge wissen um das Program vollumfänglich nutzen zu können. Das liegt zu einem an der frühen Version (beta 0.14) und zum anderen auch daran, das jeder Nutzer an jedes Tool andere Erwartungen stellt, je nach vorerfahrung. Ansonsten stimmt es natürlich das die Dokumentation sehr dürftig ist, aber es ist halt ein OS projekt, wenn niemand einspringt und Dokumentation schreibt wir es sie nicht geben. Es ist richtig das momentan die Entwicklung auf wenigen Schultern liegt, daher ist jeder Willkommen der sich beteiligen möchte!

Diese Tage wird 0.14 stable veröffentlicht, lohnt sich mal anzuschauen!

danke für die Infos über FreeCAD. Gut zu hören, dass sich da was tut. Ich denke je mehr FreeCAD Anwendung und Anwender findet, desto mehr Ressourcen werden sich für die Weiterentwicklung finden. Es ist eben bei OS-Dingen anfangs eine enorm große Hürde, da diese im Vergleich zu kommerziellen closed-source-Produkten nicht konkurrenzfähig sind und sich wohl nur ideologisch veranlagte Anwender mit solch neuen unausgereiften Entwicklungen auseinandersetzen und diverse Ineffektivitäten akzeptieren.

Hallo Ickby,

Interessant. Da Opencascade ja nun auch schon etliche Jahre existiert hatte ich automatisch angenommen es wäre auch stabil. Umso besser, wenn es noch aktiv weiterentwickelt wird.

Es kann aber auch durchaus sein, dass die Probleme, die ich hatte, gar nichts mit OpenCascade zu tun haben, zum Beispiel „Löcher bohren mittels boolscher Subtraction“, das bezog sich darauf, wenn man das Teil als .step-File exportiert und dann z.B. nach Blender importiert, oder selbst wenn man es wieder in FreeCad reimportiert, dann sind anstatt Löcher da auf einmal wieder die Zylinder. Das dürfte aber schätzungsweise eher was mit der .step-Export-Funktion zu tun haben, soll heissen, solange ich innerhalb von FreeCad bzw. .fcstd bleibe wirds schon korrekt dargestellt.

Man muss auch klar sagen das FreeCAD mehr ist als nur ein Frontend. Es vereint viele verschiedene Bibliotheken zu einem Nutzbaren ganzen und fügt sehr viele eigene Erweiterungen hinzu. Der Sketcher zum Beispiel ist eine Eigenentwicklung und ein sehr zentraler Bestandteil.

Ja, ok. Mir gings bei dieser etwas plakkativen Differenzierung zwischen Frontend und Grafik-Kern hauptsächlich darum, zu illustrieren, das man über den direkten Zugriff via Python-Script noch einen zweiten, sichereren Weg hat, was etwaige noch vorhandene Bugs etwas weniger dramatisch erscheinen lässt. Es war also an sich eher positiv gemeint.

Der Workflow ist natürlich auch noch nicht wirklich gut ausgebaut und mann muss schon ziemlich viele Dinge wissen um das Program vollumfänglich nutzen zu können. Das liegt zu einem an der frühen Version (beta 0.14) und zum anderen auch daran, das jeder Nutzer an jedes Tool andere Erwartungen stellt, je nach vorerfahrung.

Vorerfahrung ist das Stichwort. Was für mich als Einsteiger die Sache besonders schwierig und enorm zeitraubend machte, das war die ständige Unsicherheit, ob wenn etwasnicht klappte es an mir lag oder sich um ein FreeCad-Problem handelte.


Ansonsten stimmt es natürlich das die Dokumentation sehr dürftig ist, aber es ist halt ein OS projekt, wenn niemand einspringt und Dokumentation schreibt wir es sie nicht geben. Es ist richtig das momentan die Entwicklung auf wenigen Schultern liegt, daher ist jeder Willkommen der sich beteiligen möchte!

Genau das Problem haben wir mit unseren Projekten hier auch und hat wohl jedes Projekt, liegt halt in der Natur der Sache. Für mich wäre es halt wichtig wenn wenigstens die API noch besser dokumentiert wäre, im Hinblick auf eine Einschätzung ob man FreeCad tatsächlich produktiv einsetzen möchte und kann.
Ich kann aber auch verstehen, dass aus Sicht der FreeCad-Leute eine Dokumentation der User-Funktionen erstmal Vorrang hatte.

Diese Tage wird 0.14 stable veröffentlicht, lohnt sich mal anzuschauen!

Ganz bestimmt! Das sind gute Neuigkeiten.

Gruss, Oliver

Hallo allerseits!

sorry, ich habe dieses Posting erst jetzt gelesen, bzw. habe es rein zufällig gefunden als ich das Forum durchstöberte :wink: , als ich das ganze negative hier gelesen habe (eine unendliche spirale nach Unten!!) wo es überall hakt usw. (wir hatten hier schon einmal eine ähnliche Diskussion geführt :wink:) muß ich jetzt erstmal sagen stop Leute!! Wenn man sich mit FreeCAD beschäftigt, sollte man sich auch die History vor Augen halten und das dieses Projekt erst im Jahr 2000 ins Leben gerufen wurde und die erste Version 0.0.1 im Jahre 2002 erschien ist. 2003 wurde dann Version 0.1 raus gehauen. Und das war eigentlich auch schon ein ziemlicher Quantensprung. Über die Jahre bis 2009 bzw 2010 gab es zwar einzelne Verbesserungen in der Funktionalität aber keine nennenswerten Fortschritte was das Modellieren betrifft. Das änderte sich erst im Jahr 2010, ich habe noch mit der 0.10 die ende 2011 bzw anfang 2012 als stable Version zur verfügung stand gearbeitet. Der Grund für diese langsame Entwicklung wurde hier schon in diesem Verlauf des Postings öfters genannt, es war zuviel Arbeit auf zu wenige Leute verteilt, des weiteren wurde sich hier auch nicht drum gekümmert Fördergelder zu beantragen, damit die Entwickler nicht nur in Ihrer Freizeit sondern auch vollberuflich daran arbeiten konnten, denn das ganze ist sehr komplex und erfordert mehr als die Zeit sich am Wochenende damit zu beschäftigen. Es wurden also sehr viele Fehler gemacht, was die Entwicklung verzögerte, Wie schon gesagt hat sich das in der zwischenzeit geändert! Mitlerweile ist Yorik Team Leader und er hat dank der Fördergelder jetzt auch entsprechend Zeit, sich der Sache ganz zu widmen, was man daran sieht, das fast täglich code update gemacht werden siehe hier unter Latest activity http://www.freecadweb.org/ !!! Ja ich geb zu am Anfang war es ein krux gewesen mit Freecad zu arbeiten, Löcher konnte man nur durch boolische Operation in das Werkstück bekommen und viele Operationen beinhalteten fehlerhaften code’s! Insbesondere die Bemaßung. Das hat sich aber seit 0.14 geändert und an der Bemaßung wird momentan sehr stark gearbeitet. da das Team entsprechend zulauf bekommen hat, gibt es mittlerweile eine guten support via Forum und die Tutorials konnten entsprechend Fahrt aufnehmen siehe: https://www.youtube.com/watch?v=m49z0weonog (mitlerweile gibt es schon das Tutorial 11 aus dieser reihe) . D.h. die Weiterentwicklung von FreeCad wird in den nächsten Jahren entsprechende Fortschritte machen, so das wir in den nächsten 3 bis 4 Jahren mit einer wirklich vielversprechenden Profiversion rechnen können, in 6 bis 7 Jahren (oder früher) rechen ich sogar damit das es Konkurrenzfähig zur proprietären Software wird, so wie Blender zu 3D studiomax oder 4D Cinema, das außer in einigen Punkten was Rendern angeht in nichts mehr zurücksteht und sogar in vielen Pukten die proprietären Übertrifft!!! Und wenn ich bedenke das die Entwicklung von Blender erst in den letzten 5 bis 6 Jahren bedeutend wurde, 2007 konnte man damit gerade mal einige einfache Sachen Modellieren aber nicht wirklich etwas komplexes, erwarte ich eine ähnliche Entwicklung in Bezug auf FreeCAD. Zudem habe ich vor 2 Jahren darauf aufmerksam gemacht das wir mit dem Team enger zusammenarbeiten sollten! Ansprechpartner in Deutschland waren Jürgen Riedel und Werner Mayer.