Drehinkrementalregler am IO Warrior?

Dies ist das deutsche Forum für alle Themen um den IO-Warrior. Beiträge bitte nur in Deutsch.

Moderator: Guido Körber

toga
Posts: 20
Joined: Thu Dec 30, 2004 7:33 pm

Drehinkrementalregler am IO Warrior?

Post by toga »

Hallo,

ich habe vor einen Drehinkrementalregler mit der Tastaturmatrixfunktion des IO40 abzufragen. Da die Zeiten der Impulsflanken ausgewertet werden müssen, weiss ich nicht ob die USB Geschwindigkeit eine saubere Auswertung möglich macht. Bei 30 Rastungen pro Umdrehung sollten es 60 auszuwertende Flanken je Sekunde sein, wenn man in einer Sekunde eine Umdrehung vollzieht. (Also ziemlichj schnell)
Hat jemand ähnliches schon gemacht oder eine Idee über die Realisierungsmöglichkeit am IO40

Danke ins wiederhergestellte Forum
TOGA
Guido Körber
Site Admin
Posts: 2856
Joined: Tue Nov 25, 2003 10:25 pm
Location: Germany/Berlin
Contact:

Re: Drehinkrementalregler am IO Warrior?

Post by Guido Körber »

Mit der Matrixfunktion wird das nichts, die muss nämlich immer zwei Reports senden, also kommt die nur auf die Hälfte der Abtastrate der einfachen I/O.

So of wie Drehgeber nachgefragt werden wird das jetzt bei uns mal auf die To-Do Liste gesetzt für neue Funktionen in einer zukünftigen Version der Chips. Irgend welche Vorlieben für so eine Funktion?
toga
Posts: 20
Joined: Thu Dec 30, 2004 7:33 pm

Drehinkgeber

Post by toga »

Diese Funktion wäre implementiert in die Chips echt suuuper. Toll wäre, wenn u.a. gleich ein auf und abwärts zählender Wert per USB weitergegeben werden könnte. In welchem Zeitraum kann man denn mit solchen Änderungen rechnen?

TOGA
supachris
Posts: 124
Joined: Tue Mar 16, 2004 12:30 am
Location: Dresden

Post by supachris »

Geht das nicht ganz normal mit der Read-Funktion auszulesen? Diese Encoder haben doch nen Gray-Code, bei jedem Schritt ändert sich genau immer nur eines der beiden Bits. Darauf springt doch die normale Read-Funktion an. In der Software muss man dann doch nur noch gucken, ob jetzt hoch oder runter gezählt wurde (nach Maskieren der Bits natürlich). Dafür sollten doch die 125 Reports/s locker reichen, selbst wenns nur die Hälfte wäre noch OK, oder lieg ich jetzt völlig falsch? Klar, is dann nicht entprellt, aber das is ja wieder ne andere Geschichte...
toga
Posts: 20
Joined: Thu Dec 30, 2004 7:33 pm

Post by toga »

Mit dem entprellen würde mich auch mal interessieren. Ist das in der Matrixfunktion schon realisiert oder kann man da eventuell Probleme bekommen?

TOGA
toga
Posts: 20
Joined: Thu Dec 30, 2004 7:33 pm

Post by toga »

Nochmals zu meinen Drehgebern. Diese haben keinen Graycode sondern haben zwei interne Taster die je nach Drehrichtung zeitversetzt schliessen und öffnen.
supachris
Posts: 124
Joined: Tue Mar 16, 2004 12:30 am
Location: Dresden

Post by supachris »

Ja klar, 2 Taster, aber meines Wissens ist das nen 2-Bit Gray Code. Also jedenfalls der normale, den ich mal hatte, war so. Und das is total simpel auszuwerten. Aber wird nen bissl prellen, eigentlich muss da immer nen monoflop rein mit 5-7ms.
wayoda
Posts: 362
Joined: Fri Dec 19, 2003 12:00 pm
Location: Wuppertal/Germany

Re: Drehinkrementalregler am IO Warrior?

Post by wayoda »

Guido Körber wrote:So of wie Drehgeber nachgefragt werden wird das jetzt bei uns mal auf die To-Do Liste gesetzt für neue Funktionen in einer zukünftigen Version der Chips.
Sehr gute Idee, ich habe meinen Drehgeber schon wieder in Regal zurückgelegt.
Guido Körber wrote:Irgend welche Vorlieben für so eine Funktion?
Ein Report könnte die Anzahl der erzeugten Taktimpulse und ein Bit für die Richtung enthalten. Sollte man es schaffen den Drehgeber in den minimalen 8ms um zwei Stellungen links herum und eine Stellung nach rechts zu drehen, ergäbe das also ein Report mit 1 Impuls nach links.
toga wrote: Toll wäre, wenn u.a. gleich ein auf und abwärts zählender Wert per USB weitergegeben werden könnte.
Finde ich nicht so eine gute Idee, eine Zählerfunktion kann man ja ganz einfach in Software implementieren.
Mit der Anzahl der Impulse und der Richtung lässt sich sicher alles abdecken was man für eine Applikation braucht.

Eberhard
Guido Körber
Site Admin
Posts: 2856
Joined: Tue Nov 25, 2003 10:25 pm
Location: Germany/Berlin
Contact:

Re: Drehinkgeber

Post by Guido Körber »

toga wrote:Diese Funktion wäre implementiert in die Chips echt suuuper. Toll wäre, wenn u.a. gleich ein auf und abwärts zählender Wert per USB weitergegeben werden könnte. In welchem Zeitraum kann man denn mit solchen Änderungen rechnen?

TOGA
Momentan ist das in der "man könnte mal" Phase, also noch keine Ankündigung einer neuen Funktion.
Guido Körber
Site Admin
Posts: 2856
Joined: Tue Nov 25, 2003 10:25 pm
Location: Germany/Berlin
Contact:

Post by Guido Körber »

toga wrote:Nochmals zu meinen Drehgebern. Diese haben keinen Graycode sondern haben zwei interne Taster die je nach Drehrichtung zeitversetzt schliessen und öffnen.
Also eigentlich sind das zwei phasenverschobene Rechtecksignale. Je nach Drehrichtung hat man 90 oder 270 Grad Phasenverschiebung.

Und die Dinger mit Schaltern werden wir wegen des Prellens bestimmt nicht unterstützen, wenn dann sollten wir mindestens 1000 Impulse pro Sekunde zuverlässig tracken können und das geht mit Entprellen schlecht.
Guido Körber
Site Admin
Posts: 2856
Joined: Tue Nov 25, 2003 10:25 pm
Location: Germany/Berlin
Contact:

Re: Drehinkrementalregler am IO Warrior?

Post by Guido Körber »

wayoda wrote:Ein Report könnte die Anzahl der erzeugten Taktimpulse und ein Bit für die Richtung enthalten. Sollte man es schaffen den Drehgeber in den minimalen 8ms um zwei Stellungen links herum und eine Stellung nach rechts zu drehen, ergäbe das also ein Report mit 1 Impuls nach links.
Ich denke daran an Port 2 ein bis vier Drehgeber zu unterstützen, jeder bekommt ein Byte im Report in dem ein signed char die Zahl der Pulse seit dem letzten Paket angibt. Bei Umkehrung der Drehrichtung wird ein Report geschickt um möglichst keine Impulse zu verlieren.
wayoda
Posts: 362
Joined: Fri Dec 19, 2003 12:00 pm
Location: Wuppertal/Germany

Re: Drehinkrementalregler am IO Warrior?

Post by wayoda »

Guido Körber wrote: Ich denke daran an Port 2 ein bis vier Drehgeber zu unterstützen..
Ja, sehr gute Idee einen ganzen Port zu nutzen.
Guido Körber wrote: ... jeder bekommt ein Byte im Report in dem ein signed char die Zahl der Pulse seit dem letzten Paket angibt.
Das entspräche doch so etwa meinem Vorschlag.
Guido Körber wrote: Bei Umkehrung der Drehrichtung wird ein Report geschickt um möglichst keine Impulse zu verlieren.
Das verstehe ich leider nicht mehr so ganz? Wären das dann zwei Reports wenn innerhalb von 8 Millisekunden die Drehrichtung gewechselt wird?
Ich glaube das funktioniert auf Applikationsseite nicht so ganz. Werte vom Geber die sich in 8 Millisekunden (mit Drehrichtungsumkehr) ändern bräuchten dann 16 Millisekunden bis sie über den USB-Bus übertragen sind. Das ergäbe also eine theoretische Zeitverzögerung von 100%.

Und während ich das obige gerade geschrieben habe, fällt mir auf, dass die ganze Problematik nicht so trivial ist, wie ich anfangs gedacht habe!
Ich stelle mir gerade vor, ich hätte einen Drehgeber angeschlossen, der kontinuierlich Impulse erzeugt. Dann wäre die gesamte Bandbreite auf dem USB-Bus (1 Report alle 8 ms) schon durch den Drehgeber belegt und der IOWarrior wäre nicht in der Lage noch irgendwelche Reports von anderen Funktionen zu schicken. Sollte man daher vielleicht vorsehen, dass die Drehgeber-Funktion nur alle 32,64 oder 128 Millisekunden einen Report generiert, um den anderen Reports eine Chance zu lassen?

Wäre das in der Firmware machbar?

Eberhard
Robert Marquardt
Posts: 543
Joined: Mon Dec 01, 2003 6:09 pm

Post by Robert Marquardt »

Ich verstehe Guido so das er immer die Anzahl der aufgelaufenen Drehimpulse als vorzeichenbehaftetes Byte liefern will. Das Vorzeichen gibt die Drehrichtung an.
Wehselt die Drehrichtung zwischen zwei Reports, so kann man ja Impulse verlieren wenn der Zaehler nicht zurueckgesetzt wird.
Dieses Zuruecksetzen = Wechsel der Drehrichtung wird dann einfach als ein zusatzlicher Report mit 0 Impulsen signalisiert.
Guido Körber
Site Admin
Posts: 2856
Joined: Tue Nov 25, 2003 10:25 pm
Location: Germany/Berlin
Contact:

Post by Guido Körber »

Robert Marquardt wrote:Ich verstehe Guido so das er immer die Anzahl der aufgelaufenen Drehimpulse als vorzeichenbehaftetes Byte liefern will. Das Vorzeichen gibt die Drehrichtung an.
Wehselt die Drehrichtung zwischen zwei Reports, so kann man ja Impulse verlieren wenn der Zaehler nicht zurueckgesetzt wird.
Dieses Zuruecksetzen = Wechsel der Drehrichtung wird dann einfach als ein zusatzlicher Report mit 0 Impulsen signalisiert.
Nö.

Das Problem ist wenn man den Drehgeber nicht für Eingaben des Users, sondern für Positionsmessungen verwendet. Dann kann man sich es ja nicht leisten wenn der Zähler erst 4 Schritte in die eine Richtung zählt, dann drei in die andere und dann erst der nächste Report gesendet wird. Dann hätte man zwar die richtige aktuelle Position, aber man hat den Extremwert nie gesehen.

Also würde ich so vorgehen, dass erst mal bei einem Richtungswechsel versucht wird einen Report zu senden, wenn das nicht geht wird halt der Zähler in die andere Richtung gezählt bis mal wieder Zeit zum Senden eines Reports ist.

Was die Auslastung der Reports angeht: Die Drehgeberdaten kämen ja über Interface 1, also Endpoint 2. Damit werden die Daten von den einfachen Pins in keiner Weise berührt. Die Daten, die von einer anderen Funktion, z.B. IIC zurück kämen würden sich dann zwischen die Drehgeberdaten packen. Da aber ReportIDs drin sind kann man die ja auseinandersortieren. man muß sich nur darüber im Klaren sein, dass IIC gleichzeitig zum Drehgeber dazu führen kann, dass der Drehgeber Impulse verpasst.
wayoda
Posts: 362
Joined: Fri Dec 19, 2003 12:00 pm
Location: Wuppertal/Germany

Post by wayoda »

Guido Körber wrote:Also würde ich so vorgehen, dass erst mal bei einem Richtungswechsel versucht wird einen Report zu senden, wenn das nicht geht wird halt der Zähler in die andere Richtung gezählt bis mal wieder Zeit zum Senden eines Reports ist.
Ein Richtungswechsel selbst wäre noch kein Grund einen neuen Report zu generieren. 7 Stufen rauf und dann wieder 7 runter enthält zwar einen Richtungswechsel, aber die relative Änderung der Position ist 0 und damit für eine Applikation vernachlässigbar (oder besser : der Programmierer sollte sich dieser Möglichkeit bewußt sein).
Guido Körber wrote:Was die Auslastung der Reports angeht....
...man muß sich nur darüber im Klaren sein, dass IIC gleichzeitig zum Drehgeber dazu führen kann, dass der Drehgeber Impulse verpasst.
Das geht leider gar nicht. Im Rahmen der Abtastrate an den IO-Pins (im Datenblatt mit 1 ms angegeben), muß die Drehgeberfunktion jeden Impuls zuverlässig melden! Wenn auch nur eine einzige relative Positionsänderung verloren geht, ist die Bestimmung der absoluten Position in der Applikation nicht mehr möglich. (Das geht vielleicht noch wenn man den Drehgeber als Poti-Ersatz für einen User einsetzt, aber die angesprochenen Verwendung als Positionsgeber würde damit unmöglich.)

Vielleicht könnte man eine dynamische Strategie einsetzen:
Falls gerade keine Daten von anderen Funktionen zu übertragen sind, wird der Zählerstand des Drehgebers sofort geliefert.
Ansonsten wird garantiert, das die Daten des Drehgebers auf jeden Fall nach spätestens 120 Millisekunden übertragen werden. (Damit kein Überlauf im signed char wegen der Chip-internen Abtastrate von 1kHz auftreten kann.)

Lieber wäre mir allerdings ein festgelegter Zeitrahmen von z.B. 16 Millisekunden, also also jeder zweite Report gehört dem Drehgeber (wenn er ihn braucht), womit ich eine feste Abtastrate von 62,5 Hz erhalte. Gleichzeitig garantiert dies eine minimale Bandbreite auf dem USB-Bus von 50% für alle anderen Funktionen.

Eberhard
Post Reply