I have 2 PCs with integrated USB controllers (VIA chipset) that do not start up my application. The device manager of Win2k recognizes the XEM3001.v2 correctly, but my program does not start up correctly. Other PCs (using Intel USB chips) work fine!
One of the XEM3001.20050215 is not recognized by the 2 VIA-PCs properly (the other XEM3001 are ok). I see a yellow ! in the device manager. The Intel- PCs say it works fine!
Could there be a problem with some - not all! - VIA USB chipsets, that even differ from board to board? I allways use the latest driver version (from 26. Dec 2005). Most of my PCs use USB1.1 as speed is not restrictive for me. I already connected the XEM3001 modules using a powered USB hub (+5V/2A) assuring to have enough power all the time.
Any suggestions?
Are you using FrontPanel 1.3.1? Can you try FrontPanel 1.2.5?
The shift from 1.2.5 to 1.3.x added asynchronous (queued) bulk transfers to dramatically increase transfer speed. It would seem that this caused problems with Win2K machines and USB 1.1 (it’s fine with Win2k / USB 2.0). We are likely going to release a fix which will drop back to NOT using the asynch bulk transfers, but could use a bit more information.
Great answer, that was the problem! Going back to 1.2.5 fixed this issue. I tested another USB1.1 PCI board (CMD chipset) in the meantime, which did not help at all. So this was no VIA problem. Btw: I did not know that I had to deinstall the driver for each XEM3001 individually! When I switched back to 1.2.5 the one non-working board was ok and all others had this yellow ! in the device manager. So I had to choose ‘deinstall’ on each board unplug, replug (the actual driver installed automatically) and everything was fine again.
Generally: One option is to use Win2K with USB2.0, the other option is WinXP with USB1.1 or 2.0. Than I may use the new driver. Right? In this case I rather send our customers a new USB2.0 board (<10$) …
Our limited experience with Win2K machines shows that it works fine with 2.0 interfaces. However, feedback is somewhat limited in this area – Win2k is 7 yrs old (!) and a vast majority of our users are on USB 2.0.
Windows stores driver associations in a per-device manner. In most cases, this is a nuisance because even moving a device to a different port can cause it to have to reload the driver. This only occurs with devices (like the XEM3001) that have a serial number so that multiple devices can communicate in the same system.
Our current solution to the Win2k problem is looking like this-- we will add a configuration method to disable asynchronous (queued) bulk transfers. Unfortunately, there does not appear to be a convenient way to detect which machines will encounter this problem, so it will need to be a user-called configuration option.
The biggest drawback is the reduced performance when it is called. However, since it appears to only affect USB 1.1 machines, this performance hit will not be noticed.