My questions to ACCES:
- is it possible to control each I/O pin separately through your API software, rather than in groups of 8 or all at once?
- I need to read pulses from several incremental rotary encoders mounted to motors, at 1.25 kHz. Is this possible with this I/O card?
----------------------------------------
Their answer:
The USB-DIO-48, and in fact the entire USB-DIO line, supports read and write by bit, byte, and "all."
However, the USB bus is a very real bottleneck, and care should be taken to limit the number of USB transactions that occur in your program. Using the DIO_Read1 or DIO_Write1 API functions consumes as much USB bandwidth as using the DIO_ReadAll and DIO_WriteAll functions, but reads and controls 1/48th the number of bits.
That is, although the throughput of the board is around 4000 transactions per second in Windows XP, you can either get 4000 bits per second, or 4000 bytes per second, or 24000 bytes per second (on the DIO-48. Up to 48000 bytes per second on the USB-DIO-96.)
So, although it does support it, if you're aiming at speed we don't recommend it.
Next, the API provided includes an infrastructure associated with plug-and-play detection of multiple cards of arbitrary types. If you only intend on having a single device of a known type installed in your system (made by ACCES, that is,) then you should pay careful attention to the discussion of diOnly on page three of the document. Using diOnly will eliminate the need for the PnP infrastructure, which can reduce your code to as little as three lines (DIO_Configure, DIO_ReadAll, and DIO_WriteAll.)
Regarding the encoders: maybe. The unit supports throughputs in excess of what Windows XP will allow, which limits the device to about 4000 transactions per second. However, this number of transactions per second is a-periodic and unscheduled. The system can steal control from your application on a whim, causing your timing to go haywire.
If you are able to write your code in a "driver" you can almost certainly schedule a 2.51kHz sample rate (kinda nyquist on your 1.25kHz signals) and read the encoders successfully. From "Userland" code -- normal applications -- I don't think it will be reliable unless you take extreme measures (no other programs running, kill most processes, etc.)
However, the device uses an onboard microcontroller based on the 8051, this microcontroller contains firmware written in "C", in the Keil development tools. The firmware source code is available at no cost, and you could add the encoder reading at that level then simply report the count values up to the host computer, instead of the bit patterns.