Hallo und guten Tag zusammen! Kurz zum Hintergrund meiner Problematik: Ich betreibe einen Maxon EC6 mit Hallsensoren und einer starken Untersetzung. Ungeregeltes Bewegen funktioniert mit der aktuellen Elektronik (Allegro A4915 Motortreiberbaustein) problemlos, ich möchte dem Motor aber gerne eine Positionsregelung verpassen. Einen zum Motor gehördenen Encoder zu benutzen, kommt aufgrund des beschränkten Bauraums leider nicht in Frage, der Motor würde für die mobile Anwendung dann zu lang werden. Stattdessen folgender Gedanke: Ich untersetze sehr stark (221:1) und übertrage das ganze anschließend auf eine Schwenkmechanik welche mit 2 Umdrehungen der Getriebeabtriebswelle 100° Schwenkbewegung macht. Hier ist mir eine Positioniergenauigkeit im Bereich von 1° völlig ausreichend. D.h. ich habe rechnerisch 440 Motorumdrehungen für den vollen Bewegungsumfang, d.h. ca. 4 Motorumdrehungen pro 1° Schwenkbewegung. Ich würde jetzt gerne einfach die Hallsensor-Signale des EC-Motors nutzen um meine Positionsbestimmung durch zu führen. (Zwar an sich nur eine sehr "grobe" Positionsbetsimmung, bei 4 Umdrehungen pro gewünschtem 1° Genaugikeit aber völlig ausreichend). Ich habe mir überlegt die Hallsensor-Signale z.B. auf die entsprechenden Counter Eingänge meines µC (z.Z. PIC18F25K22) zu legen. Um eine Richtungsinformation zu erhalten, langt einfaches Mitzählen nicht, ich muss hierfür bei jeder Signaländerung einen Interrupt auslösen und die (gespeicherten) alten Zustände der Hallsensoren mit den aktuellen vergleichen. Sollte eigentlich kein Problem darstellen. Aaaaber: Bei einer Nenndrehzahl von 750 1/s des Motors und 6 Zustandsänderungen pro Umdrehung bekomme ich alle (1/(750*6))=0,000222s einen Interrupt. Ich befürchte, nun zwei Dinge, erstens wird mir die Zeit zum ausführen des eigentlichen Regelungsalgorithmus sehr eng werden (sollte aber trotzdem lösbar sein). Zweitens bekommt der µC seine Sollwerte via I2C übermittelt. Dessen Interrupt braucht meiner Erfahrung nach höchste Priorität, da die Kommunikation sonst Probleme bereitet. D.h. entweder verliere ich während der Kommunikation Positionsinformationen, weil im worst Case mehrere Hallsensro-Interrupts hintereinander nicht abgehandelt werden, oder ich störe meine Kommunikation :( Jemand eine Idee, wie das gelöst werden könnte? Gibt es vielleicht Logik/Tachobausteine (gerne BUS-fähig) die aus den Hallsensor-Signalen ein einfaches Rechtecksignal und ein FORWARD/BACKWARD Signal generieren? Ich habe bereits nach EC-Motortreibern gesucht, es gibt welche mit Tachofunktion, die genau das ausspucken, aber meine sonstigen Spezifikationen leider nicht erfüllen (Riieeeeßige Teile). :( Sorry für soviel Text, habe versucht, dass Problem und meine Gedanken dazu so detailiert wie Möglich zu beschrieben. Danke für lesen und mitdenken, Dominik
Vergiss das mit dem Flanken-Interrupt. Nimm einen Timmer und schau dir zyklisch den Zustand der drei Hallsensor-Leitungen an. Die Auswertung funktioniert dann im Prinzip genauso wie bei einem Encoder mit 2 Signalen, Tabellen-basiert. Das sind nur wenige Zeilen Code, die im Timer-Interrupt benötigt werden. Edit: Ein "Tacho" gibt übrigens ein analoges, von der Geschwindigkeit abhängiges Signal. Das ist sichelich nicht das was du meinst?! Du redest vermutlich von einem Encoder-Signal. Dein Hallsensor ist aber nichts anderes, nur mit 3 statt mit 2 Spuren. Mit freundlichen Grüßen Thorsten Ostermann
:
Bearbeitet durch User
Thorsten Ostermann schrieb: > Vergiss das mit dem Flanken-Interrupt. Nimm einen Timmer und schau dir > zyklisch den Zustand der drei Hallsensor-Leitungen an. Die Auswertung > funktioniert dann im Prinzip genauso wie bei einem Encoder mit 2 > Signalen, Tabellen-basiert. Das sind nur wenige Zeilen Code, die im > Timer-Interrupt benötigt werden. Das würde ich nicht machen, da die Abtastrate immer >=5 kHz liegen müßte, um 0,222 ms Impulsabstand zu erkennen. Da sind die Flanken-Interrupts angenehmer ;-) Dominik H. schrieb: > Zweitens bekommt der µC seine Sollwerte via I2C übermittelt. > Dessen Interrupt braucht meiner Erfahrung nach höchste Priorität, da die > Kommunikation sonst Probleme bereitet. Dann stimmt etwas mit Deiner IIC-Übertragung nicht, oder erledigt der PIC das nicht mit Hardware?
Thorsten Ostermann schrieb: > Vergiss das mit dem Flanken-Interrupt. Nimm einen Timmer und schau dir > zyklisch den Zustand der drei Hallsensor-Leitungen an. Die Auswertung > funktioniert dann im Prinzip genauso wie bei einem Encoder mit 2 > Signalen, Tabellen-basiert. Das sind nur wenige Zeilen Code, die im > Timer-Interrupt benötigt werden. > > Edit: Ein "Tacho" gibt übrigens ein analoges, von der Geschwindigkeit > abhängiges Signal. Das ist sichelich nicht das was du meinst?! Du redest > vermutlich von einem Encoder-Signal. Dein Hallsensor ist aber nichts > anderes, nur mit 3 statt mit 2 Spuren. > > Mit freundlichen Grüßen > Thorsten Ostermann Hi Thorsten, was spricht gegen den Flankeninterrupt? Ist doch eigentlich einfacher, als die Alternative, vor allem wird nur dann ausgelöst, wenn wirklich nötig. Was dann abgehandelt wird, ist ja eine andere Fragestellung. Tacho war die beste Bezeichung die mir einfiel. Am besten wäre ein Rechtecksignal mit Flankenwechsel pro Kommutierungsänderung und ein Kanal High/Low für Vorwärts/Rückwärts, so spucken es auch die EC-Treiberbausteine aus. Das wäre µC-seitig deutlich einfacher/blitzschnell zu handeln.
Thorsten Ostermann schrieb: > Edit: Ein "Tacho" gibt übrigens ein analoges, von der Geschwindigkeit > abhängiges Signal. Das ist sichelich nicht das was du meinst?! Du redest > vermutlich von einem Encoder-Signal. Weder - noch :-) Als Tachosignal wird im allgemeinen bei BLDC-Ansteuerung und Encodern ein Signal verstanden, was einen Impuls mit einer bestimmten Pulslänge pro Umdrehung liefert. Der hat auch keine Richtungsinformation. Einfach nur ein Impuls pro Umdrehung. Daraus kann die Geschwindigkeit mittels Integrator erzeugt werden (die ist dann analog). Oder eben eine Information, ob der Motor überhaupt dreht. Also die Bezeichnung "Tachosignal" ist in diesem Zusammenhang schon völlig korrekt.
m.n. schrieb: > Thorsten Ostermann schrieb: >> Vergiss das mit dem Flanken-Interrupt. Nimm einen Timmer und schau dir >> zyklisch den Zustand der drei Hallsensor-Leitungen an. Die Auswertung >> funktioniert dann im Prinzip genauso wie bei einem Encoder mit 2 >> Signalen, Tabellen-basiert. Das sind nur wenige Zeilen Code, die im >> Timer-Interrupt benötigt werden. > > Das würde ich nicht machen, da die Abtastrate immer >=5 kHz liegen > müßte, um 0,222 ms Impulsabstand zu erkennen. Da sind die > Flanken-Interrupts angenehmer ;-) Sehe ich auch so. > > Dominik H. schrieb: >> Zweitens bekommt der µC seine Sollwerte via I2C übermittelt. >> Dessen Interrupt braucht meiner Erfahrung nach höchste Priorität, da die >> Kommunikation sonst Probleme bereitet. > > Dann stimmt etwas mit Deiner IIC-Übertragung nicht, oder erledigt der > PIC das nicht mit Hardware? Tut er an sich. Meiner Erfahrung nach (Und frag bitte nicht wieso :D) macht das I2C-Modul zicken, bzw ist nicht mehr ansprechbar, wenn es nach auslösen seines Interrupts zu lang warten muss. Und selbst wenn das glatt geht, muss ich ja trotzdem die ankommenden Daten in meine Variablen schreiben, wenn ihr der Zeit mehr als ein Flanken-Interrupt kommt, gehen die mir wahrscheinlich verloren. Theoretisch wäre es möglich das hinzubekommen, wenn sichergstellt ist, dass die Kommunikation inklusive abspeichern weniger lang dauert, als ein Kommunikationszyklus. Bzw. um den Worst-Case anzunehmen unterbechen des Flanken-Interrupts, abhandeln der Kommunikation und zurückspringen in die Routine des Flankeninterrupts. Jemand ne Idee, ob man das irgendwie berechnen kann, oder am besten über Pin-toggle am Oszi misst, wie lang das jeweils dauert?
Angehängte Dateien:
-
tacho.gif
7,6 KB
Hier mal ein Ausschnitt aus dem L6235, wo man sieht wie der Tacho-Impuls aus den Hallsignalen mittels MMV erzeugt wird.
Dominik H. schrieb: > Meiner Erfahrung nach (Und frag bitte nicht wieso :D) > macht das I2C-Modul zicken, bzw ist nicht mehr ansprechbar, wenn es nach > auslösen seines Interrupts zu lang warten muss. Das würde ich abklären. Ist dort ggf. ein Timeout vorhanden, den man höher setzen könnte? Mit PICs kenne ich mich nicht aus, aber ein Flankeninterrupt mit Zähler sollte doch in weniger als 5 µs abgehandelt sein. IIC nehme ich immer gerne, wenn der µC schon viele Interrupts zu bedienen hat und IIC geduldig auf die Bearbeitung warten kann. Vielleicht ginge bei Dir auch Polling.
Hallo "npn", > Thorsten Ostermann schrieb: >> Edit: Ein "Tacho" gibt übrigens ein analoges, von der Geschwindigkeit >> abhängiges Signal. Das ist sichelich nicht das was du meinst?! Du redest >> vermutlich von einem Encoder-Signal. > > Weder - noch :-) > Als Tachosignal wird im allgemeinen bei BLDC-Ansteuerung und Encodern > ein Signal verstanden, was einen Impuls mit einer bestimmten Pulslänge > pro Umdrehung liefert. Soso. Wer definiert denn hier, was "im Allgemeinen" bedeutet? In der elektrischen Antriebstechnik gibt bzw. gab es analoge Tachogeber. Wenn jemand Tachosignal sagt, geht man in der Antriebstechnik davon aus, dass ein solches Signal gemeint ist. http://de.wikipedia.org/wiki/Tachogenerator Mit freundlichen Grüßen Thorsten Ostermann
Thorsten Ostermann schrieb: > Hallo "npn", > >> Thorsten Ostermann schrieb: >>> Edit: Ein "Tacho" gibt übrigens ein analoges, von der Geschwindigkeit >>> abhängiges Signal. Das ist sichelich nicht das was du meinst?! Du redest >>> vermutlich von einem Encoder-Signal. >> >> Weder - noch :-) >> Als Tachosignal wird im allgemeinen bei BLDC-Ansteuerung und Encodern >> ein Signal verstanden, was einen Impuls mit einer bestimmten Pulslänge >> pro Umdrehung liefert. > > Soso. Wer definiert denn hier, was "im Allgemeinen" bedeutet? In der > elektrischen Antriebstechnik gibt bzw. gab es analoge Tachogeber. Wenn > jemand Tachosignal sagt, geht man in der Antriebstechnik davon aus, dass > ein solches Signal gemeint ist. > http://de.wikipedia.org/wiki/Tachogenerator > > Mit freundlichen Grüßen > Thorsten Ostermann Guten Morgen Torsten, ich schrieb aber nicht von ausdrücklich analogen Tachogeneratoren, sondern vom Begriff "Tachosignal" bei Ansteuerung von BLDC-Motoren. Und dort gilt als Tachosignal nun mal ein Impuls-Signal, dessen Impulshäufigkeit von der Drehzahl abhängt. Ich habe noch das Beispiel vom L6235 (zwei Beiträge darunter) angehängt. Und bei PC-Lüftern beispielsweise (die ja auch mit BLDC angetrieben werden) heißt das genauso "Tachosignal". Da wird einmal pro Umdrehung ein Impuls fester Länge gebildet. Im Gegensatz zu den Hall-Signalen, deren Impuls ja immer bis zum Beginn der nächsten Kommutierungsphase dauert und damit dessen Länge von der Drehzahl abhängt. Damit will ich nur sagen, ich habe nicht von "im Allgemeinen" gesprochen, sondern "im allgemeinen bei BLDC-Ansteuerung". Und daß die Begriffe je nach Anwendungsgebiet unterschiedliche Bedeutung haben können, wissen wir ja beide, oder? Was heißt zum Beispiel "Transmission"? Die einen kennen das Wort nur aus der Zeit, als Maschinen mit Lederriemen von der Decke aus angetrieben wurden. Die anderen sagen, das ist die Durchlässigkeit eines Materials. Der Dritte denkt an die Register-Kopplung von Orgeln und der Vierte meint damit eine Funkübertragung. Und alle haben sie Recht. Aber eben in ihrem speziellen Anwendungsfall. So ist es auch mit dem Begriff "Tachosignal". Er sagt lediglich aus, daß eine Geschwindigkeitsinformation vorhanden ist. Ob die jetzt analog oder digital oder sogar in Form eines Zahlenwertes auf dem CAN-Bus vorliegt, bleibt es doch ein Tachosignal. Einverstanden? :-)
>Wenn jemand Tachosignal sagt, geht man in der Antriebstechnik davon aus Das ist eben nur die halbe Wahrheit. Die andere Hälfte ist, das z.B. jeder Lüfter mit Tachoausgang ein digitales "Ich dreh mich mit..." rausgibt. Das ist wenn man Lüfter synchronisieren will um akustische Schwebungen loszuwerden auch gut so. Dein Problem lässt sich mit einem Timer auf external clock source bewältigen. Der zählt halt einfach vor sich hin und ab und zu fragst Du wie weit er schon ist. Die Drehrichtung musst Du natürlich eigenständig händeln. Evtl. können Deine Timer auch Quadratursignale direkt verarbeiten. Schau Dir einmal bitte: http://ww1.microchip.com/downloads/en/AppNotes/00696a.pdf an und Vergleiche mit Deinem Controller. viel Erfolg hauspapa
Hallo "npn", > So ist es auch mit dem Begriff "Tachosignal". Er sagt lediglich aus, daß > eine Geschwindigkeitsinformation vorhanden ist. Ob die jetzt analog oder > digital oder sogar in Form eines Zahlenwertes auf dem CAN-Bus vorliegt, > bleibt es doch ein Tachosignal. > > Einverstanden? :-) Na gut ;) Mit freundlichen Grüßen Thorsten Ostermann
>Gibt es vielleicht >Logik/Tachobausteine (gerne BUS-fähig) die aus den Hallsensor-Signalen >ein einfaches Rechtecksignal und ein FORWARD/BACKWARD Signal generieren? Altmodische Lösung: Onsemi MC33039 als Taktquelle und ein Zustandsautomat aus 1x74HC175 und 2x74HC00 Das ganze bedient dir 2 Timer mit externer Taktquelle. Einer zählt Schritte rechts rum, der andere Schritte links herum oder 1 Timer mit up/down. Auf 6 Positionen pro Umdrehung genau. Den Zustandsautomaten mit 3 ICs könnte man genauso altmodisch in eine Eprom mit mindestens 7 Adress und 5 Datenleitungen schreiben. Ohne Zusatzlogik mit 3 Position pro Umdrehung. Ein kleiner 8 Haxel PIC oder Attiny in Endlosschleife nur für diese Aufgabe macht das sicher ohne weiteres drum herum. Ein 6 Beiner geht auch, dann aber nur 4 Positionen pro Umdrehung. Irgendwie klingt Dein Problem sehr "dienstlich". viel Erfolg Hauspapa
:
Bearbeitet durch User
Eigentlich sollte direktes Mitzählen bei >1ms zwischen den Interrupten auch für den Hauptproessor keine grosse Hürde sein. Um grosse Handstände zu vermeiden sollte der Interrupt innerhalb 200us angesprungen werden. Der gesamte Drehbereich passt in eine 16 bit Variable, alles andere passt in 8 bit. Das gibt <1% zusätzliche Prozessorlast. Die Interruptdauer (Einsprung, Pins einlesen, Vergleich, Zähler increment/decrement, Rücksprung)müsste man ausprobieren, kann aber nicht sonderlich lange dauern. Eins sauberes Gesamtkonzept vorausgesetzt... viel Erfolg Hauspapa
S. K. schrieb: >>Gibt es vielleicht >>Logik/Tachobausteine (gerne BUS-fähig) die aus den Hallsensor-Signalen >>ein einfaches Rechtecksignal und ein FORWARD/BACKWARD Signal generieren? > > Altmodische Lösung: > > Onsemi MC33039 als Taktquelle > und ein Zustandsautomat aus 1x74HC175 und 2x74HC00 > > Das ganze bedient dir 2 Timer mit externer Taktquelle. Einer zählt > Schritte rechts rum, der andere Schritte links herum oder 1 Timer mit > up/down. > Auf 6 Positionen pro Umdrehung genau. > > Den Zustandsautomaten mit 3 ICs könnte man genauso altmodisch in eine > Eprom mit mindestens 7 Adress und 5 Datenleitungen schreiben. Ohne > Zusatzlogik mit 3 Position pro Umdrehung. > > Ein kleiner 8 Haxel PIC oder Attiny in Endlosschleife nur für diese > Aufgabe macht das sicher ohne weiteres drum herum. Ein 6 Beiner geht > auch, dann aber nur 4 Positionen pro Umdrehung. > > Irgendwie klingt Dein Problem sehr "dienstlich". > > viel Erfolg > Hauspapa Hallo Hauspapa, Danke für die Anregungen. Werde ich mir mal in Ruhe zu gemüte führen :) Was verstehst du unter dienstlich? LG Dome
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.