Gitterrost - performanter Lösungsansatz gesucht

In diesem Forum Fragen und Diskussionen in Deutsch
Forum rules
Foren-Regeln und hilfreiche Informationen

WICHTIG: Bitte zuerst lesen, bevor Sie posten
FrankF
Posts: 3
Joined: Sun Jan 23, 2022 12:55 am

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by FrankF »

chrisb wrote: Sun Jan 23, 2022 2:01 pm Hat mal jemand versucht das ganze Konstruktiv zu machen, also schräg laufende Pads und den Überschuss am Ende wegschneiden?
Zunächst ganz herzlichen Dank für eure Antworten und die damit verbundene Zeit und Mühe!

Mein erster Ansatz war konstruktiv und nicht diagonal, also Pads in x- und y-Richtung mulitpliziert. Dort hatte ich einen vergleichbaren Effekt und als Alternative die Lochmethode versucht.

Die aktuelle Konstruktion ist 150mm x 13mm groß und hat ca. 4.200 Löcher, siehe Anhang, und befindet sich derzeit im Druck.

An den Einstellungen zur Tesselierung habe ich schon gespielt, konnte aber keine Verbesserung feststellen. Trotzdem werde ich nochmal Versuch in dieser Richtung mit runden Löchern vornehmen.

Grundsätzlich scheint es aber eine FreeCAD-Eigenschaft zu sein und nicht Unwissenheit meinerseits. Als Lösungsansätze habe ich nun zur Auswahl:
- Tesselierung und runde Löcher
- Cut mit Part - da werde ich Dirks Vorschlag testen, auch wenn ich die Part-Bench kaum kenne
- Kleinere Bauteile konstruieren, mit 150mm ist der 3D-Drucker am Ende. Bei kleineren Teilen ist die Fail-Rate geringer. Gemergt wird dann mit Sekundenkleber
- Etwas gröberes Gitter konstruieren, hängt von der Wirkung im Modell ab

Vielen Dank für die tollen Anregungen und eure Hilfe!

Grüße, Frank

P.S.: Falls es jemanden interessiert, es geht um https://www.stahlbahn.de - erste kleinere FreeCAD-Projekte haben bereits zu schönen Modellen geführt.
Attachments
Screenshot 2022-01-23 165104.jpg
Screenshot 2022-01-23 165104.jpg (162.12 KiB) Viewed 1037 times
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by chrisb »

Ich habe hier noch mal das Sketch nachgearbeitet und die Zahl der Constraints von 31 (und eine fehlte noch) auf 20 reduziert, nun voll eingeschränkt.
In Sachen Rechenzeit bringt das aber natürlich nix.
Attachments
SketchFuerGitterrost_cb.FCStd
(4.25 KiB) Downloaded 24 times
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by chrisb »

Ich habe noch mal einen Versuchsballon gestartet und wollte mit dem Sketcher-Array arbeiten. Nach ca. einer 3/4 Stunde Rechenzeit mit 200% CPU habe ich das Experiment nun abgebrochen. Es wird wohl nicht schneller sein als die anderen Möglichkeiten.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
Dirk.B
Veteran
Posts: 1423
Joined: Sat Feb 02, 2019 11:47 am
Location: Deutschland/Saarland

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by Dirk.B »

Hallo
ch habe noch mal einen Versuchsballon gestartet und wollte mit dem Sketcher-Array arbeiten. Nach ca. einer 3/4 Stunde Rechenzeit mit 200% CPU habe ich das Experiment nun abgebrochen. Es wird wohl nicht schneller sein als die anderen Möglichkeiten.
mit welchen Bedingungen und welche Möglichkeiten ;)

Wir können ja mal ein def Beispiel Starten und mal schauen welcher Rechner welch Zeiten benötigt mit Part/Part Design das wir hier mal ein Verhältniss haben ;)
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by chrisb »

chrisb wrote: Sun Jan 23, 2022 1:35 pm Recompute-Zeiten
============
Cut mit Part: 85s
Multipattern mit Non-Overlap-Mode: 174s
Multipattern mit Overlap-Mode: 177
Multipattern mit Detect-Overlap-Mode: 176
Das sind die Zeiten für Deine Zahlen (99x14). Gemessen wurde die Zeit mit diesem Makro timeToRecompute.py:

Code: Select all

# measure the time elapsed for a recompute
# exec(open('/Users/cb/panhard/coupe/sanssoupapes/timeToRecompute.py').read())
import time
import FreeCAD

# touch everything:
for obj in FreeCAD.ActiveDocument.Objects:
  obj.touch()

# Uncomment exactly one of these two:
## timeFn = time.perf_counter # measure real time
timeFn = time.process_time # measure process time, ignore sleep, count each processor

# measure recompute
startTime = timeFn()
App.ActiveDocument.recompute()
endTime   = timeFn()
elapsed = int(endTime - startTime)
print('{:02d}:{:02d}:{:05.2f}'.format(int(elapsed) // 3600, (int(elapsed) % 3600 // 60), elapsed % 60))
print(endTime - startTime)
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
user1234
Veteran
Posts: 3326
Joined: Mon Jul 11, 2016 5:08 pm

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by user1234 »

Grundsätzlich sollte man sowieso solche Gitter nicht ausmodellieren (LOD), aber beim Drucken hilft das natürlich nicht.

Bei mir mit dem richtigen Computer braucht er bei 32x32 mit 1% und 15°, PartDesign, Multitransform (2x Linear), Overlap = dedect

Rund 8,785s
Rechtecke 24,206s

. Er nimmt am Anfang 3/4 der Zeit einen Kern und am Ende fast alle die ich habe. Ich dachte ursprünglich, dass runde Löcher länger benötigen, weil diese komplizierter zu meshen sind. Da aber dies nur eine Fläche ist und bei Rechtecken 4, dauert es tatsächlich länger.

Man muss aber wenn man sowas modelliert bedenken, bei jedem nachgehenden Schritt benötigt man mindestens die selbe Zeit, weil FreeCAD bei jeden Schritt neu meshen* muss. D.h. am idealsten macht man 2 Bodies, einen mit den Rahmen und einen mit dem Gitter, und am Ende macht man eine Fusion. Damit umgeht man das ständige neuberechnen des Gitters.

*Anmerkung. Ich weiß nicht, ob wirklich es das meshen oder das die Berechnung selbst die Dauer benötigt, denn auch wenn man es ganz grob einstellt, es kommt ein Punkt, wo es nicht mehr schneller werden kann, denn durch alle Flächen muss FreeCAD so oder so durchgehen und bei den gröbsten Einstellungen wird halt am Ende immer das gleiche berechnet. Ich weiß, mit Python kann man mit das meshen unterdrücken, wenn man nicht Part.show() oder ähnliches ausführt.

Grüße
user1234

Code: Select all

Version: 0.20.27190 (Git)
Build type: Release
OCC version: 7.6.0
FrankF
Posts: 3
Joined: Sun Jan 23, 2022 12:55 am

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by FrankF »

user1234 wrote: Mon Jan 24, 2022 1:14 am Man muss aber wenn man sowas modelliert bedenken, bei jedem nachgehenden Schritt benötigt man mindestens die selbe Zeit, weil FreeCAD bei jeden Schritt neu meshen* muss.
Ja, das ist das eigentlich Lästige! Ich habe es nun so gemacht, daß ich in Excel eine Liste mit der Anzahl der linearen Transformationen ("Vorkommen") vorbereitet habe. In FreeCAD lasse ich die Multitransformation dann bei (z.B.) 14 x 3 und konstruierte meine Teile fertig. Und abspeichern. Ganz zum Schluß setze ich auf 14 x 152 und beschäftige mich die nächste Viertelstunde mit etwas anderem. Die Folgeschritte in der Mesh-Bench mit Export der STL-Dateien gehen dann ja flott. Und dann orgelt der Drucker 7-8h, aber gestern Abend mit vorzüglichem Ergebnis - man kann durch das Gitterrost hindurchsehen, und das war genau das Ziel. Muss nur beim Lackieren aufpassen...

Runde Löcher habe ich als Alternative mal getestet, jeweils mit einem Quadratpaar bzw. Kreispaar gerendert:
14 x 47 Paare: 3 Minuten Quadrate, 1,5 Minuten Kreise
14 x 70 Paare: 6 Minuten Quadrate, 2 Minuten Kreise
14 x 100 Paare: 10 Minuten Quadrate, 4 Minuten Kreise

LG Frank
user1234
Veteran
Posts: 3326
Joined: Mon Jul 11, 2016 5:08 pm

Re: Gitterrost - performanter Lösungsansatz gesucht

Post by user1234 »

FrankF wrote: Mon Jan 24, 2022 7:42 pm Ganz zum Schluß setze ich auf 14 x 152 und beschäftige mich die nächste Viertelstunde mit etwas anderem.
Ja, das ist schon ganz gut die Idee. Hier mal ein ähnliches Beispiel mit der Body Trennung.
0.gif
0.gif (729.28 KiB) Viewed 793 times
example.FCStd
(61.34 KiB) Downloaded 12 times

Nur zur Anmerkung: Patterns in PartDesign sind in FreeCAD 0.20master wesentlich schneller als 0.19.x. Das hat davidosterberg extrem verbessert.

Grüße
user1234
Post Reply