IOWarriorWindowsMBS.CancelIO(Pipe as Integer) as boolean

Returns true for success.

Cancel a read or write operation under way on one of the pipes.
This function is seldom used, because you need several threads in your program to be able to call it at all.
Read() blocks the thread so you need another thread for cancelling. Setting the timeouts is an easier way for handling read or write problems.
The function cancels pending read and write operations simultaneously.

IOWarriorWindowsMBS.close

Close all IO-Warriors.
You must call this function when you are done using IO-Warriors in your program.
If multiple IO-Warriors are present all will be closed by this function.

IOWarriorWindowsMBS.DeviceCount as Integer

The function has to be called after Open() to return meaningful results.
Plugging or unplugging IO-Warriors after calling IowKitOpenDevice() is not handled. The number DeviceCount() returns stays the same.

IOWarriorWindowsMBS.GetProductID as Integer

You can compare this with the values from USB40DeviceID, USB56DeviceID and USB24DeviceID.

Return the Product ID of the IO-Warrior device identified by iowHandle.
The Product ID is a 16-bit Word identifying the specific kind of IO-Warrior.
The value is cached in the dynamic library because access to the device needs some msecs.

Some examples using this method:

• /USB/IOWarrior/IO Warrior Windows LEDs

IOWarriorWindowsMBS.GetRevision as Integer

0 on any error.

Some examples using this method:

• /USB/IOWarrior/IO Warrior Windows LEDs

IOWarriorWindowsMBS.Open as boolean

IOWarriorWindowsMBS.Read(pipe as Integer, buffer as memoryblock, bufferSize as Integer) as Integer

Read data from IO-Warrior.
This function reads length bytes from IO-Warrior and returns the number of bytes read if successful.
Note that you must specify the number of the pipe (see IO-Warrior specs) to read from. numPipe ranges from 0 to IOWKIT_MAX_PIPES-1.
Since the IO-Warriors are HID devices, you can only read the data in chunks called reports. Each report is preceded by a ReportID byte. The "IOWarriorDatasheet.pdf" elaborates about that.
The function returns the number of bytes read, so you should always check if it reads the correct number of bytes, you can use GetLastError() to get error details. Keep in mind that data is always returned in report chunks, so reading 5 bytes from the IO-pins of an IO-Warrior 24 would only return 3 bytes of data because the IO-Warrior 24 has a 3 byte report whereas an IO-Warrior 40 has a 5 byte report.
The Special Mode pipe has a report size of 8 bytes for all IO-Warriors.
Linux does not have a ReportID byte of 0 for pipe 0 (I/O pins). To be completely compatible with Windows libiowkit.so adds that ReportID to the data.
As of dynamic library version 1.4 the function correctly reads several reports at once.

ATTENTION!
This function blocks the current thread until something changes on IO-Warrior (i.e. until user presses a button connected to an input pin, or until IIC data arrives), so if you do not want your program to be blocked you should use a separate thread for reading from IO-Warrior. If you do not want a blocking read
use ReadImmediate(). Alternatively you can set the read timeout with SetTimeout() to force Read() to fail when the timeout elapsed.

IOWarriorWindowsMBS.ReadImmediate(byref value as UInt32) as Integer

Return last value read from IO-Warrior pipe 0 (I/O pins).
The function returns TRUE (1) if a new value has arrived otherwise it returns FALSE and places the last value read into value.
The function can only read the I/O pins via pipe 0 so it does not need a numPipe parameter. It also abstracts from the number of I/O pins the device has.

Until the first report has been read the function returns -1 because the I/O pins are initially high.

Internally 8 reports are buffered to allow using a timer to call ReadImmediate() without losing fast bursts of reports. Read() also uses the buffered reports so do not mix calls to Read() and ReadImmediate() without careful consideration.
This is not true for the Linux version yet.
There is no non-blocking read for pipe 1 (Special Mode Functions) because pipe 1 has a command interface where you write a command and then read the answer.

IOWarriorWindowsMBS.ReadNonBlocking(pipe as Integer, buffer as memoryblock, bufferSize as Integer) as Integer

IOWarriorWindowsMBS.SerialNumber as string

Returns an empty string if there is no serial number available.
The serialnumber is an eight byte long string.

IOWarriorWindowsMBS.SetTimeout(timeout as Integer) as boolean

dim w as IOWarriorWindowsMBS // your instance

if w.SetTimeout(1000) then
  MsgBox "OK. Set one second timeout"
else
  MsgBox "Failed."
end if

Default is infinity.

Set read I/O timeout in milliseconds.
It is possible to lose reports with HID devices. Since reading a HID device is a blocking call it is possible to block your application in that case.
SetTimeout() makes Read() fail if it does not read a report in the allotted time.
If Read() times out, you have to restart any pending transaction (for example, IIC write or read transaction) from the beginning.
It is recommended to use 1 second (1000) or bigger timeout values.

Returns true on success.

IOWarriorWindowsMBS.SetWriteTimeout(timeout as Integer) as boolean

Default is infinity.

Set write I/O timeout in milliseconds.
SetWriteTimeout() makes Write() fail if it does not write a report in the
allotted time.
If Write() times out, you have to restart any pending transaction (for example, IIC write transaction) from the beginning.
Failure of Write() is uncommon. Check your hardware if you encounter write errors.
The Linux library does not implement SetWriteTimeout() yet.
It is recommended to use 1 second (1000) or bigger timeout values.

IOWarriorWindowsMBS.Version as string

returns e.g. "IO-Warrior Kit V1.4".

IOWarriorWindowsMBS.Write(pipe as Integer, buffer as memoryblock, bufferSize as Integer) as Integer

Write length bytes of data to pipe numPipe of IO-Warrior. The return value is the number of bytes written. Writing something else than a single report of the correct size and a valid report ID for the pipe fails for Windows. The function allows writing to the I/O pins through pipe 0 and Special Mode functions
through pipe 1. To be completely compatible with the Windows version libiowkit.so expects a ReportID 0 for pipe 0 (I/O pins) even if Linux does not have a ReportID on pipe 0. The ReportID is stripped from the data sent to the device.
Sample write to pipe 0 of an IO-Warrior 40:
Integer value consists of 32 bits, which correspond to the 32 IO-Warrior 40 I/O pins. Each bit has the following meaning:
When a 1 is written to a pin the output driver of that pin is off and the pin is pulled high by an internal resistor. The pin can now be used as an input or an output with high state.
When a 0 is written to a pin the output driver is switched on pulling the pin to ground. The pin is now a output driving low.
For example, writing 0 (all 32 bits are zero) to IO-Warrior sets all pins as outputs driving low (so if you have LEDs connected to them they will be on).
Reading the status of the pins does always return the logic level on the pins, not the value written to the pin drivers.
Writing -1 (value in hex, all 32 bits set) sets all pins as inputs.
Note that if you want to use a pin as an input, you must first set it up as input, in other words, you must write 1 to it. For connected LEDs this means they go off.