Drehinkrementalregler am IO Warrior?
Moderator: Guido Körber
Drehinkrementalregler am IO Warrior?
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
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
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Drehinkrementalregler am IO Warrior?
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?
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?
Drehinkgeber
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
TOGA
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...
Re: Drehinkrementalregler am IO Warrior?
Sehr gute Idee, ich habe meinen Drehgeber schon wieder in Regal zurückgelegt.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.
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.Guido Körber wrote:Irgend welche Vorlieben für so eine Funktion?
Finde ich nicht so eine gute Idee, eine Zählerfunktion kann man ja ganz einfach in Software implementieren.toga wrote: Toll wäre, wenn u.a. gleich ein auf und abwärts zählender Wert per USB weitergegeben werden könnte.
Mit der Anzahl der Impulse und der Richtung lässt sich sicher alles abdecken was man für eine Applikation braucht.
Eberhard
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Drehinkgeber
Momentan ist das in der "man könnte mal" Phase, also noch keine Ankündigung einer neuen Funktion.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
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Also eigentlich sind das zwei phasenverschobene Rechtecksignale. Je nach Drehrichtung hat man 90 oder 270 Grad Phasenverschiebung.toga wrote:Nochmals zu meinen Drehgebern. Diese haben keinen Graycode sondern haben zwei interne Taster die je nach Drehrichtung zeitversetzt schliessen und öffnen.
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.
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Drehinkrementalregler am IO Warrior?
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 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.
Re: Drehinkrementalregler am IO Warrior?
Ja, sehr gute Idee einen ganzen Port zu nutzen.Guido Körber wrote: Ich denke daran an Port 2 ein bis vier Drehgeber zu unterstützen..
Das entspräche doch so etwa meinem Vorschlag.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 verstehe ich leider nicht mehr so ganz? Wären das dann zwei Reports wenn innerhalb von 8 Millisekunden die Drehrichtung gewechselt wird?Guido Körber wrote: Bei Umkehrung der Drehrichtung wird ein Report geschickt um möglichst keine Impulse zu verlieren.
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
-
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
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.
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.
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Nö.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.
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.
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: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.
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.)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.
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