---

Massentragheit.pkg.txt Vergleich_Wellen.png

Hallo,

eigentlich wollte ich nur die Trägheitstensoren für eine BG ermitteln. Da ich früher schon mal den Fall hatte, dass da etwas nicht gestimmt hat, habe ich die Analyse mit zwei verdrehten Koordinatensystemen gemacht. Wenn sich nur die Richtungen des Koordinatensystems ändern, sollten die Werte die gleiche Größe haben und sich  nur in Bezug zur Richtung ändern. Das stimmt meistens auch.

Leider nicht in meinem Fall.

Nach etwas suchen habe ich ein Teil, das komische Werte liefert, gefunden. In der angehängten BG ist es die Welle.

Zuerst habe ich die Trägheitstensoren in Abhängigkeit der beiden Koordinatensysteme berechnet. Bei dem Klotz stimmt das Ergebnis wie erwartet und bei der Welle kommen "komische" Werte heraus:

Teile/Baugruppen:
       /Test/Klotz

Bezugskoordinaten:
Koordinatensystem:
       /Test/KoSy1

Trägheitstensor (kg mm2):
(In Bezug auf die Bezugskoordinaten.)
  XX:  1439720.8142894357     +-  0          ( 0 % )
  YY:  976343.7589550356      +-  0          ( 0 % )
  ZZ:  802600.9260646398      +-  0          ( 0 % )
  XY:  322319.6281958399      +-  0          ( 0 % )
  XZ:  315977.792634283       +-  0          ( 0 % )
  YZ:  -619708.3840036714     +-  0          ( 0 % )

--------------------------------------------

Teile/Baugruppen:
       /Test/Klotz

Bezugskoordinaten:
Koordinatensystem:
       /Test/KoSy2

Trägheitstensor (kg mm2):
(In Bezug auf die Bezugskoordinaten.)
  XX:  1439720.8142894357     +-  0          ( 0 % )
  YY:  802600.9260646398      +-  0          ( 0 % )
  ZZ:  976343.7589550356      +-  0          ( 0 % )
  XY:  -315977.792634283      +-  0          ( 0 % )
  XZ:  -322319.6281958399     +-  0          ( 0 % )
  YZ:  -619708.3840036714     +-  0          ( 0 % )

--------------------------------------------
--------------------------------------------

Teile/Baugruppen:
       /Test/Welle

Bezugskoordinaten:
Koordinatensystem:
       /Test/KoSy1

Trägheitstensor (kg mm2):
(In Bezug auf die Bezugskoordinaten.)
  XX:  709577.1831641158      +-  0          ( 0 % )
  YY:  408949.2796359495      +-  0          ( 0 % )
  ZZ:  340661.5669732994      +-  0          ( 0 % )
  XY:  80076.5872623119       +-  0          ( 0 % )
  XZ:  74853.6167375162       +-  0          ( 0 % )
  YZ:  -300212.5583283556     +-  0          ( 0 % )

--------------------------------------------

Teile/Baugruppen:
       /Test/Welle

Bezugskoordinaten:
Koordinatensystem:
       /Test/KoSy2

Trägheitstensor (kg mm2):
(In Bezug auf die Bezugskoordinaten.)
  XX:  656467.4397787447      +-  0          ( 0 % )
  YY:  393771.5675147561      +-  0          ( 0 % )
  ZZ:  408949.022479864       +-  0          ( 0 % )
  XY:  -21272.8582968601      +-  0          ( 0 % )
  XZ:  -79910.0600265658      +-  0          ( 0 % )
  YZ:  -300549.080878417      +-  0          ( 0 % )

--------------------------------------------

Dann habe ich die Welle noch einmal modelliert (Welle_neu_modelliert) und eine einfache Analyse der beiden Wellen gegenübergestellt -> siehe angehängtes Bild.
Hier sieht man deutlich, dass sich die Masse, der Schwerpunkt und das Volumen von den beiden Teilen deutlich unterscheiden.

Meine Fragen sind nun:
Warum ist das so?
Kennt jemand so ein Phänomen?
Gibt es eine Möglichkeit solche Teile einfach zu erkennen und zur "reparieren"?

Ich würde mich eigentlich gerne einfach auf die berechneten Werte verlassen ohne sie hinterfragen zu müssen.

Vielen Dank.

Grüße
Stephan

[Diese Nachricht wurde von StephanD am 24. Apr. 2020 editiert.]

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

---

Wellentypen.jpg wellentypen_resultat.txt

Hallo Stephan,

habe mit dem hochgeladenen Model schon eher etwas rumprobiert aber nix gefunden.
Eben habe ich das Problemteil kopiert + halbiert,
kopiert + geviertelt und kopiert + zu einem Zylinder geändert.
Dann habe ich von den einzelnen Teilen die Messberichte abgefragt.
Ups, was man mit dem Ding auch macht, die Werte bleiben gleich.
Wie eingefroren.

Wo hast du das Teil denn her? Tippe auf Import, zB. als Step oder so.
Deine Fragen =>
Meine Fragen sind nun:
Warum ist das so? Da kann man viel spekulieren. 
Kennt jemand so ein Phänomen? Kommt mir bekannt vor, zumindest ähnlich "Klick"  
Gibt es eine Möglichkeit solche Teile einfach zu erkennen und zur "reparieren"?
Erkennen: Vom "neuen" Importteil Teilemasse abfragen, irgendwas am Teil grob verändern, wieder Teilemasse abfragen und vergleichen.
Reparieren: Keinen Schimmer. 
Ich würde mich eigentlich gerne einfach auf die berechneten Werte verlassen ohne sie hinterfragen zu müssen. Jepp, wäre nicht nur schön!
Hast du einen funktionierenden Supporter? Könnte vieleicht helfen.
Sorry mehr ist momentan nicht.

------------------
Gruss Friedhelm

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

---

Zitat:

---

Original erstellt von friedhelm at work:
habe mit dem hochgeladenen Model schon eher etwas rumprobiert aber nix gefunden.
Eben habe ich das Problemteil kopiert + halbiert,
kopiert + geviertelt und kopiert + zu einem Zylinder geändert.

---

• Skaliert rauf/runter?
• neues Teil erstellt, kleine Geometrie. Geometrisch vereint mit dem hochgeladenen Model mit Ziel = neues Teil?
• Step raus + Step rein?
• Alle Flächen auf ein neues Teil kopiert? (besser in mehreren Schritten, damit zwischen drin ein FacePart entsteht)
• Fläche gelöscht, speichern (als SD), wieder neu laden + Fläche wieder einfügen?

[technisch]: den Body vom Sel-Item trennen. Das sind intern 2 Paar Pantoffel[/technisch] vielleicht hülfst. 

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

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

---

Hallo,

danke für eure Hilfe.
Ich bin auch ein Stück weitergekommen und habe hier im Forum einen wichtigen Hinweis gefunden:
http://ww3.cad.de/foren/ubb/Forum29/HTML/004470.shtml#000000

Man kann im Modeling unter "Struktur - Teile&Baugruppe - Mehr - Masseneigenschaften zuweisen" sogar die Werte fest ins Modell "einbrennen". Weg bekomme ich sie nur über ein neues Teil. Also z.B. über Step export/import oder ein leeres neues Teil erstellen und mit dem falschen Teil vereinigen.

Zum Finden von solchen Teilen versuche ich mich gerade an einem kleinen Lisp-Programm, das die Trägheitstensoren von zwei unterschiedlichen Koordinatensystem vergleicht. Das ist aber noch nicht ganz fertig.

Es mag ja Fälle geben wo es Sinn macht, die Eigenschaften im Modell zu fixieren, warum aber werden die fixierten Eigenschaften beim Kopieren nicht wieder aufgehoben? Das verstehe ich nicht.

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

---

Du_list_falscher_Schwerpunkt.lsp.txt

Hallo zusammen,

so, nun ist das Programm fertig, das Teile/Baugruppen mit falsch fixierten Hauptachsen und Schwerpunkte findet.

Da meine Programmierkenntnisse nicht so doll sind, bitte ich eventuelle Bugs oder unsauber programmierte Teile zu Entschuldigen. Vielleicht gibt es ja auch Verbesserungsvorschläge.

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

---

Zitat:

---

Original erstellt von StephanD:
so, nun ist das Programm fertig

---

👍  sieht doch schon mal sehr gut aus.. 

Verbesserungsvorschläge.... kommen noch. 😉

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

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

---

Zitat:

---

Original erstellt von StephanD:
Verbesserungsvorschläge.

---

Code:

---

(defun unique-objects(objects)… 

---

Okay..

Erst alles in eine Hashtable stopfen und dann über die keys loopen um eine neue Liste zu erstellen. Mir deucht, es gibt dann 'nen Zeitpunkt, wo die Daten 3 mal im Speicher sind.

Code:

---

190:    (loop for obj being the hash-values of ht collect obj)))

---

Das liest sich allerdings auch echt cool. 

Einfacher, lesbarer und vermutlich schneller ist ein EIN-Zeiler:

Code:

---

(setq objects (remove-duplicates objects :test 'equal :key 'sd-inq-obj-contents-sysid))

---

Vertrauen wir einfach mal darauf, das ein LISP primitive immer effektiver arbeitet als auscodierter LISP code.

Schade das (get_selection …) keine  option  :uniq-sel-item T hat.
____________________________________________

Warum nicht

Code:

---

108: (setq TraeTen1 (gpnt3d_x (sd-call-cmds(get_vol_prop :for_par…
115: (setq TraeTen2 (gpnt3d_x (sd-call-cmds(get_vol_prop :for_part…

---

An anderen Stellen nutzt du ja auch den return wert von sd-call-cmds.
____________________________________________

In der Hauptschleife machst du ja immer wieder ein create_part.. unite .. delete part.

Mach’s besser so:

Code:

---

(setq recover-state (sd-set-model-checkpoint))

(dolist (a_TEIL (unique-objects Alle_Elemente))  ;; (übrigens ohne extra progn)
  (create_part ...)
  (unite_3d ...)
  (measure ...)
  ;; kein (delete_3d …)   aber .. :
  (sd-return-to-model-checkpoint recover-state)
  ) ;; end dolist
(sd-return-to-model-checkpoint recover-state) ;; falls wir aus der dolist noch anderweitig rausspringen..

---

Siehe auch die Erklärung im ==> Integration Kit:

• ==> sd-set-model-checkpoint
• ==> sd-return-to-model-checkpoint

Das Funktionspäärchen macht das ganze echt robust. Das ist deutlich Speicher schonender.

Und über create + unite stülpst du noch nen sd-call-cmds drüber.

Den return-to-model-checkpoint kann man auch (evtl.) in der :cleanup (zusätzlich) machen..
____________________________________________

und zum Schluss

Code:

---

sd-defdialog DU_LIST_FALSCHER_SP...
; (DEFUN DU_LIST_FALSCHER_SP ...) is being compiled.
;; The variable AUSGABELISTE is undefined. (Assume its global)
;; The variable ALLE_ELEMENTE is undefined. (Assume its global)
;; The variable TRAETEN1 is undefined. (Assume its global)
;; The variable TRAETEN2 is undefined. (Assume its global)
;; The variable ABSTAND_SP is undefined. (Assume its global)
;; The variable FALSCHER_SP is undefined. (Assume its global)
;; The variable FALSCHES_MOMENT is undefined. (Assume its global)
;; The variable MAS is undefined. (Assume its global)
;; The variable MESSVEKTOR is undefined. (Assume its global)
;; The variable BENENNUNG is undefined. (Assume its global)
;; The variable AUSGABE is undefined. (Assume its global)

---

Da fehlen ein paar LETs.

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

[Diese Nachricht wurde von der_Wolfgang am 09. Mai. 2020 editiert.]

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

---

Zitat:

---

Original erstellt von der_Wolfgang:
(sd-set-model-checkpoint) / (sd-return-to-model-checkpoint recover-state)

---

Stellt Euch das wie eine Art "gezielter UNDO" vor. Nur muss man eben schon vorher festlegen, zu welchem Punkt man zurückgehen möchte. Das ist (inbesondere) für Schleifen mit temporären Modeling Aktionen optimal!

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

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

---

Du_list_falscher_Schwerpunkt_V1.1.lsp.txt

Hallo Wolfgang,

vielen Dank für deine Auswertung die Tipps.

Ich habe versucht (soweit ich es verstanden haben) alles gut umzusetzen. Hier das Ergebnis.

Wo muss das "LET" für Variable "Ausgabeliste" gesetzt werden? Wie kann ich die LETs prüfen?

Gibt es eine einfache Möglichkeit den Fortschritt des Makros z.B. in der Promptzeile anzuzeigen? Z.B. 30 von 50 Teile fertig oder 30% fertig

Bei größeren Baugruppen dauert es manchmal doch einige Zeit und wenn gar keine Rückmeldung da ist, dann weiß mann nicht ob es noch voran geht.
Als Idee hatte ich schon, das Console-Fenster einzublenden und dann wieder auszublenden. Finde ich aber nicht so schön.

Grüße
Stephan

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

---

Das sind jetzt viele viele Einzelpunkte...  ich hoffe es wird nicht zu unübersichtlich:
_______________________________________________

1)
Wenn du den LET in der dolist drin läßt

Code:

---

(dolist (a_TEIL Alle_Elemente)
  (let (TraeTen1 TraeTen2 Abstand_SP Messvektor falscher_SP mas falsches_Moment Typ_Teil Ausgabe Benennung)

---

kannst du auf die ganzen Setzerei auf NIL verzichten, weil, die sind dann eh schon nil.

Wenn du jene Variablen hochziehst.. 

Code:

---

(los_gehts ()
  (let (Alle_Elemente …also_hierhin… )

---

werden sie in der dolist nicht immer wieder und wieder neu angelegt und wieder weg geschmissen.
Dann brauchst du natürlich wieder das Rücksetzen.

Das geht aber auch so:

Code:

---

(setq TraeTen1 nil
      TraeTen2 nil
      Abstand_SP nil)

---

_______________________________________________

2)
Den

Code:

---

(setq recover-state (sd-set-model-checkpoint))

---

machst du EINMAL vor der dolist..  ist ja immer der selbe Rücksprungpunkt.  Und es reicht den einmal festzulegen.

Und natürlich der passende LET

Code:

---

(los_gehts ()
  (let (Alle_Elemente recover-state...)

---

_______________________________________________

3)
AUSGABELISTE ist einen Variable, die du in der ok-action nutzt UND in der Schleife in der localen funktion.
Das ist etwas unschön, aber nicht unlösbar.

In die Liste der Dialog variablen stopfen. Da kann ja nicht nur sichtbare Variablen unterbringen.

Code:

---

....
(Ausgabeliste :initial-value nil)
) ;; end :variables

---

_______________________________________________

4)
Was effektives:
Statt:

Code:

---

(setq Ausgabeliste (cons Ausgabe Ausgabeliste))
.....
(dolist (Ergebnisse Ausgabeliste)
          (display (format nil "~a" Ergebnisse))
);dolist

---

Schneller:

Code:

---

(push Ausgabe Ausgabeliste))  ;; die Reihenfolge wäre jetzt falsch.. aber..  macht nix..
...
(display (format nil "~{~a~%~}" (nreverse Ausgabeliste)))

---

(format nil "~{ ....~}" bedeuted: formatiere jedes Element der Liste.. (mit der Format Anweisung die dazwischen steht)
_______________________________________________

5)
Wenn aber:
los_gehts  als return value ein (nreverse Ausgabeliste) hätte, könnte Ausgabeliste eine lokale (let..) variable von los_gehts sein.
Und nach der Überschrift kommt dann:

Code:

---

(display (format nil "~{~a~%~}" (los_gehts))

---

_______________________________________________

6)
Wegen progress indicator
Man konnte mal die Promptbar mal setzen (unsupported) ... aber das geht nimmer ... irgendwie ... :-\
Alternative (hattest du  schon gesagt):

Code:

---

(sd-show-console-window)
(dotimes (i 10)
  (format T "~& running ~a of 10~%" i)
  (sleep 1)
)
;(sd-hide-console-window)  ;; den würde ich nicht machen!!

---

_______________________________________________

7)
Die gemeldeten nicht initialisierten (also global angenommene) Variablen und andere solche Definitions-Unzulänglickeiten sieht du,
wenn Du den code compilierst: siehe ==>>> dort = COMPILE
Aber vor allem brauchst du dann auch eine Lizenz für das Integration Kit. Diese werden wohl nur sehr wenige Mitleser*Innen haben.

------------------
● Firefox ESR ● Java Forum Stuttgart JUGS ● OSD Hilfeseite (de) / help page (en) ● NotePad++ ● BuFDi ●

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

---

Du_list_falscher_Schwerpunkt_V1_2.lsp.txt

Hier nun eine weitere Version.

Die Vorschläge von Wolfgang habe ich eingearbeitet.

Mir ist noch etwas aufgefallen:
Wenn ich die neuen Teile vereinige bekomme ich bei Teilen mit Bohrungen viele dieser Meldungen:

Informationen: Ungültiges MACH_ADV_LIBRARY_BLINDHOLE-Formelement "Zapfensenkung" wurde validiert.

Ich habe auch das Gefühl, dass das Validieren ziemlich Zeit benötigt.

Wenn ich aber das neue Teil mit den Flächen füttere (siehe Code unten) dann kommen die Meldungen nicht und es geht gefühlt schneller. Das Erbeniss scheint das gleiche zu sein. Gibt es dafür einen Grund und könnte man das Validieren auch abstellen?

Code:

---

(if (sd-inq-part-p a_TEIL)
(progn
(create_part)

(if Flaechen (progn
(copy_faces
:FACES (ALLE_FLAECHEN_PART a_TEIL)
(values)
:to_part (sd-inq-curr-part)
)
)(progn ;else if
(unite_3d
:keep_tools :YES
:BLANK (sd-inq-curr-part)
:TOOLS a_TEIL
)
)
)

---

[Diese Nachricht wurde von StephanD am 20. Mai. 2020 editiert.]

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