---

Screenshot2026-03-11134722.png Screenshot2026-03-11134637.png

Hallo zusammen,
ich bin gerade dabei für eine Projektarbeit im Studium, für die Validierung eines kleinen Excel-Berechnungs-Programms, die Verschiebungen eines mittels Federn gelagerten Körpers unter Krafteinwirkung zu simulieren.

Ziel ist es, einen Körper zu haben, der auf Federn in x- und y-Richtung gelagert ist, und an dessen Schwerpunkt Kräfte und Momente eingeleitet werden. Der Körper wird dabei als starr angenommen, da seine Steifigkeit in der Realität, die Steifigkeit der Lager um ein Vielfaches überschreitet. Für die schnelle Anpassbarkeit, soll kein richtiger Körper verwendet werden, sondern nur ein Knoten als Krafteinleitungspunkt und 2-6 Knoten als Lagerpunkte. Zunächst soll das Ganze zweidimensional simuliert werden und später dreidimensional.

Ich habe hierzu ein Modell aus drei Knoten erstellt (siehe Bild). Ein Knoten als Krafteinleitungspunkt und zwei Knoten als Lagerpunkte. Die Knoten sind mit jeweils einem RBE2-Element verbunden (Position abhängige/unabhängige Knoten wurde beachtet). Als Federn werden CBUSH-Elemente verwendet, welche mit fixierten Knoten im Raum befestigt sind.

Nach viel Probieren, Recherchieren und F06-Dateien lesen bin ich jetzt am verzweifeln. Ich habe es geschafft ein Ergebnis zu erhalten, für eine nach oben (y-Richtung) wirkende Kraft (siehe Bild), und auch eine Kraft nach rechts (x-Richtung) hat funktioniert. Allerdings führt es zu Fehlern und Abbrüchen sobald ich verschieden große Steifigkeiten definiere, die Größe der Kraft ändere, die Steifigkeiten ändere, usw. Auch das Aktivieren der Option "Große Verschiebungen" führt zum Abbruch. Mit dem Solver 101 linear static war nichts zu machen. Mit dem Solver 402 multi-step nonlinear Kinematics bin schonmal weitergekommen, aber auch nicht ans Ziel.

Ich weiß, dass die großen Steifigkeitsunterschiede von RBE2 zu CBUSH zu Problemen führen kann, aber ich habe keinen Weg gefunden dies zu umgehen. Ich habe von einem "Rigid body" Element gelesen, welches die Knoten mit Zwangsbedingungen verbinden soll. Dieses habe ich aber nicht finden können.
Es muss doch möglich sein, so einen simplen Aufbau zu realisieren? Ich würde mich freuen, wenn mir jemand helfen kann.

Viele Grüße
Stefan

[Diese Nachricht wurde von Stefan12345 am 11. Mrz. 2026 editiert.]

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

---

Hallo Stefan,

eigentlich wäre das hier das richtige Board:
NX Simulation
Ich lass den Eintrag dennoch mal hier stehen, verschiebe ihn später aber ins Simulations-Board.

Kannst du in deine Skizze mal die ganzen Längen und Federsteifigkeiten eintragen, damit ich's 1:1 nachbauen kann? Und zusätzlich bitte einen Lastfall nennen (Länge und Richtung der angreifenden Kraft einzeichnen), der bei dir zu einer Lösung führt und einen, bei dem die Rechnung abbricht?

Ich werde dann bei Gelegenheit mal gucken, ob ich zu brauchbaren Ergebnissen komme.

------------------
Gruß 

Markus

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

---

260312_Prinzipskizze.jpg 260312_Analytische_Loesung.jpg

Hallo nochmal,

da bisher noch nix kam, hab ich mal ein eigenes Beispiel gebaut. In der Hoffnung, dass es dir hilft, hier meine Gedanken:

(1) Prinzipskizze und Lastfall siehe ersten Screenshot
(2) Analytische Lösung:

- Wegen der symmetrischen Anordnung verteilen sich die senkrecht nach unten wirkenden 400 N gleichmäßig auf die Lagerpunkte A und B (jeweils 200 N).
- Die Horizontalkraft nach rechts verursacht zum einen ein Längen der horizontalen Feder bei A, zum anderen ein Stauchen der horizontalen Feder bei B. Da die Federsteifigkeiten gleich sind, wirken auf beide Lagerpunkte jeweils 100 N nach rechts.
- Kommt noch das Drehmoment hinzu, welches von der Horizontalkraft FX (200 N) hervorgerufen wird. Wir halten gedanklich den Lagerpunkt B fest, die 200 N drehen mit einem Hebel von 150 mm nach rechts, auf die vertikale Feder bei A wirken nach Hebelgesetz 100N nach oben (200N * 150mm / 300mm).
- Halten wir gedanklich den Punkt A fest, erzeugt nach gleicher Logik das Drehmoment von FX um A eine Kraft von 100N nach unten auf B.

(3) Siehe zweiten Screenshot:
Bei einer Steifigkeit von 100 N/mm (gleich für alle Federn) ergibt sich:
- Punkt A wandert 1mm nach rechts und 1mm nach unten (entspricht Gesamtweg von 1,414 mm nach rechts unten
- Punkt B wandert 1mm nach rechts und 3mm nach unten (entspricht Gesamtweg von 3,162mm nach rechts unten.

Die Beschreibung der Analyse über NX folgt gleich im nächsten Post.

------------------
Gruß  

Markus

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

---

260312_FEM-Datei.jpg 260312_SIM-Setup.jpg 260312_SOL101_AUTOMPC.jpg

Nun zur NX-Analyse:

(1) Es wurde ein Modell mit Punkten vorbereitet, deren Abstand und Anordnung der Prinzipskizze aus dem vorigen Post enstpricht.
(2) In der .fem-Datei wurden die äußeren Endpunkte der linken beiden Federn mit dem Punkt A durch CBUSH1D-Elemente mit der entsprechenden Steifigkeit (in meinem Beispiel 100 N/mm) verbunden. Das gleiche wurde mit den äußeren Endpunkten der rechten beiden Federn mit dem Punkt B gemacht.
(3) Der Kraftangriffspunkt wurde mit den Punkten A und B jeweils durch ein RBE2-Element verbunden.

Siehe dazu den ersten Screenshot im Anhang.

(4) In der .sim-Datei (Solution 101) wurden die äußeren Endpunkte der Federn fixiert.
Die anderen drei Punkte (A und B sowie der Kraftangriffspunkt) wurden durch einen User Defined Constraint nur in der Z-Richtung gesperrt, alle anderen Freiheitsgrade sind offen. Siehe zweiten Screenshot.

(5) Wichtig: Da ich beim Anbringen der Verbindungselemente nicht auf die Richtung geachtet habe, wird die Lösung auf einen Fehler laufen. Die RBE2er koppeln Knoten miteinander, das heißt der Master-Knoten gibt seine Verschiebungen 1:1 an einen Slave-Knoten weiter. Da ein Slave-Knoten aber keine zwei Master-Knoten haben kann, schepperts. Um diese Konflikte aufzulösen, ist es nötig, die Option "AUTOMPC = YES" zu setzen. Dazu wie folgt vorgehen:

#RMB auf die Solution #Edit.
Links auf #Case Control, dann rechts neben bei "Parameters (PARAM)" auf #New Modeling Object gehen.
Hier die Option AUTOMPC auf YES setzen (siehe dritten Screenshot).

Anschließend kann die Sol101 gelöst werden. Die Ergebnisplots hänge ich im nächsten Post an (gehen immer nur drei Anhänge pro Post).

------------------
Gruß   

Markus

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

---

260312_Result_X.jpg 260312_Result_Y.jpg 260312_Result_Mag.jpg

Nun zu den Lösungen. Zur Erinnerung die Lösung aus dem analytischen Vorgehen:

A = 1mm nach rechts, 1mm nach unten (also gesamt 1,414mm nach rechts unten)
B = 1mm nach rechts, 3mm nach unten (also gesamt 3,162mm nach rechts unten)

Die Ergebnisplots decken sich mit der analytischen Lösung, das Simulations-Setup scheint mir deshalb ok zu sein. Ich hab's auch mit anderen Lastfällen und -Richtungen probiert - hat bisher immer problemlos geklappt.

Erster Screenshot: Verformung in X-Richtung
Zweiter Screenshot: Verformung in Y-Richtung
Dritter Screenshot: Gesamtverformung

Genau so sollte es auch bei dir funktionieren.

------------------
Gruß  

Markus

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

---

Hallo Markus,
vielen Dank für deine Mühe und die schnellen Antworten! Entschuldige die späte Rückmeldung, ich war ein paar Tage verhindert aber habe mich jetzt wieder drangesetzt.

Am liebsten würde ich das Thema einfach löschen, weil mir der Fehler so peinlich ist.
Ich mache es kurz: Ich habe nochmal viel probiert, konnte aber garnicht sagen bei welchen Eingaben oder Einstellungen es funktioniert und bei welchen nicht, habe dein Beispiel nachgebaut, dachte es liegt daran, dass ich CBUSH anstatt CBUSH1D verwendet habe, da es mit CBUSH mal funktioniert hat und mal nicht, aber es lag im Endeffekt an zwei, durch versehentliche Doppelerstellung, übereinanderliegenden Knoten.

Da ich remote auf das Programm zugreife gibt es manchmal Verzögerungen bei Eingaben, daher habe ich wohl manchmal versehentlich Knoten doppelt erstellt. Dann wurde der eine Knoten in der .fem Datei mit dem CBUSH verknüpft und der andere Knoten in der .sim Datei fixiert. So kam es, dass ich durch Kopieren und Neuerstellen der .fem Dateien Versionen hatte, bei denen mal der eine Knoten, mal der andere Knoten und mal kein Knoten doppelt erstellt wurde.

Die doppelt erstellten Knoten sind natürlich sichtbar, und ich habe mich auch gefragt warum da an manchen Knoten orangene Sternchen sind, aber ich habe es leider nicht weiter hinterfragt und bin daher nicht darauf gekommen, dass das immer der Knoten war, welcher in der .f06 Datei als Fehler gemeldet wurde. Ich habe diese Knoten natürlich kontrolliert, aber in der .fem Datei waren sie ja mit dem CBUSH verknüpft und in der .sim Datei fixiert. Augenscheinlich also alles in Ordnung aber es war eben nicht derselbe Knoten.

Ich danke dir für deine Hilfe! Auch wenn es quasi nur indirekt war hat es trotzdem zur Lösung des Problems beigetragen.

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