Reaktionszeit / Signallaufzeit

horchi · Post by **horchi** » Sun Nov 26, 2006 6:09 pm

Hallo,

ich bin neu im Forum und habe auch gleich eine Frage, was sonst ;)

Ich möchte eine kleine (Zeit) Messstecke mit Lichtschranken aufbauen, nun überlege ich mir, ob ich diese über den IO-Warrior an den USB-Port anbinde. Hierbei stellt sich die Frage, welche 'Auflösung' realisierbar ist. Wenn ich die anderen Beiträge richtig verstanden habe ist das zyklische Abfragen der einzige Weg an die Einganssignale zu kommen. Eine Benachrichtigung via Interrupt scheint es nicht zu geben? Die neue API 2.0 wird (wie ich es verstehe) hierfür Callbacks bereitstellen, welche aber wiederum von einem 'pollenden' Lese-Thread aufgerufen werden.
Mir würde eine Abfrage alle 10ms genügen (bessere wäre 1ms ;)), stellt sich noch die Frage wie die (mittlere) Laufzeit des Signals vom I/O PIN bis zum abfragbaren Wert im Programm ist (habe keine diesbezüglichen Kentnisse des USB Protokolls, ...).
Ich würde das ganze unter Linux realisieren wollen.
Genug der Fragen, ich hoffe ich habe nicht allzuviel beim suchen im Forum übersehen.

BTW: Wie ist der Stand zur neuen API (Linux)

Grüße und schon mal vielen Dank
horchi

wayoda · Post by **wayoda** » Mon Nov 27, 2006 12:15 pm

Hallo horchi,

Hierbei stellt sich die Frage, welche 'Auflösung' realisierbar ist. Wenn ich die anderen Beiträge richtig verstanden habe ist das zyklische Abfragen der einzige Weg an die Einganssignale zu kommen.

Das ist richtig. Auf der Ebene der Betriebssysteme Windows und Linux (bei MacOs weiß ich es nicht) ist ein IOWarrior wie eine Datei anzusehen, bei der neue Daten immer am Ende angefügt werden. Es gibt keine automatische Benachrichtigung für neue Daten, dass muss man selbst implementieren, indem man solange Daten einliest bis keine mehr vorhanden sind. Dann pollt man den IOWarrior periodisch und kann für neue Daten den Zeitpunkt des Eintreffens speichern. Die maximale Auflösung wäre 8ms für Iow24/Iow40 und 1 ms für den Iow56.
Alle Zeiten die hierbei ermittelt werden sind zu betrachten als : Irgendwann in den letzten 8ms (bei Iow24/40) ist was an den IO-Pins passiert.

stellt sich noch die Frage wie die (mittlere) Laufzeit des Signals vom I/O PIN bis zum abfragbaren Wert im Programm ist (habe keine diesbezüglichen Kentnisse des USB Protokolls, ...).

Diese Laufzeiten kann man bei entsprechendem Aufbau der Meßstrecke vernachlässigen. (Man hat zwei Lichtschranken ein für den Start der Messung eine für das Ende der Messung). Bei den Lichtschranken ist allerdings zu beachten, das sie ein Signal erzeugen müssen, das länger als 8ms (Iow24) ansteht. Sonst kann der IOWarrior dieses Signal u.U. nicht erkennen.

Wenn das ganze unter Linux implementiert werden soll, würde ich vielleicht auf die IowKit-Lib verzichten und direkt mit den vom Kernel-Modul bereit gestellten Funktionen arbeiten, die im IOWarrior-HowTo beschrieben sind.

Eberhard

Guido Körber · Post by **Guido Körber** » Mon Nov 27, 2006 12:25 pm

Die Latenzzeit der Signale ergibt sich daraus, dass der IO-Warrior ein pla pro Millisekunde die Eingänge liest und der Host bei IOW40/24 aqlle 8ms und bei IOW56 alle 1ms nach Daten fragt. Ergibt also eine Latenz von 9 bzw. 2 ms. Dazu kommt dann noch mögliche Verzögerung durch das System.

horchi · Post by **horchi** » Mon Nov 27, 2006 12:54 pm

Hi Eberhard,

danke für die genauen Daten!

Dann pollt man den IOWarrior periodisch und kann für neue Daten den Zeitpunkt des Eintreffens speichern. Die maximale Auflösung wäre 8ms für Iow24/Iow40 und 1 ms für den Iow56.

Verständnissfrage, wenn sich in einem Pollzyklus an den Pins mehrmals etwas ändert stehen entsprechend viele Daten zum abholen an? Der Warrior sendet also den Zustand der Pins immer bei Änderung und nicht einfach zyklisch?
Nochmals sorry der vielen dummen Fragen ich bin ganz neu in diesem Thema.

Diese Laufzeiten kann man bei entsprechendem Aufbau der Meßstrecke vernachlässigen. (Man hat zwei Lichtschranken ein für den Start der Messung eine für das Ende der Messung). Bei den Lichtschranken ist allerdings zu beachten, das sie ein Signal erzeugen müssen, das länger als 8ms (Iow24) ansteht. Sonst kann der IOWarrior dieses Signal u.U. nicht erkennen.

ok, sollte kein Problem sein da habe ich schon ein Monoflop am Ausgang.

Dann werde ich mir mal den Chip bestellen, eine externe Beschaltung ist ja fast nicht nötig, sieht alles sehr entspannt aus.

Grüße Jörg

horchi · Post by **horchi** » Mon Nov 27, 2006 12:58 pm

Hi Guido,

das habe ich erst nach meinem letzten Post gelesen.
Wenn der Host die Anfragen macht könnte ich diesen Zyklus doch im Kernel Modul (oder was ist mit Host gemeint) auch für den IOW24 aug 1ms ändern?

Danke
Jörg

wayoda · Post by **wayoda** » Mon Nov 27, 2006 2:00 pm

horchi wrote:Verständnissfrage, wenn sich in einem Pollzyklus an den Pins mehrmals etwas ändert stehen entsprechend viele Daten zum abholen an? Der Warrior sendet also den Zustand der Pins immer bei Änderung und nicht einfach zyklisch?

Genau so ist es, neue Daten werden nur dann erzeugt wenn sich an den Pins etwas geändert hat.

Wenn der Host die Anfragen macht könnte ich diesen Zyklus doch im Kernel Modul (oder was ist mit Host gemeint) auch für den IOW24 auf 1ms ändern?

Nein, das geht nicht. Die Datenraten sind von der Hardware bestimmt. Wenn es 1 ms sein soll, muss man den Iow56 verwenden.

Eberhard

horchi · Post by **horchi** » Mon Nov 27, 2006 3:03 pm

Ok, ich glaube nun habe auch ich es verstanden:

Zusammenfassung des Ablaufs (ausgehend vom IOW24):

- für jede Änderung an den Pins (Ändeung > 1 ms) bekomme ich Daten
- diese Daten werden alle 8ms seitens des Kernel-Modul vom Warrior abgeholt/abgefragt
- ändert sich also 3 x in den 8ms etwas bekomme ich auch alle 3 Änderungen mit (nur halt bis zu 9ms verzögert)!

Dann habe ich auch schon eine Idee wie ich die Auflösung für meine Anwendung verbessere. Ich verwende einen 8bit Binärzähler an eben 8 Eingangspins, zähle damit im 1ms Takt (läuft halt nach 256 Zyklen immer über). Wenn ich nun Abfrage bekomme ich auch diesen Wert und kann so mit der Systemzeit auf den PC syncronisieren. Dan genügt es auch wenn ich z.B alle 100ms abfrage. Bei meiner Anwendung kommt es mehr auf die Auflösung Messung an, nicht ob ich diese etwas verzögert im Programm mitbekomme. So spare ich mir einen eigenen µController.

Grüße
Jörg

Post by **Admin** » Mon Nov 27, 2006 3:58 pm

horchi wrote:- ändert sich also 3 x in den 8ms etwas bekomme ich auch alle 3 Änderungen mit (nur halt bis zu 9ms verzögert)!

Wo kommt denn diese Idee her?

Der IO-Warrior kann nicht beliebig viele Events zwischenspeichern, es gibt nur den Sendepuffer und den Datenpuffer. Ist der Sendepuffer nach einer Änderung noch nicht abgeholt worden, so wird bei jeder weiteren Änderung der Datenpuffer überschrieben. Also maximal zwei Ereignisse innerhalb einer Abfragephase können erkannt werden.

horchi wrote:Dann habe ich auch schon eine Idee wie ich die Auflösung für meine Anwendung verbessere. Ich verwende einen 8bit Binärzähler an eben 8 Eingangspins, zähle damit im 1ms Takt (läuft halt nach 256 Zyklen immer über). Wenn ich nun Abfrage bekomme ich auch diesen Wert und kann so mit der Systemzeit auf den PC syncronisieren. Dan genügt es auch wenn ich z.B alle 100ms abfrage. Bei meiner Anwendung kommt es mehr auf die Auflösung Messung an, nicht ob ich diese etwas verzögert im Programm mitbekomme. So spare ich mir einen eigenen µController.

Viel Spaß, der Zähler wird eine Unmenge von Events erzeugen...

Sinnvoller ist es einen Zähler mit Latch zu nehmen und das Latch mit dem Ereignis zu tirggern.

horchi · Post by **horchi** » Mon Nov 27, 2006 4:39 pm

Wo kommt denn diese Idee her?

Der IO-Warrior kann nicht beliebig viele Events zwischenspeichern, es gibt nur den Sendepuffer und den Datenpuffer. Ist der Sendepuffer nach einer Änderung noch nicht abgeholt worden, so wird bei jeder weiteren Änderung der Datenpuffer überschrieben. Also maximal zwei Ereignisse innerhalb einer Abfragephase können erkannt werden.

Das hatte ich so verstanden, ist für meine Anwendung aber auch kein Problem. Da gibt es nur alle paar Sekunden eine Änderung (Messung) nur die soll eben recht genau sein.

Sinnvoller ist es einen Zähler mit Latch zu nehmen und das Latch mit dem Ereignis zu tirggern.

so war das auch gemeint, jeden Zählerstand wollte ich nicht übertragen ;)

Jörg

wayoda · Post by **wayoda** » Mon Nov 27, 2006 4:43 pm

horchi wrote:Ok, ich glaube nun habe auch ich es verstanden:

Leider nicht :-(.

Das muss so aussehen:

Zusammenfassung des Ablaufs (ausgehend vom IOW24):

- für jede Änderung an den Pins, die für eine Zeitspanne von mehr als 8 ms ansteht, bekomme ich genau ein Datum.

- Daten werden alle 8ms seitens des Kernel-Modul vom Warrior abgeholt/abgefragt und in einem Puffer gespeichert, der maximal 16 Daten enthält.

- ändert sich also 3 x in den 8ms etwas bekomme ich auch alle 3 Änderungen mit ? Nein nur die letzte!

Eberhard

horchi · Post by **horchi** » Mon Nov 27, 2006 4:53 pm

... allerdings zu beachten, das sie ein Signal erzeugen müssen, das länger als 8ms (Iow24) ansteht. Sonst kann der IOWarrior dieses Signal u.U. nicht erkennen.

das hatte ich überlesen.
Ich glaube nun habe ich euch wirklich genug ausgefragt ;)

Der IOWarrior ist bereits bestellt, wenn ich's fertig habe berichte ich ob (wie) es läuft.

Danke nochmals,
Jörg

horchi · Post by **horchi** » Mon Dec 04, 2006 9:14 pm

Hi,

wollte nur noch mal kurz berichen, der IC (IOWarrior24) ist am Wochenende angekommen. Nach dem Zusammenbau der Schaltung und Anschluss an den USB Port wurde er sofort erkannt und auch das zuvor installierte Modul automatisch geladen.
Ein kleine Proggi in C++ welches schon alles macht was ich brauche (nur bislang noch ohne GUI) ist fertig und funzt. An der GUI bin ich nun dran.

Die einzige wirklich nerfige Hürde war das übersetzen des iowkit wegen cmake. Auch werde ich (was ich ohnehinn vor hatte) noch vom verwenden der iokit Lib Abstand nehmen, mir gefallen u.A. die an die Windows API angelehnten Datentypen nicht besonders.

Alles in allem tolles Produkt und super leicht anzuwenden!

horchi

horchi · Post by **horchi** » Sat Jan 27, 2007 10:09 am

Hallo,

um den Faden doch nochmals aufzunehmen, ...

Wie sicher ist der Ausgabezyklus von 8ms seitens des Betriebssystems (Linux)? Ist es möglich, dass hier bei höherer CPU Last deutliche Verzögerungen auftreten oder ist diese Abfrage an einen nicht maskierbaren Interrupt oder ähnliches gebunden?

Danke und Grüße
horchi

Robert Marquardt · Post by **Robert Marquardt** » Sat Jan 27, 2007 3:33 pm

Bei USB darf man sich nicht aufs Timing verlassen. Es kommt bei Linux wie bei Windows durchaus zu Verzoegerungen. Wie lange ist unvorhersehbar. Linux duerfte zwar bessere Werte haben, aber das Prinzip ist das gleiche.

horchi · Post by **horchi** » Sat Jan 27, 2007 3:42 pm

Bei USB darf man sich nicht aufs Timing verlassen. Es kommt bei Linux wie bei Windows durchaus zu Verzoegerungen. Wie lange ist unvorhersehbar. Linux duerfte zwar bessere Werte haben, aber das Prinzip ist das gleiche.

Dann müsste ich um recht genaue Werte zu erhalten eine externe Uhr mitlaufen lassen, selbst eine Genauigkeit von 10ms wäre sonst in Frage gestellt. Dann bleibt mir wohl nur das umsteigen auf einen externen µController, was den Aufwand leider deutlich in die Höhe treibt :( .
Schade, die Schaltung mit dem IO Warrior war so schön einfach.

horchi