Viergelenk (Koppelgetriebe) mit direkt angelenkter Koppel
Hallo Welt,
ich möchte ein Koppelgetriebe mit 4 Gelenken, zwei Lenkern/Schwingen und einer Koppel (so etwas, wie in beiliegendem Beispiel) so konstruieren, dass die Eingangsgröße für eine Animation der Winkel der Koppel ist.
In beiliegendem Beispiel -- so wäre der einfache Weg -- muss man einen der Lenker (hier L2) bzw. dessen unabhängigen(?) Punkt (L2'2) bewegen, um das Getriebe anzutreiben. Das lässt sich beispielsweise umsetzen, indem man den Lenker winkelabhängig definiert; hatte ich probiert, funktioniert, ist hier nur gerade nicht eingebaut ...
Stattdessen soll jedoch die Koppel (das blaue Ding rechts) per Definition ihres Winkels zu irgendeinem äußeren Bezug (z.B. x-Achse) das Getriebe antreiben. Wie müsste ich die Koppel dafür definieren? Im Prinzip bräuchte ich eine Strecke (fixe Länge), deren Endpunkte auf jeweils einer Kreisbahn (Lenker1, Lenker2) liegen müssen und für die ich einen Winkel vorgeben kann. Geht das irgendwie zu machen?
Vielen Dank schon einmal :)
Viel zu schwammig Beschrieben.
Und vermutlich schon Beantwortet: Koppelgetriebe mit vier Gliedern oder Suche.
Willst du das?:
Dann machst du das:
Und als Bonus das:
Vielen Dank für die forsche Antwort, aber das, was Du beschreibst, hatte ich vorher schon erreicht (im angehängten Beispiel nur ohne Antrieb und freilich viel weniger elegant).
Ich versuche noch einmal, es zu erklären -- diesmal anhand Deines Beispiels:
Bei Deinem Beispiel ist der "Antrieb" der Animation der Winkel der Strecke MP1 zur x-Achse. Das will ich nicht. Ich will als Antrieb den Winkel der Strecke P1P2 (zur x- oder y-Achse ... pupsegal).
Als Anhang Koppelgetriebe01.
Mit Näherungsverfahren für die Einstellung des Winkels der Koppel (mittels Schieberegler).
Die gegenseitig abhängigen Radien (Schwingen, Koppel) sind so gewählt, dass möglichst ohne gegenseitige Korrektur der Abmessungen mit den Parametern die optimalen Masse und Positionen gefunden werden können.
Anmerkung: in Extrempositionen beginnt das Näherungsverfahren zu schwingen. Dann muss der Divisions-Faktor in speed_0 (zur Zeit 20) erhöht werden.
.
Aber:
Falls das Modell eine physische Realisierung bekommen soll, so ist der Anhang "Koppelgetriebe02" ev. geeigneter. Mit Linear-Motoren liesse sich das Modell noch weiter vereinfachen.
Nach der dynamischen Anpassung des Wertebereichs (dies war der Hauptfehler) vom Schieberegler "winkel" und der Dämpfung für die Approximatin (speed_0) sollte (hoffentlich) das Nachführen von C auch in den Extrempositionen funktionieren.
Natürlich würde das Nachführen von C mittels einer Funktion rascher (ohne Verzögerung) erfolgen.
Allerdings ist das Erzeugen (in Abhängigkeit der Parameter) dieser Funktion ist (für mich) nicht so ohne weiteres machbar.
Ob ich Dir mit dieser Version Freude bereite, wage ich zu bezweifeln. Sie ist noch um einiges Anspruchsvoller als die Vorangehende Version.
Der Vorteil dieser Version liegt darin, dass ein erster Wert (ca auf 1° genau) sehr rasch gefunden wird. Anschliessend läuft im Hintergrund und parallel zu den übrigen Aktionen eine (recht präzise) Annäherung an den vorgegenene Winkel (für Punkt C). Die Geschwinigkeit der Annäherung ist stark abhängig vom vorgegebenen Winkel.
Die erste, rasche Phase basiert auf der Funktion fOLW(). Sie gibt für einen vorgebenen Winkel den (ungefähren) Pfadparameter von C auf a' zurück. Diese Funktion wird mittels einer Ortslinie erstellt, die (unter anderem) mit TrendSin() in eine trigonometrische (!) Funktion überführt wird. Der (vermutlich nach wie vor unverständliche) Rest ist praktisch unverändert. Geändert hat die Berechnung von speed_0, die nun obige Funktion zur Dämpfung mit verwendet (je näher der Funktionswert bei y=0 um so kleiner werden die Iterations-Schritte). Es ist denkbar, dass in extremen Fällen die Annäherung osziliert, dann müsste vermutlich der (jetzige) Wert von 400 im Objekt speed_0 herab gesetzt werden.
.
Ich kann an dieser Stelle nicht den vollständigen Umfang von GGB in einer beliebigen Tiefe erläutern. Vor allem kenne ich dazu Dein Verständnis und Vorwissen nicht. Ich schlage deshalb vor, dass Du in mehreren Schritten möglichst spezifische Fragen stellst, die ich Dir so kompakt und verständlich (wie ich vermag) beantworten werde.
.
Vielleicht ist jemand (Loco, mire2, abakus und und) in der Lage die Formel für die Funktion fOLW() ohne Umweg über die Ortslinie zu erstellen. Das würde die Anwendung erheblich vereinfachen und beschleunigen.
Noch mal vielen Dank, auch für die Erklärungsansätze.
In plumpen Worten würde ich sagen, dass Deine Lösung eine Regelung simuliert, welche durch Stellung von [habe ich noch nicht herausgefunden] auf den Sollwert des Winkels regelt, also die Abweichung zwischen dem Ist-Winkel und dem Soll-Winkel durch ein (zuletzt zweistufiges) Näherungsverfahren minimiert. Mit den mathematischen und programmtechnischen Einzelheiten setze ich mich noch auseinander (vielleicht nach dem Frühstück oder so) ...
Ja, Regelung, Simulation treffen das 2. Verfahren recht gut.
Es wird der Winkel(Vektor(C,D)) also der Winkel der Koppel relativ zur xAchse mit dem Sollwert-Winkel im roten Schieberegler verglichen und bei Abweichung wird der Punkt C auf a' (per Animation ON) in die richtige Richtung in einer adäquaten Geschwinigkeit bewegt. Adäquat meint: nicht zu schnell sodass C nicht über das Ziel hinaus schiesst aber so schnell als möglich, sodass die Regelung möglichst rasch abgeschlossen ist. Mit Annäherung von C an die Position für den Sollwinkel der Koppel wird die Animation verlangsamt. Dies geschieht mit "speed" im Eigenschaften/Algebra im Objekt C.
.
das neue, vorangehende 1. Verfahren ermittelt aufgrund des Winkel-Sollwertes (roter Schieberegler "winkel") mit einer Funktion fOLW() die Soll-Position von C auf a'. Diese Position ergibt den gewünschten Winkel für die Koppel. Die Position von C auf a' ist durch den sog. PfadParameter bestimmt. Es ist dies ein Wert von 0 bis 1 mit der die Länge des Kreisbogens a' unterteilt ist. Der Pfadpameter ist eines der wichtigen Konzepte von GGB, es lohnt sich dazu das Manual zu konsultieren.
.
Im Schieberegler "winkel" befindet sich auch der Skript, der die beiden Verrfahren anstösst.
Stoppen der Animation von C
Verschieben C aufgrund der Funktion (1. Verfahren)
Starten der Animation von C für das 2. Verfahren.
Das Anstossen der Verfahren 1 und 2 geschieht unter der Bedingung, dass das entsprechende Kontrollkästchen (ausgeblendet) auf ON steht. Dies für Testzwecke und allfällig spätere Ergänzungen.
Und zu guter Letzt: Hier noch eine schlichte Lösung für diese interessante Problemstellung (danke dafür).
Siehe auch "Subtread mit Loco"
.
Hinweis:
allle Objekte mit Präfix"H" dienen nur zur Illustration des Lösungsweges, sind also rein zeichnerisch relevant und sind Hilfsobjekte. Die effektive Realisierung ist etwas kompakter.
Ich find die Lösung immer noch total schön :D
Selbst, als sie vor mir lag, musste ich mir längere Zeit den Kopf kratzen. Dabei steckt ja eigentlich "nur" dahinter, dass man Vektoren in beliebiger Reihenfolge addieren kann und dennoch immer beim selben Punkt ankommt bzw. denselben resultierenden Vektor erhält (oder mit Bestandteilen des Getriebes gesprochen: man kann gedanklich Lenker und Koppel tauschen bzw. den Zug aus beiden durch das entsprechende Parallelogramm ersetzen). Aber dieses "Nur" erst einmal in der Aufgabe zu erkennen ...
Eigentlich wollte ich aber eine Frage fragen: Loco, Du benutzt in Deinem letzten Beispiel die Funktion Element(), um von den beiden möglichen Schnittpunkten zweier Kreise nur einen als Ergebnis zu erhalten (im Beispiel war es, glaube ich, der zweite). Hast Du durch Probieren herausgefunden, ob Du den ersten oder zweiten Schnittpunkt nehmen musst, oder gibt es dahinter eine System in GGB?
Comments have been locked on this page!