Flankenerkennung mit Auswertung

Hallo zusammen!

Ich hab ein kleines Problem bei dem ich nicht weiter komme.
Und ja ich hab die Forumssuche schon bemüht, doch leider konnte sie mir nicht weiterhelfen weils bei mir nicht um eine simple Flankenerkennung geht...

Folgendes:
Meine Eingabedaten sind mehrere (viele) Integer-Werte die als Array vorliegen. (Wurden aus einem Controller ausgelesen)
Mich interessiert an jedem Byte jedoch nur das 4te und das 6te Bit (von 0 an gezählt) weil darin die die Abtastwerte eines Rechtecksignals gespeichert sind.
Betrachtet man also nur diese beiden Bits hat man zwei von einander abhängige Rechteckssignale welche einem Auskunft über die Drehrichtung und Drehposition eines Gleichstrommotors geben.
Abhängig deswegen weil die beiden Signale um 90 Grad phasenverschoben sind und bei Drehung in die eine Richtung das erste dem zweiten Signal nachläuft. Bei Drehung in die andere Richtung läuft dann das zweite dem ersten Signal nach.

Mein eigentliches Problem besteht jetzt darin, die Flanken so richtig zu zählen, dass ich zum einen erkenne in welche Richtung sich der Motor dreht, als auch wieviele bereits vorhanden waren um die relative Position des Motors gegenüber der Ausgangsposition zu kennen.

Ich habs schon so versucht in ner Schleife aus jedem einzelnen Byte die beiden relevanten Bits "herauszufiltern" und mit den Bitwerten aus dem vorheringen Schleifendurchlauf zu vergleichen. (einfache Flankenerkennung)
Wenn ich dabei noch versuche die Drehrichtung zu bestimmen kommt irgendwie nicht das richtige raus...

Könnt ihr mir dabei vielleicht helfen?
Am coolsten wäre es eigentlich wenn man direkt aus den einzelnen Bytes mittels irgendwelcher Vektoroperationen die Flanken auslesen könnte. Zwecks Performance (weil ich taste mit ca 500 kHz ab was glaub ich mit ner "manuellen" Verarbeitung in ner Schleife (also Byte für Byte) nicht an die Geschwindigkeit der in LabVIEW implementierten Vektorbibliotheksfunktionen herankommt.)
Also quasi eine Boolsche Operation direkt auf den ganzen Array anwenden oder so. Aber ich hab mir da noch nix vernünftiges ausdenken können.

Ich hab mal mein bisheriges VI angehängt.
Wär cool wenn ihr zumindest mal drübergucken könntet obs soweit stimmt.
Außerdem sind im Anhang noch ein paar vom Controller ausgelesenen Testdaten.

Grüße
Adrian

Hallo Adian,

das was Du suchst nennt sich QuadraturDecoder.
Hier mal die elektronische Variante.

Da stehts wie man es machen kann. Sollte vielleicht aussreichen um sich das testweise in LV auch zu bauen.
Allerdings ist die Frage ob das bei 500kSamples/s nicht besser in einer extra Hardwareschaltung gemacht wird und man das nur das Ergebnis in LV einliest und auswertert.


Gruß,
Rob

Das Problem hat man bei jedem Winkelencoder. Die einzig wasserdichte Lösung ist mit einer state machine mit 4 Zuständen:
   
Die (digitalen) Eingangssignale heißen A und B. Die 4 Zustände entsprechen AB = 00,01,11,10. Wenn die Zustandsänderung in Uhrzeigerrichtung vor sich geht, dann ist der Positionszähler zu inkrementieren und das Vorwärts-bit auf True zu setzen. Bei Zustandsänderung entgegengesetzt dem Uhrzeigersinn das entsprechende Gegenteil.

Bedingung ist natürlich, daß sich niemals die Bits A,B gleichzeitig ändern. Aber wenn das der Fall ist, dann ist es grundsätzlich nicht möglich ordentlich zu zählen - also auch mit keinem anderen Software-Ansatz.

Die Realisierung der state machine mit LabVIEW ist ganz einfach - wenn Du nicht klar kommst, melde Dich.

Edit:
Hier als Morgengabe ein VI
Deine Daten enthalten 47 Fehler, d.h deine 2 Bits ändern sich gleichzeitig, z.B. von 00 auf 11, und da ist es nicht möglich, zwischen Vor- und Rückwärtszählung zu unterscheiden. Man könnte das VI noch so verfeinern: wenn in der Vergangenheit vorwärts gezählt wurde, dann zählt so ein Doppelsprung als 2 Zählungen vorwärts, und umgekehrt. Jetzt wird einfach nicht gezählt.
Bitte nichts fragen, ich habe schon jetzt wieder vergessen, wie ich es gemacht habe.
   

Hab mir Dein VI mal angesehen. Es mag ja vieles richtig gemacht sein, jedenfalls hast Du da ordentlich Gehirnakrobatik betrieben. Ich finde nur, daß doch die hier fehlende Position als Funktion der Zeit die eigentlich interessierende Größe ist, und nicht irgendwelche Hilfsgrößen auf dem Weg dahin. Was sollen solche End-Informationen wie "Anzahl der Flanken A (in pos Richtung" überhaupt?

Thema Verarbeitung:
Es gibt zwei Möglichkeiten der Verarbeitung: Offline oder sofort.

Dir schwebt offenbar ein Sofort-Verarbeitung während der Erfassung vor. Das sind dann aber mehr Punkt-zu Punkt Operationen und keine, wie Du schreibst, Array-Operationen. Mit großen Arrays hat man nur bei der Offline-Verarbeitung zu tun

Und dc6xs hat recht: Mit 500khz ist die Verarbeitungsgrenze erreicht, besser ist hier ein Hardwarelösung. Man kann die oben beschriebene state-machine, die identisch ist mit der Beschreibung im Link von dc6xs, mitsamt einem V/R-Zähler in ein FPGA brennen.

Wow hey vielen Dank euch beiden!!!

Vor allem dir Lucki fürs VI und die Arbeit die du dir gemacht hast!
Hab mir dein VI jetzt solange "angeschaut" bis ichs endlich verstanden hab!
Das Konzept mit ner State Machine ist ne super Idee!

Nachdem ich dein VI verstanden hab hab ich dann versucht mir mein eigenes zu schreiben - wollts nich einfach übernehmen sondern selbst neu entwickeln weil nur so kann ich am Ende sicher sein, dass ichs wirklich verstanden hab ;-) (vorrausgesetzt es funktioniert am Ende)
Und genau das tut es noch nicht... Bei mir werden noch nicht gleich viele Zustandswechsel gezählt wie bei deinem - aber ich denk ich hab irgendwo noch nen 0/1 er Dreher drin. Btw: dein VI passt glaub ich nicht so ganz mit deiner gemalten Statemachine zusammen weil die Bitorder nicht die gleiche ist - aber an sonsten super!

Was meinst du mit:

Zitat:Ich finde nur, daß doch die hier fehlende Position als Funktion der Zeit die eigentlich interessierende Größe ist, und nicht irgendwelche Hilfsgrößen auf dem Weg dahin.

Ich hab halt bisher versucht die Flankenwechsel richtig zu zählen. Über die bekomm ich ja auch die relative Positionsänderung raus. Die Idee mit den vier Zuständen ist allerdings besser.
Aber du hast schon recht was die Endauswertung der Größen betrifft. Wollte erstmal sicherstellen dass richtig gezählt wird und mir dann Gedanken darüber machen wie die Ergebnisse ausgewertet werden sollen.

Zu den Array-Operationen:
Ich lese pro Schleifendurchlauf den kompletten Pufferinhalt des Controllers als Array ein. Nachdem der Puffer 62KByte gross ist ist das Array auch im Extremfall so gross. Ich dachte halt, dass die Vektoroperationen von LabVIEW schneller wären als jedes Byte einzeln zu betrachten.
Allerdings hab ich mal n bischen rumgetestet und festgestellt dass die Laufzeiten sich erst bei Vektorgrößen ab 1 Million Werte deutlich unterscheiden...

Zur Verarbeitungsgrenze:
Ich taste ja nicht in LabVIEW direkt mit 500kHz ab. Das ganze läuft so dass der Contoller die I/O Ports mit ner eingestellten Abtastrate (bis zu 3 MBaud/sec) abtastet und die Werte in nen Puffer schreibt. Diesen Puffer les ich dann in einem Schleifendurchlauf komplett leer und verarbeite die Daten nachträglich.
Deswegen wollt ich auch Vektoroperationen haben weil ich dachte dass dann ein Schleifendurchlauf schneller fertig ist und der Puffer bis zum nächsten mal Auslesen nicht so voll wird.

Dazu kommt allerdings noch, dass der Controller die Lesedaten noch in einen USB-Strom wandeln muss weil ich über USB mit ihm kommuniziere.
Ich weiß dabei nicht was das ganze dann an Performance schluckt.
Wenn ich mir die beiden Signale die ich vom Motor bekomm direkt am Oszi anschau sind es zwei wunderschön gleichmäßige Rechteckssignale die um genau 89,8 Grad phasenverschoben sind.
Les ich das ganze aber in LabVIEW ein - ihr habt ja die Fehlerhaften Eingabedaten (fehlerhafte Zustandswechsel) ja gesehn - hab ich plötzlich keine gleichmäßigen Rechteckssignale mehr!
Allerdings müsste die Abtastrate des Controllers genügen! Zwischen zwei Flanken liegen immerhin ca. 40 Abtastwerte!
Ich benutz das Modul DLP-2232M von der Firma DLP Design welches den Chip FT2232C von FTDI verbaut hat.

Vielleicht fällt euch ja noch was dazu ein?


Grüße
Adrian

' schrieb:Nachdem ich dein VI verstanden hab hab ich dann versucht mir mein eigenes zu schreiben - wollts nich einfach übernehmen sondern selbst neu entwickeln weil nur so kann ich am Ende sicher sein, dass ichs wirklich verstanden hab ;-)

Das würde ich genau so machen, mach weiter so.
Impulsqualität: die Fehler sind ja im Grunde wenige. Ich denke, daß es nicht am Einlesen liegt, sondern eher am Winkelencoder. Untersuch doch mal. ob die Fehler sich bei jeder vollen Umdrehung des Encoders wiederholen, also, wenn der Encoder 500 Impulse pro Umdrehung hat, ob sich der Fehler nach 500 Impulsen wiederholt (Zählimpulsen, nicht Abtsatimpulsen. Beachte auch, daß 4fach gezählt wird, d.h bei jeder Flanke von a und b, 500 I/U = 2000 Zählungen)

Das läßt sich wunderbar prüfen - einfach das neue VI unten verwenden und die Diagramm zoomen.
Beipiel für fehlerhafte Region:
   

Hab das VI wesentlich vereinfacht und versucht zu erklären, Vielleicht gefällt es Dir so auch besser.

Anzeige

Hi Lucki!

Danke für das neue VI und die Erklärung!!
An der Beispielstelle sieht man die Fehler gut!
Stimmt schon es ist nach außen hin einfacher geworden - aber dafür muss man ein wenig mehr Hirnschmalz investieren ums zu kapieren!
Ich denk auch es sollte weng schneller sein als die erste Variante weil hier nicht so viele if-Abfragen drin sind sondern hauptsächlich Integerrechenoperationen.

Was mich an den Fehlern im Signal eigentlich noch mehr stört sind nicht die fehlerhaften Zustandswechsel (also da wo er anscheinend einen Zustand übersprungen hat) sondern die falsch detektierten Zustandswechsel (also Drehungen in die falsche Richtung!)
Denn in meinem Beispielsignal wurde der Motor definitiv nur in eine Richtung gedreht und trotzdem wurde 17 mal die andere Richtung erkannt.
Ok jetzt sind 17 falsch erkannte Zustandsänderungen nicht viel gegenüber 3703 richtig erkannten Zustandsänderungen aber ich frag mich einfach woher das ganze kommt...

Leider kam ich heut noch nicht dazu die Fehler auf Periodizität zu testen. Werd ich aber morgen nachholen und dann bescheid geben!

Übrigens zu meinem nachprogrammierten VI:
Es war wirklich nur ein kleiner Bitdreher :-)
Hab halt auf die Zustände 01 und 10 genau falsch herum reagiert...


Gruß
Adrian

' schrieb:Ok jetzt sind 17 falsch erkannte Zustandsänderungen nicht viel gegenüber 3703 richtig erkannten Zustandsänderungen aber ich frag mich einfach woher das ganze kommt...

Habe mir das mal angesehen, ich sehe in den Fehlern kein strenge Periodizität, der Encoder ist es wohl nicht.
Dafür habe ich einen anderen Verdacht: Kann es sein, das die Abtastung nicht wirklich kontinuierlich ist?

Kontinuierliche Abtastung: Abtastrate muß auf "kontinuierlich" eingestellt sein! Die Werte laufen in einen Buffer, und beim Lesen werden z.B jedesmal 1000 Werte aus dem Buffer gelesen. Das ist OK.

Manche denken aber, wenn sie die Abtastung statt auf kontinuierlich auf z.B 1000 Werte festlegen, und das dann in einer Schleife wiederholen, das wäre auch kontinuierlich. Ist es nicht. Man hat dann zwischen den 1000 Abtastungen immer mehr oder weiniger kurze Pausen, in denen nicht abgetastet wird.

Ich tippe darauf, daß das der Fehler bei Dir ist.

PS: Deine Abtastrate ist sehr hoch. Ausreichend wäre die doppelte Abastrate gegenüber der Zählrate, d.h wenn auf eine vollständige Periode von Signal A oder B 8 Abtastungen kommen. So wie deine Abtastrate jetzt ist, kannst Du noch bis zur 5..10 fach höheren Drehzahl richtig messen. Wenn das verlangt wird, dann ist das OK. Andernfalls könnte man die Abtastrate entsprechend verringern.

Hi Lucki!

Bin jetzt endlich etwas zum weiterarbeiten gekommen und habe auch ausgeschlossen, dass die Fehler periodisch sind.
D.h. der Fehler liegt entweder bei mir oder am Controller. Ich hoffe ja, dass er bei mir liegt glaube aber eher letzteres.

Weil...

Zitat:Kontinuierliche Abtastung: Abtastrate muß auf "kontinuierlich" eingestellt sein! Die Werte laufen in einen Buffer, und beim Lesen werden z.B jedesmal 1000 Werte aus dem Buffer gelesen. Das ist OK.

genau das mache ich bzw der Controller.
Denn sobald ich den Controller mit den entsprechenden Parametern (Timeouts, Baudrate, BitModus, ...) initialisiert habe liest er kontinuierlich mit der eingestellten Baudrate die Eingänge und speichert diese in einen Puffer. Wenn ich den Puffer gar nicht auslese läuft dieser halt irgendwann voll (was relativ schnell passiert wenn ich die maximalen 3MegaBaud/sec einstell). Was passiert wenn er voll läuft weiß ich noch nicht genau - muss ich noch ausprobieren. Aber ein voll laufen soll auf jeden Fall vermieden werden, was bisher eigentlich auch klappt.
Denn ich lese erst mit einer Funktion den aktuellen Füllstand des Puffers aus und lese anschließend alle im Puffer befindlichen Daten aus um diese dann zu verarbeiten (also die Zustandswechsel zu zählen).
Dabei kommt es auch oft genug vor (siehe Anhang), dass der Puffer noch nicht so schnell aufgefüllt wurde und in einem Schleifendurchlauf gar keine Werte gelesen werden. Im nächsten werden dann dafür wieder 10000 Werte auf einmal eingelesen.
Ok so wie ich das gerade beschrieben habe klingt das so als ob die Abtastung wirklich nicht regelmäßig wäre, aber ich hab mir die unterschiedlichen Auslesemengen so erklärt, dass die Schleifen ja auch nicht immer 100%ig gleich lange laufen und so gewisse Verzögerungen entstehen. Außerdem benötigt die Interaktion mit den Controller auch unterschiedlich lang. Oder kann das eher nicht sein?
Jedenfalls dachte ich mir, da ich nicht jeden Lesevorgang selbst vornehme sondern immer blos den Puffer auslese, dass die Abtastung des Controllers schon kontinuierlich ist...

Zitat:PS: Deine Abtastrate ist sehr hoch

Ja ich weiß, ich wollte erstmal schaun, dass es damit funktioniert und dann die Abtastrate entsprechend runterschrauben.
Außerdem läuft der Motor im Moment nur über die 5V die er über meinen USB-Port bekommt. Es gibt allerdings noch die Möglichkeit ihn über eine externe Spannungsquelle mit 12V zu betreiben wobei er dann ca. 4 mal so schnell wird.
Später soll er dann auch so benutzt werden, aber bis das Programm noch in der Entwicklung ist lass ich ihn lieber auf "Sparflamme" laufen da das Betriebsgeräusch auf Dauer doch etwas nervig werden kann ;-)

Werd morgen mal ne Mail an den Controller Hersteller schreiben und den fragen obs am Controller liegen könnte. Hoffe bloß, dass meine Englischkenntnisse da nicht schon zu eingestaubt sind... :-)

Gruß
Adrian