Hallo zusammen, ich bin auf der Suche nach einer effektiven Umsetzung der folgenden Aufgabe: Ich habe einen Zähler mit einem Zählrichtungsbit und einem Zählwert. Der Zähler soll zwischen dem aktuellen und dem neuen Zählwerten eine Rampe abfahren. z.B. Zählrichtung vorwärts - Wert 1000 Wenn nun die Zählrichtung auf rückwärts gestellt wird, soll nicht von einem Takt auf den nächsten von +1000 auf -1000 umgestellt werden, sondern der Vorwärtswert muss erst verkleinert werden (+800, +600, +400, +200, 0) und dann auf -1000 wieder vergrößert (-200, -400, -600, -800, -1000). Genauso soll auch von +2000 auf +1500 diese Rampe ebenfalls abgefahren werden. Also nicht immer nur bei Richtungsänderung... quasi wie ein "Beschleunigungsprofil". Ich möchte gerne eine Art LUT ablegen, in der die Zählwerte hinterlegt sind, also meine Kurve. Der Adressvektor muss dann wandern... Nur wie berechne ich die Adressen? Die Adresse müssen sich ja dann quasi anhand der Differenz des neuen und alten Zählewertes berechnen... ich habe nur einen Knoten im Kopf und weiss nicht wie ich das umsetzen kann. Ich wäre für einen kleinen Gedankenanstoß dankbar! Vielen Dank! Lars
Ich verstehe deine Spec. nicht >Ich habe einen Zähler mit einem Zählrichtungsbit und einem Zählwert Was meinst du mit Zählwert? >z.B. Zählrichtung vorwärts - Wert 1000 Was bedeutet das " - Wert 1000" ? >und dann auf -1000 wieder vergrößert Was bedeutet das?
Lars schrieb: > z.B. Zählrichtung vorwärts - Wert 1000 Wenn du nur 1 Zähler hast, und die Zählrichtung umkehrst, dann ist der nächste Schritt 999, der übernächste 998, dann 997 usw... Was willst du machen? Einen Schrittmotor mit einer Rampe ansteuern? Lars schrieb: > Ich möchte gerne eine Art LUT ablegen Unnötig. Das lässt sich alles in Echtzeit ausrechen. Wofür eine LUT für eine Gerade?
@ Lothar Miller (lkmiller) (Moderator) Benutzerseite >> Ich möchte gerne eine Art LUT ablegen >Unnötig. Das lässt sich alles in Echtzeit ausrechen. Wofür eine LUT für >eine Gerade? Er meint wohl eher die Sollwerte des Zählers über der Zeit. Dazwischen werden die Rampen abgefahren.
Hallo, Stachele schrieb: > Was meinst du mit Zählwert? Quasi der Wert, mit dem der Zähler hochgezählt wird. Zählerstand +/- Zählwert = neuer Zählerstand Stachele schrieb: > Was bedeutet das " - Wert 1000" ? das - ist ein Bindestrich, also hier nicht als Vorzeichen zu sehen... etwas verwirrend, sorry! Lothar Miller schrieb: > Was willst du machen? Einen Schrittmotor mit einer Rampe ansteuern? Ja am Zählerausgang hängt ein mechanisches Gerät, das natürlich eine gewisse Trägheit hat. Dadurch müssen zwischen zwei Werten Rampen gefahren werden, um zu schnelle Änderungen des Sollwertes zu verhindern. Lothar Miller schrieb: >> Ich möchte gerne eine Art LUT ablegen > Unnötig. Das lässt sich alles in Echtzeit ausrechen. Wofür eine LUT für > eine Gerade? Und wie berechne ich es? Ich muss ja quasi alle Fälle abfangen. Ich sehe folgende 10 Szenarien: stillstand => vorwärts stillstand => rückwärts vorwärts => stillstand rückwärts => stillstand vorwärts klein => vorwärts groß vorwärts groß => vorwärts klein vorwärts => rückwärts rückwärts => vorwärts rückwärts klein => rückwärts groß rückwärts groß => rückwärts klein Diese alle in eine Berechnungsvorschrift zu fassen, fällt mir gerade extrem schwer und genau das ist auch mein Problem. Ich könnte jeden Fall in einer Fallunterscheidung anhand der Differenz der Konfigurationszählwerte behandeln, was aber sehr aufwendig werden dürfte?! Vielen Dank! Lars
Lars schrieb: > Diese alle in eine Berechnungsvorschrift zu fassen, fällt mir gerade > extrem schwer und genau das ist auch mein Problem. Variable Rampen brauchst du ja eigentlich nur, wenn Lars schrieb: > Ich sehe folgende 10 Szenarien: > stillstand => vorwärts > stillstand => rückwärts > vorwärts => stillstand > rückwärts => stillstand > vorwärts klein => vorwärts groß > vorwärts groß => vorwärts klein > vorwärts => rückwärts > rückwärts => vorwärts > rückwärts klein => rückwärts groß > rückwärts groß => rückwärts klein Da sind entweder 1. einige Redundanzen dabei: > stillstand => vorwärts > vorwärts klitzeklein => vorwärts Oder 2. es fehlen einige Fälle... > stillstand => vorwärts klein > stillstand => vorwärts groß > stillstand => rückwärts klein > stillstand => rückwärts groß > vorwärts klein => stillstand > vorwärts groß => stillstand > rückwärts klein => stillstand > rückwärts groß => stillstand Mal bezogen auf -100%...100%: Was ist denn der Unterschied, wenn du von 10% auf 100% fährst oder von 0% auf 100% oder von -10 auf 100%? Warum sollte da die Rampe nicht jedesmal gleich sein? Warum kannst du da verschieden steil fahren?
Hallo, Lothar Miller schrieb: > Mal bezogen auf -100%...100%: > Was ist denn der Unterschied, wenn du von 10% auf 100% fährst > oder von 0% auf 100% > oder von -10 auf 100%? > > Warum sollte da die Rampe nicht jedesmal gleich sein? Die Rampe ist in allen Szenarien gleich steil. An dieser Stelle muss also nicht differenziert werden. Deine beschriebenen Fälle haben für mich in der Berechnung den Unterschied, dass sie verschiedene Vorzeichen haben. -----\ \ \ \ /------------ \ / \ / \ / \/ direction 0 | direction 1 Ich habe das Szenario der Richtungsumkehr mit unterschiedlichen Geschwindigkeiten mal versucht zu skizzieren. Der Zählwert wird also vom alten Sollwert aus verringert, bei 0 wird die Richtung umgestellt und der Zählwert wird wieder angehoben auf den Sollwert. Mein Vorzeichenbit ist quasi das direction-Bit. Wenn ich das dem Zählwert am MSB anhänge
1 | direction & zaehlwert(10 downto 0) |
sollte ich doch dann einfacher rechnen können, oder? Ich habe immer wieder Probleme mit signed-Rechnungen und versuche sie stets zu umgehen bzw. zu vermeiden... Vielen Dank! Lars
Lars schrieb: > Mein Vorzeichenbit ist quasi das direction-Bit. Blöd nur, dass es "das Vorzeichenbit" nicht gibt. Denn 000000000001 ist zwar 1, aber 100000000001 ist mitnichten -1... Du willst doch nur zwischen 2 Zählerwerten linear interpolieren. Und das zudem noch mit einer konstanten Rampe. Das ist viel einfacher, als über Beschleunigung und Geschwindigkeit einen Schrittmotor auf Position zu fahren. Du willst nämlich eigentlich nur einen I-Regler bauen...
Lothar Miller schrieb: > Blöd nur, dass es "das Vorzeichenbit" nicht gibt. > Denn 000000000001 ist zwar 1, aber 100000000001 ist mitnichten -1... Genau das ist die Stolperstelle, wieso ich einfach nicht damit klar komme. Eine positive Zahl schaue ich an und weiß sofort welche Zahl gemeint ist. Sobald es in den negativen Bereich geht, komme ich ins Straucheln. Lothar Miller schrieb: > Du willst doch nur zwischen 2 Zählerwerten linear interpolieren. Und das > zudem noch mit einer konstanten Rampe. Genau, ich müsste zwischen altem und neuem Sollwert linear interpolieren und diese entstandene Interpolationsgerade dann vom alten Sollwert zum neuen Sollwert mit den Zählwerten ablaufen. So zählt mein Zähler erst schnell mit dem alten Sollwert, dann langsamer, dann langsam in die andere Richtung und dann wieder schneller bis zum neuen Sollwert (im Fall der Richtungsumkehr). Nur wie laufe ich berechnender Weise an genau dieser Interpolationsgerade entlang? Vielen Dank! Lars
@ Lars (Gast) >> Was meinst du mit Zählwert? >Quasi der Wert, mit dem der Zähler hochgezählt wird. Das nennt man Schrittweite, neudeutsch Increment. >Zählerstand +/- Zählwert = neuer Zählerstand Zähler + Increment = neuer Zähler. >Die Rampe ist in allen Szenarien gleich steil. Was die Sache mal sehr vereinfacht! Einfach hoch oder runter zählen! >Deine beschriebenen Fälle haben für mich in der Berechnung den >Unterschied, dass sie verschiedene Vorzeichen haben. Ja und? Man muss nur zwischen hoch- und runterzählen unterscheiden. Einfacher geht es kaum!
1 | process(clk) |
2 | begin
|
3 | if rising_edge(clk) then |
4 | if ist>soll then |
5 | ist = ist -1; |
6 | elseif ist<soll then |
7 | ist = ist+1; |
8 | end if. |
9 | end if; |
10 | end process; |
>Ich habe das Szenario der Richtungsumkehr mit unterschiedlichen >Geschwindigkeiten mal versucht zu skizzieren. Das widerspricht deiner Aussage oben! >Die Rampe ist in allen Szenarien gleich steil. >Der Zählwert wird also vom alten Sollwert aus verringert, ISTWERT! >bei 0 wird die Richtung umgestellt und der Zählwert wird wieder >angehoben auf den Sollwert. Deine Beschreibung ist konfus. Deswegen hast du auch einen Knoten im Kopf. Es gibt z.B. Sollwert, von aussen vorgegeben. Istwert, istself Regelabweichung, Soll-Ist Schrittweite, entweder fest oder variabel. >Mein Vorzeichenbit ist quasi das direction-Bit. >Wenn ich das dem Zählwert am MSB anhänge Nö, du vermischst hier einiges. Das Zweikomplement ist schon OK. >sollte ich doch dann einfacher rechnen können, oder? Oder. Nimm wie der Rest der Welt das zweirkomplement ohne Getrickse. >Ich habe immer wieder Probleme mit signed-Rechnungen und versuche sie >stets zu umgehen bzw. zu vermeiden... Dann solltest du besser mit VHDL und jeglicher anderer Programmierung aufhören. Oder du lernst endlich, wie das Zweierkomplement funktioniert. http://de.wikipedia.org/wiki/Zweierkomplement Wenn aber zwischen Punkten linear interpoliert werden soll, wird es "ETWAS" aufwändiger. Der Herr Bresenham ist dein Freund. http://de.wikipedia.org/wiki/Bresenham-Algorithmus
@ Lars (Gast) >gemeint ist. Sobald es in den negativen Bereich geht, komme ich ins >Straucheln. Dann lass die Binärdarstellung ruhen und schreib es dezimal. Die Umrechung macht der VHDL-Compiler. >So zählt mein Zähler erst schnell mit dem alten Sollwert, NEIN! Dein SOLLWERT ist die Endposition. Was du verdreht beschreibst ist deine Anstiegsgeschwindigkeit! >dann langsamer, dann langsam in die andere Richtung und dann wieder > schneller bis zum neuen Sollwert (im Fall der Richtungsumkehr). Das sind Beschleunigungsrampen, machbar, aber bei deinem Verständnisstand NOCH weiter weg. Mach es erstmal mit konstanter, niedriger Anstiegsgeschwindigkeit.
Lars schrieb: > Ja am Zählerausgang hängt ein mechanisches Gerät, das natürlich eine > gewisse Trägheit hat. Dadurch müssen zwischen zwei Werten Rampen > gefahren werden, um zu schnelle Änderungen des Sollwertes zu verhindern. Wenn du einen Sprung verhindern willst, gibt den Sprung auf eine entsprechendes Filter, das erzeugt dir nun keine Rampe aber einen gleichmäßigen (e-förmigen) Übergang zwischen den beiden Endpunkten des Sprunges. Aber falls du eine Position regeln willst, nimmt man dazu einen Regler. Es ist sowieso ungünstig einen neuen Algorithmus gleich in VHDL zu implementieren. Teste ihn erst mit Matlab/Octave/Scilab/... und setze ihn dann um. Tom
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.