CodeMercs Forum

Die IOW24, 40 und 56 sind glaube ich schon länger in ProfiLab drin. Die sind aber auch ein paar Tage älter ;) Was die Eingänge / Funktionen betrifft, der IOW kann das alles. Allerdings muss man für den ein Programm schreiben, was die Daten ausliest und damit dann Dinge tut. Der IOW kann nicht wie ei...

Hi, leider kenne ich mich mit Profilab nicht aus. Es kann sein, dass der IOW100 nicht integriert ist. Wir selber haben keinen Kontakt zu Profilab, da müssten Sie sich dort man an den Support wenden. Zu dem IO-Warriorn unter Windows. Die werden als USB und als mehrere HID-Geräte hinzugefügt. Davon me...

Also ich hab mir mal Blender angeschaut und die Shortcuts für "Radius" und "Strength" sind "F" bzw. "Shift + F". Allerdings wird die Stärke dort dann nicht per Mausrad (Z-Achse) sondern über die Maus Links/Rechts (X-Achse) gesteuert. Mit dem KW100 wäre das an ...

Leider kenne ich mich mit Blender und dem Bedienkonzept nicht aus. Wenn es sich um einfache Tastenkombinationen handelt um z.B. die Pinselauswahl zu öffnen oder ander Aktionen auszuführen, dann können das der KW28 und KW100. Mit beiden kann man die 8 Tasten realisieren und die Tasten können mit so z...

Im Goben sollte die API-Funktion "SpinKitReadNonBlocking(HANDLE, DATASTRUCT)" verwendet werden. Die ausgelesenen Daten (Drehgeber und Buttons) stehen dann im DATASTRUCT drin. Ansonsten haben wir ein SDK, wo einige Beispiele enthalten sind: https://codemercs.com/downloads/spinwarrior/spinki...

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 verschwi...

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 Regel, w...

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 g...

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 D...

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 Sim...