|
|
| Bensen83 |
Forum-Fortgeschrittener
|
 |
Beiträge: 91
|
|
|
|
Anmeldedatum: 09.11.07
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
 |
|
Verfasst am: 19.01.2009, 16:54
Titel: Encodersinal auswerten
|
 |
|
Hallo, ich habe einen Servomotor, welcher ein Encodersignal ausgibt und zwar 2 um 90 grad verschobenerechtecksignale. Allerdings flackern diese auch auf und ab, wenn der Motor sich gar nicht dreht. hat jemand e Ide, wie ich diese Signale auswerten kann, dass ich eine relativ genaue Drehahl raus bekomme?
|
|
|
|
|
|
| Dave86 |
Forum-Century
|
|
Beiträge: 113
|
|
|
|
Anmeldedatum: 31.07.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 17:42
Titel:
|
|
Hi Bensen83,
zuerst solltest du die Zeitwerte deiner Flanken abfragen und irgendwie hinterlegen können! Da alle Flanken im Abstand von 90° folgen, kannst du aus dem Weg (der ist ja immer 90°) die Geschwindigkeit in min^-1 durch den entsprechenden Algorithmus bestimmen!
Gruß Dave
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 17:54
Titel:
|
|
@dave: Das mit den 90° bezieht sehr vermutlich auf die zwei Signale zueinander. Der Abstand zwischen zwei steigenden Flanken innerhalb eines Signals (eine Periode des Ausgangssignals) wird auf 360° festgelegt. Der Drehzahlgeber dreht sich dabei aber nur ein ganz kleines Stückchen weit z.B. 1/1024 Umdrehung.
Das wird verwendet, um die Drehrichtung feststellen zu können.
Wenn der Geber allerdings im Stand irgendwas beliebiges ausgibt, wird es schwer, daraus letztendlich ein vernünftiges Drehzahlsignal zu erzeugen. Funktioniert er denn richtig, wenn sich der Motor dreht? Hast Du evtl. ein Oszilloskop zur Verfügung, um da mal genau hingucken zu können?
|
|
|
|
| Idefix_1024 |
Forum-Century
|
|
Beiträge: 230
|
|
|
|
Anmeldedatum: 16.10.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 18:13
Titel:
|
|
also da muss ich leider extrem einschreiten
die beiden Siganle haben sehr wohl IMMER 90° zueinander
lediglich durch die Kenntnis ob Signal A zuerst einen Flankenwechsel hat oder Signal B kann man die Richtung feststellen
wer was anderes behauptet sollte mal dringend Wikipedia oder Google um Rat fragen und mir ganz schnell nen Link schicken wo da was von 360° gesagt wird
meist gibt es noch ein sog. Index Signal, so dass man bei einer kompletten Umdrehung durch einen Puls seine Zähler rücksetzen kann. Damit wird ein Überlaufen der Zähler-Variablen verhindert
aber sowas seltsames wie Epfi hat mir noch nie jemand verkaufen wollen...
|
|
|
|
| Idefix_1024 |
Forum-Century
|
|
Beiträge: 230
|
|
|
|
Anmeldedatum: 16.10.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 18:17
Titel:
|
|
ich hab da auf die Schnelle auch gleich ein sehr schönes pdf im Netz gefunden das die Welt der Inkrementalgeber recht umfassend darstellt
http://www.ifm.com/obj/S400d.pdf
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 18:20
Titel:
|
|
| Idefix_1024 hat Folgendes geschrieben: |
| wer was anderes behauptet |
Ich glaube, hier hat nie jemand etwas anderes behauptet - lies einfach nochmal langsam durch, was ich geschrieben habe und guck die "Skizze" an. Es ist das Selbe, was Du auch gesagt hast.
Ich habe lediglich hinzugefügt, dass es sich bei den 90° nicht um 90° an der Encoderwelle (also mechanische 90°) handelt sondern um 90° zwischen den beiden Signalen und dass eine Signalperiode (also die Zeit zwischen zwei steigenden Flanken) dabei 360° entspricht. Eben so, wie es in der Skizze gemalt ist.
|
|
|
|
| Idefix_1024 |
Forum-Century
|
|
Beiträge: 230
|
|
|
|
Anmeldedatum: 16.10.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 18:54
Titel:
|
|
also auch nach mehrmaligem Lesen kann ich die Skizze nicht so interpretieren dass sie richtig wird... (mag an mir liegen)
Signal 1 und 2 liegen 90° zueinander und JEDES periodische Signal das ich auf dieser Welt wiederholt sich nach 360°. Wie man aus 360° dann die Drehrichtung erhalten kann würde mich schon auch nochmal interessieren...
aber wenn Du denkst dass wir einer Meinung sind... *beruhigtGuck*
|
|
|
|
| Bensen83 |
Themenstarter
Forum-Fortgeschrittener
|
|
Beiträge: 91
|
|
|
|
Anmeldedatum: 09.11.07
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 19:43
Titel:
|
|
|
also ich habe sie mit dem oszi nachgemessen, das Signal B hat henau in der hälfte des "Highzustandes" des signals A einen steigende Flanke, also immer 90° das funktioniert auch, nur wenn man den motor nicht bewegt flackert immer ein signal, ich wollte nun schon darauf gehen, dass ich einfach dann wenn sie nicht 90° verschoben sind die drehzahl 0 setze, aber ich werde wahrscheinlich ehr einen µC benuzen müssen weil ich später anhand der drehung auf die age, bzw. den zurückgelegten weg schließen muss und dafür wird Matlab dann über den Rechner zu langsam sein. wenn ich noch den weg berechne verpasse ich schon die nächsten werte, oder ich müsste sie währenddessen berechnen, was meint ihr denn?
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 20:01
Titel:
|
|
| |
 |
 |
| Zitat: |
| aber wenn Du denkst dass wir einer Meinung sind... *beruhigtGuck* |
Was die Encoder angeht, bin ich mir recht sicher, dass wir da gleicher [richtiger] Auffassung sind.
| Zitat: |
| JEDES periodische Signal das ich auf dieser Welt wiederholt sich nach 360° |
Das hingegen ist eine gewagte Aussage! Ich halte mal mit dem Tangens und der Funktion y = sin(2x) dagegen. Beide sind 180°-Periodisch. Auch die Wochentage wiederholen sich im Abstand von 7 Tagen und nicht etwa 360° (ja, ich weiß - der hinkt).
Es ergibt sehr wohl fast immer Sinn, periodische Signale auf 360° umzurechnen, gezwungen wird dazu aber niemand und wenn man damit nicht öfter mal konfrontiert wird, ist es mitnichten selbstverständlich.
| Idefix_1024 hat Folgendes geschrieben: |
| Signal 1 und 2 liegen 90° zueinander |
Siehe bemaßte Skizze:
Eine Periode wird zu 360° festgelegt und daraus ergibt sich eine Verschiebung der beiden Signale um 90°.
| Zitat: |
| Wie man aus 360° dann die Drehrichtung erhalten kann würde mich schon auch nochmal interessieren... |
Gar nicht. Hat ja auch niemand behauptet. Ich habe lediglich zuerstmal 360° definiert, bevor ich daraus 90° ableite. "90° Versatz" zwischen zwei Signalen kann so ungefähr alles bedeuten, wenn man nicht stillschweigend davon ausgeht, dass jeder weiß, dass man bei einem Encodersignal aus einem Encoder mit 1024 Strichen mit "360°" die Rotation um 1/1024 Umdrehung meint und nicht die Drehung der Encoderwelle um 360° (was wohl die meisten Menschen annehmen dürften).
EDIT: Skizze verbessert, waren 45° Phasenverschiebung. Nimmt sich aber vom Prinzip nichts.
@Bensen83: Das mit dem Flackern ist natürlich hässlich. Hört das auch auf, wenn Du ganz langsam drehst? Sonst fängst Du dir da ja ganz viele hässliche Fehler ein... Zu prüfen, ob die Flankenfolge stimmt ist aber ne gute Idee.
Nichts desto trotz schadet sicherlich ein kleiner Atmel nicht, der das Signal auswertet und dann die Werte weiterreicht. Ob das jetzt das Encoder-Signal ist, oder direkt der zurückgelegte Wert ist ja dann egal. Würde aber so viel, wie möglich den Atmel machen lassen. So ein nacktes Matlab ist nicht unbedingt für Echtzeitanwendungen geeignet - gibt es hier im Board auch gerade irgendwo anders eine Diskussion dazu.
|
|
|
|
| Idefix_1024 |
Forum-Century
|
|
Beiträge: 230
|
|
|
|
Anmeldedatum: 16.10.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 20:31
Titel:
|
|
| |
|
|
@Epfi
gut
ich würde sagen ich hab evtl. einige Dinge auch falsch verstehen wollen
Friede ?
@Bensen
zu den Signalen:
wieviele Inc/U Inkremente pro Umdrehung hat denn der Geber überhaupt?
ich könnte mir vorstellen dass bei 5000 Inc/U eigentlich fast immer eine Flanke in den Signalen zu sehen ist, da 360°/5000Inc = 0,072° pro Inkrement (mechanisch von außen gesehen!)
und das ergibt schnell mal gezappel...
dreh doch einfach mal langsam von Hand dran und skalier das Oszilloskop, so dass du ein Bild mit zwei Rechtecksignalen hast, so wie's Epfi völlig richtig skizziert hat.
Wird schon gehen. Wenn ein Geber hinüber ist gibt er eigentlich meistens gar nix mehr aus... meistens
Bevor Du mit einem Atmel dran gehst solltest Du überlegen ob der so hochauflösende Geber auch in dem Drehzahlbereich den Du willst auswerten kann... ich hab das nur mal mit 1024 Inkrementen, nem 16kHz Quarz und nem ATMega8 gemacht... ging OK aber ned sooo toll
und wie der dann mit Matlab reden soll muss man sich auch überlegen...
eine Echtzeitregelung ist so nämlich auch noch ned möglich fürchte ich.
Vielleicht schreibst Du nochmal genau was Du mit der Drehzahl machen willst... die Lage scheint ja auch noch interessant zu sein... wird das eine Lageregelung ?
Dann würde ich dazu raten entweder professionell mit einer Lösung von Epfi einzusteigen oder mit mindestens einem großen Atmel (müßt ich gucken obs da was gibt), der auch Analog-Digital Eingänge für Strommesswerte hat
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 20:50
Titel:
|
|
| |
|
|
@idefix: Krieg ist was anderes ;) Trotzdem Friede.
Wenn ich das richtig verstehe, hat er das Encodersignal schon als 0/5V-Signal anliegen. Das kann er doch direkt an einen ATMega8 oder einen seiner Brüder (48, 88, 168) anstecken. Die sind nicht wirklich teuer und haben doch schon recht viel Power. Quarz dazu und gut. Das sollte für einen 1024-Strich-Encoder inklusive Kommunikation und ein bisschen Rechnerei reichen. Außer man kommt auf die Idee, floats zu dividieren oder so ;)
Signal vom Atmel nach Computer geht ganz gut über RS232, weil beide Systeme es von Haus aus sprechen. Übertragung wenn es schnell gehen soll irgendwie binärcodiert, oder, wenn man Zeit hat, mit sprintf() als ASCII schicken und auf dem Rechner dann wieder zurückcodieren.
Und wenn Du eine Regelung bauen willst und der Atmel schonmal da ist, kannst Du eigentlich gleich die ganze Regelung auf dem Atmel umsetzen und mit Matlab nur noch Statuswerte per RS232 abziehen und ab und zu mal Steuerbefehle schicken ;)
|
|
|
|
| Bensen83 |
Themenstarter
Forum-Fortgeschrittener
|
|
Beiträge: 91
|
|
|
|
Anmeldedatum: 09.11.07
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 21.01.2009, 23:57
Titel: mmh
|
|
|
Naja es ist so, ich will über die Position des Motors ein bestimtes drehmoment vorgeben, dazu muss ich natürlich genau wissen wo sich dieser befindet. die encodersimulation des Servoreglers istim moment auf 64 inc/umdrehung eingestellt, da sonst Matlab mit den Umdrehungen (1500-2000) nicht mehr mit kommt. ich hatte mir jetzt schon mal für die aufnahme überlegt die datenaufnahme zu starten nachdem ich die letzten ausgelesen habe und die berechnungen zu machen und dann erst wieder auszulesen udn wieder zu starten, meint ihr das könnte von den Zeiten her klappen? also würde dann nur auf 2 steigende flanken oder so schauen. wie lange muss ich denn eigentlich so ca. für eine befehlszeile in Matlab rechnen? kennt da jemand nen Wert?
|
|
|
|
| Epfi |
Forum-Meister
|
|
Beiträge: 1.134
|
|
|
|
Anmeldedatum: 08.01.09
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 22.01.2009, 09:19
Titel:
|
|
| |
|
|
Muss die Drehrichtung denn auch ausgewertet werden? So lange Du nicht um n=0 regeln willst und die Drehrichtung im Normalbetrieb bekannt ist, muss das ja eigentlich nicht sein. Das spart schonmal ne Menge Rechnerei und halbiert die zu verarbeitende Datenmenge.
Wie schnell Matlab etwas ausführt, kannst Du mit tic und toc messen.
Ob das mit dem |: Auslesen, berechnen, Drehmoment einstellen :| klappt, hängt von Deinem zu regelnden System ab. Du setzt ja mit dem Verfahren die Abtastrate sehr, sehr weit runter. Wenn Du zu langsam abtastest rutscht Du in den instabilen Bereich und die Regelung funktioniert nicht mehr zuverlässig. Hängt also auch von Deinem System und den vorkommenden Zeitkonstanten ab. Wenn die Geschwindigkeitsänderungen dort z.B. wegen großer Massen sehr langsam passieren, kann es durchaus auch reichen, die Geschwindigkeit etwas langsamer abzutasten.
Würde mir an Deiner Stelle aber trotzdem Gedanken um eine komplette Umsetzung auf einem kleinen µC machen.
|
|
|
|
| Dave86 |
Forum-Century
|
|
Beiträge: 113
|
|
|
|
Anmeldedatum: 31.07.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 22.01.2009, 09:24
Titel:
|
|
Guten Morgen zusammen!
Mal ne Frage, wertest du die Signal mit einem Oszilloskop erst aus, speicherst sie in einer Datei und übergibst sie dann anschließend MATLAB oder liest du sie irgendwie direkt von deiner "Hardware" aus in MATLAB ein?
Ich bin zur Zeit an nem Ähnlichen Problem! Ich hab zwei Gebersignaler vor mir liegen, beide um 90° versetzt (Sinus/ Kosinus), bei einer Auflösung von 1024 Inkrementen pro Umdrehung. Die Frage, welche in den letzten Tagen bei mir ebenfalls aufgekommen ist, ist die mit dem Richtungswechsel, wie ich den detektieren kann!
Gruß Dave
|
|
|
|
| Idefix_1024 |
Forum-Century
|
|
Beiträge: 230
|
|
|
|
Anmeldedatum: 16.10.08
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 22.01.2009, 10:28
Titel:
|
|
| |
|
|
zum Thema Zeit
wir wissen ja nun hier nicht viel von Deinem System und wie Epfi schon richtig gesagt hat ist das entscheidend ob die 5ms Abtastzeit ausreichen.
was ist das denn für ein Servomotor? Gleichstrommotor (zwei Leistungsanschlüsse) mit Getriebe und Geber oder Drehstrommotor (drei Leistungsanschlüsse) oder was?
Für eine Stromregelung wird 5ms = 200Hz definitiv nicht ausreichen! und wenn du Drehmoment abhängig von Position vorgeben willst... hmm Drehmoment ist in erster Näherung gleich Strom
ein Motor hat elektrisch etwa PT1 Verhalten (1/R)/(1+(L/R)*s)
mit R = Wicklungswiderstand und L = Induktivität der Spulenwicklungen
die Stromregelung MUSS schneller sein (und zwar deutlich, sagen wir Faktor 10) als das PT1 Verhalten sonst wirds nicht gehen... also etwa L/R > 10 * 5ms und das wird kaum der Fall sein fürchte ich
ich würde mich da eher von Matlab verabschieden und nach einem Controller suchen der das leisten kann
oder eben bei Epfi anrufen... je nachdem ob das nur in Deinem Hobbykeller laufen soll oder mal eine Industrielösung wird...
|
|
|
|
|
Gehe zu Seite 1, 2 Weiter
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2024
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|
