newbie / iow24 - bits lesen / schreiben

[mike1]

Hi,

alles klar, wenn ich das richtig erkannt habe, möchtest Du VB zum programmieren verwenden? Damit bekommst Du die gleichen Probleme wie ich. VB ist dafür nicht geeignet. Wie Du schon festgestellt hast, bleibt Dein Programm "hängen" wenn Du lesend auf Eingänge zugreifst. Das liegt daran, dass im USB - Buffer des PC's keine Daten vorliegen und das Programm wartet bis der IOW Daten sendet. (das tut er übrigens sobald sich ein Signal ändert) Drückst Du z.B. eine Taste "läuft" Dein Programm wieder. Mit VB kommst Du da nicht weiter, da es nicht Multi-Thred fähig ist. (korrigiert mich wenn ich Blödsinn erzähle). Wenn Du schon mit VB nicht klar kommst, brauchst Du mit Delphi oder C++ (diese können das) erst gar nicht anfangen.
Das werden die Herren von CodeMercs nicht gern hören, aber es gibt ähnliche Geräte anderer Hersteller, die wesentlich mehr Softwareunterstützung für ihre Produkte geben. Ich werde mir hier verkneifen, Namen zu nennen. Aber z.B. liefern diese ein OCX zu ihrem Gerät hinzu, über das das Ansprechen der Ports ein Kinderspiel ist, auch Bit und Portweise, dort übernimmt die Maskierung das Steuerelement.
Diese spezielle Teil, das ich meine hat aber auch wesentliche Nachteile. Es ist z.B. eine ganze Ecke langsamer als der IOW und bietet keine Sonderfunktionen.
Da der IOW mehr auf den Bastler als Konsumenten zielt (teure professionelle Lösungen gibt es genug), der nicht unbedingt ein geübter Hochsprachen Programmier ist, denken die Damen und Herren von CodeMercs vielleicht einmal darüber nach, auch etwas mehr Softwareunterstützung anzubieten.
In Deinem Fall, ist die Möglichkeit die MikeD vorgeschlagen hat, vielleicht noch die beste Lösung.

Mike

[Guido Körber]

Also erst mal zielt der IO-Warrior nicht auf Bastler, sondern (wie fast alle unsere Produkte, bis auf JW24RC) auf industrielle Anwender und da spielt VB nicht wirklich eine grosse Rolle.

Die Aussage, dass man den IOW mit VB nicht benutzen könne weil das Multithreading fehlt ist schlicht falsch. Die einfache I/O kann sehr gut mittels iowkitReadImmediate abgefragt werden. Lediglich die Keymatrix-Funktion macht hier Probleme und das wie schon festgestellt wurde schlicht desshalb weil VB unzulänglich ist.

[Robert Marquardt]

Ich arbeite gerade an der Moeglichkeit fuer einen Callback auf beiden Pipes.
Das muss aber fuer Windows mit VB6, C/C++ und Delphi funktionieren sowie fuer Linux. Nicht zu vergessen Java fuer Windows und Linux.

Weiterhin muss auch noch das API kompatibel erweitert werden.
Es muss ja dann ein Lese-Thread auf der Special Mode Pipe laufen was einen deutlichen Eingriff in die innere Funktionsweise der DLL bedeutet.

All diese Themen zu beherrschen ist nicht ganz leicht und ein nicht zu unterschaetzender Aufwand.

[mike1]

Hallo,

ich nehme alles zurück und behaupte das Gegenteil. Erst mal habe ich die Unternehmensstrategie verstanden. Dann ist es ja auch kein Wunder, dass die Bastler, die sich im Forum hier herumtreiben, überfordert sind und das Softwareinterface sehr offen gestaltet ist.
Auch die Sache mit der VB "Leseuntauglichkeit" ist endlich angekommen und ich habe das gerade mal getestet. War mein Fehler und ich nehme zurück, dass es in VB nicht geht.
Mein Fehler lag darin, das ich dachte, die Daten werden durch die ReadImmediate Funktion einmal angefordert und gesendet und dann noch mal, weil die Portpins sich ändern, was ja bei jeder Änderung an einem Portpin zu einem zusätzlichen Datenpaket geführt hätte. Das wiederum hätte irgendwann zwangsläufig zu einem Überlaufen des USB-Puffers geführt. Ich weis zwar nicht warum, aber dem ist nicht so.
Damit kann penpen auch seine Steuerung einfach realiesieren.
Am Besten Du schaust Dir noch mal das Beispiel SimpleIO an und gehst es im Step bei Step mod durch, dann sollte zumindes einiges klar werden.

z.B. ich habe gerade einen Timer in dieses Programm eingefügt und ein Label zum Anzeigen verwendet ( Timer = 20 ms) und

Private Sub Timer1_Timer()
Dim LData As Long
Res = IowKitReadImmediate(iowHandles(0), LData)
Form1.Label3.Caption = LData
End Sub


Ich habe das hier einfach mal in einem Label angezeigt. Du musst die gelesenene Daten natürlich noch ausmaskieren und entsprechend verarbeiten. Ich will Dir ja nun nicht den ganzen Spaß am basteln vermießen.

Gruß
Mike

[wayoda]

Mein Fehler lag darin, das ich dachte, die Daten werden durch die ReadImmediate Funktion einmal angefordert und gesendet und dann noch mal, weil die Portpins sich ändern, was ja bei jeder Änderung an einem Portpin zu einem zusätzlichen Datenpaket geführt hätte. Das wiederum hätte irgendwann zwangsläufig zu einem Überlaufen des USB-Puffers geführt. Ich weis zwar nicht warum, aber dem ist nicht so.

Steht zwar eigentlich auch in der Doku zur Iowkit-Library, aber vielleicht ist es dort ja nicht nicht anschaulich genug beschrieben:

Die iowkit-library führt intern eine Warteschlange der Länge 8 in dem automatisch alle Änderungen an den IO-Pins eingetragen werden.
Falls der IOWarrior neue Daten an den IO-Pins signalisiert werden diese entweder an die Warteschlange angehängt wenn noch Platz ist (Länge<8), oder der Wert an der Spitze der Warteschlange (sozusagen der älteste) wird verworfen und das neue Datum wird am Ende angehängt. Bis hierher passiert alles, wie gesagt, automatisch.

Nun zu ReadImmediate:
Die Funktion ReadImmediate versucht den Wert an der Spitze der Warteschlange zu lesen. Ist die Warteschlange leer, liefert ReadImmediate den Wert 0 zurück, oder anders ausgedrückt:
seit dem letzten Aufruf von ReadImmediate ist an den IO-Pins nichts mehr passiert.
Die im 2. Parameter der Funktion übergebene Referenz auf einen Long enthält jedoch bei der Rückkehr auch noch den letzten bisher gelesenen Zustand der IO-Pins.

Ist die Warteschlange nicht leer, liefert ReadImmediate den Wert 1 zurück, und die im 2. Parameter der Funktion übergebene Referenz auf einen Long enthält den Wert an der Spitze der Warteschlange.
Man kann aber nun nicht davon ausgehen, daß dieser Wert dem aktuellen Zustand an den IO-Pins entspricht!
Der befindet sich eben immer am Ende der Warteschlange!
Ist man auf den aktuellen Wert angewiesen, muß man also ReadImmediate so oft aufrufen bis die Funktion 0 zurückliefert. Erst dann entspricht die Referenz auf den Long dem aktuellen Wert.
Na, eigentlich schon einen Aufruf früher, aber da weiß man ja noch nicht, daß die Warteschlange nun leer ist.
Und dann gibt's natürlich noch eine Ausnahme:
Hat sich seit dem Programmstart noch gar nichts an den IO-Pins getan, ist die Warteschlange natürlich auch leer. In diesem Fall enthält der 2. Parameter bei Rückkehr die Konstante 0xFFFFFFFF.

z.B. ich habe gerade einen Timer in dieses Programm eingefügt und ein Label zum Anzeigen verwendet ( Timer = 20 ms) und ....

Timer ist gut, nur muß man darauf achten das man den Timer passend zu dem zu erwarteten Datenaufkommen einstellt.
Eine Untergrenze kann man jedoch bei 7 ms setzen. Ein IOWarrior kann maximal alle 8 ms einen neuen Zustand liefern. Mit 7ms ist man also sicher keinen Wert zu verpassen.
Bzgl. der Performance ist dies auch unkritisch, da der Aufruf von ReadImmediate nur aus dem internen Puffer liest, es gehen also keine Daten über den USB-Bus.

Gruß
Eberhard

[penpen]

Herzlichen Dank - klingt sehr interessant, ist aber für studenten als unbezahlbar einzustufen - wir müssen alles selbst bezahlen und sind schon weit jenseits der geplaten kosten (codec mercenaries ist uns hier sehr entgegen gekommen, wofür ich mich hier nochmals bedanken möchte)

fürchte da muss ich schon selbst was machen, ich versuche es mal kürzest darzustellen:

die steuerung der schrittmotore über pc soll können:

erst muss die kamera automatisch in mitte-position gebracht werden über eingangsignale am iow24, dannach:

1 händisch motor bewegen - also solange ich taste drücke, bewegt sich der motor und ein zähler zählt die schritte des motors mit

2. wenn taste losgelassen, steht der motor, das programm weiß wieviele schritte der motor gemacht hat - Damit wird festgelegt wie weit er sich horizontal bewegen muss, damit 1 foto aufgenommen werden kann

3. selbe prozedur mit anderen motor für vertikale bewegung

4. programm errechnet nun wieviele fotos nötig sind um 360° aufnahmen zu machen (zb 15 bilder um einmal rundherum aufzunehmen)

5 dann wird die digitalkamera: gedreht - gestoppt - ausgelöst -- gedreht - gestoppt -- augelöst ...... bis alle fotos gemacht wurden, dann vertikal geschwenkt und wieder wird eine reihe rundumbilder geschossen


6 im hintergrund läuft eine überwachung mit, sollte die kamera eine stellung zu weit links oder rechts erreichen - was sie nicht darf, muss einfach mittendrin abgebrochen werden

das wars in kürze (mir klar dass es so schwer zu verstehen ist - es geht mir nur darum dass eigentlich nur io-signale rausgesandt werden, ein zeitglied, das wenige sekunden abzählen kann wird benötigt, ein zähler und eine überwachung ob nicht der iow24 ein eingangssignal melder, sonst nichts

[mike1]

Hi,
@ wayoda: Danke für die zusätzlichen Infos. Ich war urspünglich von einer anderen Seite an das Problem gegangen und da ging es mit der ReadImmediate Funktion nicht. Siehe 8x8 Tastatur.

@penpen: Ich habe Dein Problem schon verstanden und Dein Problem ist mit VB ohne weitere Software einfach lösbar. Ich hatte ursprünglich Probleme mit der ReadImmediate Funktion, deren Funktion ich nicht richtig verstanden hatte. Aus jetztiger sicht würde ich höchstens 4-8 h für das Stück Software ansetzen. Schau Dir einfach noch mal das Beispiel mir dem Simple IO an.
Wenn Du das Stück Programm mit dem Timer statt dem Read- Button einfügst kannst Du die Signale lesen ohne das das Programm "hängen" bleibt.
Viel Spaß noch .. schließlich ist es ja Deine studienarbeit.

Gruß
Mike

[penpen]

danke - studienarbeit impliziert hier falsches - wir studieren verkaufsmanagement! = verkäufer / steyr ist ein reiner management-standort, hat nix, gar nix mit programmieren, elektronik, mechanik, software zu tun - schrieb ja schon dass es hier gar kein labor gibt (weder elektronisch, mechanisch noch sonst irgend eins) - das ist mehr eine art einbildung vom studiengangsleiter, etwas technik steht im ausbildungsplan drin und damit auch eine praktische seite da ist, können wir weit jenseits vom inhalt plötzich so was machen - würde mich sehr interessieren wenn ich zeit hätte - so kann ich mal, grob geschätzt, 50-100 stunden für eine sche.... software rechnen, zu schreiben an tagen an denen ich sowieso 18 stunden schwer beschäftigt bin, wie das gehen soll weiß ich nicht - wir haben da noch 4 andere projekte, die auch was mit unserem studium zu tun haben

tut mir leid, dieses off-topic, aber der frust bahnt sich hier seinen weg - werde mich in zukunft wieder auf thema beschränken

[penpen]

und noch etwas: es ist uns keineswegs verboten teile zuzukaufen, hilfe anzunehmen etc. wie wir das projekt handhaben ist einzig und alleine unser bier - es gibt auch 2 projekte, die mit firmen zusammen stattfinden, diese studenten bekommen sowieso enorm viele leistungen von diesen firmen direkt geliefert (bezahlung der spesen sowieso), wir habe die hardware erstellt, das gehäuse konstruiert, idee und konzept entwickelt - selbst wenn wir die software nicht selber machen - was wir sowieso müssen (genauer ich) - würde keiner was dagegen haben; ziel ist: die verbindung von etwas elektronik mit etwas mechanik - haben wir: elektronische ansteuerung, mechanische teile wie gehäuse, wellen usw... software ist mehr ein notwendiges übel, kein bestandteil der projektanforderung

[mike1]

Hallo,

dass kenne ich, habe mich wärend meines Studiums oft gefragt, warum ein E-Techniker statische Berechnungen an Brücken vornehmen können muss bzw. Wochenlang im CAD Labor gesessen und Motoren gezeichnet.

In einem gewissen Rahmen (solange es nicht mehr als die 4-8h werden) würde ich Dir meine Hilfe anbieten. Es gibt nur zwei Probleme. Ich habe nur den IOW40. Könnte also wenn ich für Dich was schreibe das nicht mit dem IOW24 testen und dann brauche ich wesentlich detailiertere Angaben zu dem Aufbau der Schaltung, Ports und der Programmiersprache. Ich kann nur mit VB6 dienen. ...
Alles andere dann per Mail. Wir wollen ja hier das Forum nicht zuspamen.

Gruß
Mike

[methusalem]

Hallo zusammen,
diesmal keine Frage, sondern eher ein DANKESCHÖN!

Steht zwar eigentlich auch in der Doku zur Iowkit-Library, aber vielleicht ist es dort ja nicht nicht anschaulich genug beschrieben:

Die iowkit-library führt intern eine Warteschlange der Länge 8 in dem automatisch alle Änderungen an den IO-Pins eingetragen werden.
Falls der IOWarrior neue Daten an den IO-Pins signalisiert werden diese entweder an die Warteschlange angehängt wenn noch Platz ist (Länge<8), oder der Wert an der Spitze der Warteschlange (sozusagen der älteste) wird verworfen und das neue Datum wird am Ende angehängt. Bis hierher passiert alles, wie gesagt, automatisch.

Nun zu ReadImmediate:
Die Funktion ReadImmediate versucht den Wert an der Spitze der Warteschlange zu lesen. Ist die Warteschlange leer, liefert ReadImmediate den Wert 0 zurück, oder anders ausgedrückt:
seit dem letzten Aufruf von ReadImmediate ist an den IO-Pins nichts mehr passiert.
Die im 2. Parameter der Funktion übergebene Referenz auf einen Long enthält jedoch bei der Rückkehr auch noch den letzten bisher gelesenen Zustand der IO-Pins.

Ist die Warteschlange nicht leer, liefert ReadImmediate den Wert 1 zurück, und die im 2. Parameter der Funktion übergebene Referenz auf einen Long enthält den Wert an der Spitze der Warteschlange.
Man kann aber nun nicht davon ausgehen, daß dieser Wert dem aktuellen Zustand an den IO-Pins entspricht!
Der befindet sich eben immer am Ende der Warteschlange!
Ist man auf den aktuellen Wert angewiesen, muß man also ReadImmediate so oft aufrufen bis die Funktion 0 zurückliefert. Erst dann entspricht die Referenz auf den Long dem aktuellen Wert.
Na, eigentlich schon einen Aufruf früher, aber da weiß man ja noch nicht, daß die Warteschlange nun leer ist.
Und dann gibt's natürlich noch eine Ausnahme:
Hat sich seit dem Programmstart noch gar nichts an den IO-Pins getan, ist die Warteschlange natürlich auch leer. In diesem Fall enthält der 2. Parameter bei Rückkehr die Konstante 0xFFFFFFFF.

Nach längerem Suchen bin ich auf diese Erklärung gestoßen! Und nu is mir einiges klarer. Wenn ihr also mal Eure FAQ erweitert, dann nehmt diese Erklärung doch bitte da mit auf. Die ist sehr hilfreich. In so klaren Worten hab ich das in der Doku nicht gefunden ... oder hab ich die falsche PDF? Wenn das so drinn stehen sollte: Asche auf mein Haupt! Und sagt mir die Seite im PDF.

[wayoda]

In so klaren Worten hab ich das in der Doku nicht gefunden ... oder hab ich die falsche PDF? Wenn das so drinn stehen sollte: Asche auf mein Haupt! Und sagt mir die Seite im PDF.

Ist zwar in Englisch, aber bei IowKitReadImmediate (Seite14) steht:

Internally 8 reports are buffered to allow using a timer to call
IowKitReadImmediate() without losing fast bursts of reports.
IowKitRead() also uses the buffered reports so do not mix calls to
IowKitRead() and IowKitReadImmediate() without careful consideration.


Jetzt die einzige Falschinformation auf der Seite:
This is not true for the Linux version yet.
Falsch, weil Linux schon immer einen internen Puffer von 16 Werten geführt hat.
Eberhard

[methusalem]

Ist zwar in Englisch, aber bei IowKitReadImmediate (Seite14) steht:

Internally 8 reports are buffered to allow using a timer to call
IowKitReadImmediate() without losing fast bursts of reports.
IowKitRead() also uses the buffered reports so do not mix calls to
IowKitRead() and IowKitReadImmediate() without careful consideration.


Jetzt die einzige Falschinformation auf der Seite:
This is not true for the Linux version yet.
Falsch, weil Linux schon immer einen internen Puffer von 16 Werten geführt hat.

***rotwerd***
Sorry, ... ich sollte vielleicht mein programmieren auf das Wochenede verlegen. Ausgeschlafen und fit geht das besser! Ich hab die Doku echt einige male durchgelesen. Aber irgendwie hab ich auf diese Beschreibung nicht zugeschlagen ... nochmals Danke!

Jetzt noch eine kurze Frage zu IowKitRead(): Ich verstehe die Doku so, das beide Funktionen auf diesen "internen Puffer" zugreifen. Ist das richtig? Solange also dort etwas drinn steht, gehts bei beiden Funktionen weiter. Sollte dieser Puffer leer sein, wartet IowKitRead() solange, bis wieder etwas passiert (blokiert also den Programmablauf). Im Gegensatz dazu meldet IowKitReadImmediate() FALSE zurück und in der Referenz steht der letzte Wert.
Dieser "interne Puffer" ist aber in der Lib realisiert und nicht im Controller selber, oder?

[Robert Marquardt]

Ja der Queue (Warteschlange) ist in der DLL. Es ist naemlich unter Windows sehr schwer nicht blockierend zu lesen. Es wird extra ein Thread gestartet, der permanent liest und den Puffer fuellt.

Das IowKit 2.0 API hat uebrigens Lesethreads auf beiden Pipes und eine Queue von 128 statt 8 Reports.

Letztlich ist diese Queue nur dazu da das IowKitReadImmediate implementieren zu koennen. und damit zu erlauben das man eine Timer zum Lesen verwenden kann. Es kann ja vorkommen das in einem Timertick mehrere Reports eintreffen und man moechte natuerlich diese Aenderungen alle mitbekommen.

Es ist daher eine gute Strategie im Timertick solange Reports mit IowkitReadImmediate zu lesen bis keine mehr da sind. Sollten naemlich die Reports schneller hereinkommen als einer pro Timertick, dann laeuft die Queue zu und verwirft schliesslich Reports. Mit einer Queuelaenge von 8 hat man allerdings mindestens 80 Millisekunden Zeit, da der IOWarrior nicht mehr als einen Report pro 8 Millisekunden senden darf. Das ist fuer low-speed HID Geraete so festgesetzt.

[mike1]

Ein IOW hat es in der Alpenrepublik in die Zeitung geschafft.

http://freenet-homepage.de/Lippmann/Nac ... 8.2006.jpg