CodeMercs Forum

Das ist dann doch schon was sehr langsam und 200ms sollte eigentlich funktionieren. Evtl. müsste man diese Fehler abfangen und den Lesevorgang einfach erneut durchführen. So handhabe ich das in C/C++ Programmen immer.

Der Timeout ist global für in der iowkit.dll und muss nur einmal gesetzt werden. Sprich einmal nach dem Open() setzten und dann einfach vergessen.

Wie schnell wird denn die Loop durchlaufen? Evtl. dort mal einen Timer/Sleep oder wie man das in LabView nennt einbauen und schauen ob das damit ...

Der Iow56 hat beim I2C nur zwei Errorbits: ACK (0x80) und Arb Loss (0x40), steht im Datenblatt zum 56er.

Der Fehler
IOWarrior_Special_Rawread.vi:1200001: IOWarrior RawRead error: Not 64 bytes: 0
sieht eher danach aus, als ob ein Lesebefehl nicht ausgeführt werden konnte.
Das passiert in der ...

Trotzdem würde ich die Vi mal mit der letzten Lib neu bauen, nicht das noch andere Stolpersteine drin sind.

Hmm komisch, bei dem was ich angehangen habe sind beider Arrays 64Byte groß.

Was man schauen kann ist, ob der Block "Enlarge Report" beim IOW56 den Report richtig aufbläht.
Dazu in der VI (nicht die Lib) doppelkick auf den "SprecialRawRead" Block, dort dann wenn das Fenster auf geht ins ...

Zur Erklärung: Die LabView Lib wurde/wird uns von einem Kunden bereitgestellt, der diese in seiner Freizeit erstellt hatte. Darauf bauen
die Beispiele und die Lib auf. Wir selber können nur bedingt Support für LabView leisten, der über einfache VIs hinaus geht.

Das, was im auf der Webseite bei den ...

Nein das ist eigentlich die aktuelle Lib und Beispiele. Wir haben nicht so viele LabView Anfragen, von daher kommt da selten was neues.
Ich schau am Montag mal ob ich ein ähnliches Verhalten bei der VI, die ich oben angehangen habe bekomme.

Klingt danach, dass er die Reportgröße des IOW24/40 nutzt und nicht die des IOW56.
Ist die "IOWarriorV150.llb" denn auf dem aktuellen Stand? Ich glaube mich zu erinnern, dass das nach einem Bug in einer alten
Version klingt.

So ich hab mal eine VI erstellt. Diese nutzt nur die RAW Write/Read Funktionen und müsste 16 Byte ab Start Register/Adresse 00 00 auslesen.
Die VI ist ungetestet, da ich den EEPROM nicht habe und nichts vergleichbares.

An sich sollte das eigentlich funktionieren, auch wenn die Lib von LabView nicht auf dem neusten Stand ist (aber das ist für den IOW56 egal)
Wir haben die LabView Lib geändert und die ganzen Blöcke für I2C entfernt, weil die nicht kompatibel sind mit den neuen IO-Warriorn. V

Naja es ist wie beim ...

Wie Guido schon geschrieben hat baut Simple-I2C den Report selber zusammen mit Startbit, Stopbit und I2C-Geräteadresse.
Auch die Leseadresse (also die I2C-Geräteadresse mit Read-Bit) baut sich das Tool selber.

Wenn also auf/ab die Speicherzelle 0x0000 (16 bit bei dem Eeporm) geschrieben werden soll ...

Hab ich ganz übersehen, die IO-Funktion möchte beim IOW28 keine 64 sondern nur 5 Byte haben.
Wenn da mehr drin stehen, dann wird der Befehl verworfen.

Das müsste so aussehen (hab den Arraynamen geändert):


if (Data[2] / 3 >= 60)
{
IOPorts[0] = 0x00; //Report-ID
IOPorts[1] = 0xFF; //IO-Port 0.0 ...

Am besten einen eigenstänigen Array für die IO-Funktion nutzen, also nicht Data[0] sonder z.B. WriteData[0].
Weil in Data steht das drin, was über IowKitRead() gelesen wurde (reportID von ADC, die Bytes, etc) und es macht ja keinen
Sinn diese "Zufallswerte" in die IO-Ports zu schreiben.


Ansonsten ...

Die Variablen stehen im Funktionsaufruf als Parameter und werden beim Aufruf der Funktion mit übergeben. Die Funktion wird ja im Code aufgerufen und da wird das dann eingetragen/übergeben. Und was da eingetragen wird ist das, was im Datenblatt angegeben ist, bzw. welches Setup man haben möchte ...

Die numpipes sind dafür da, um auf die unterschiedlichen Interfaces des IOW zugreifen zu können.
Der IO-Warrior28 hat insgesamt 4 Pipes die für unterschiedliche Funktionen zuständig sind:

0 -> IO-Ports
1 -> Special Modes (LCD, LED-Matrix, etc.)
2 -> I2C
3 -> ADC


Beispiel ADC:
Ist der ADC ...