Anyone succesfully wrapped winusb.dll in Labview code?

[rolfk]

It's not that anything in 8.6 or later makes it very much easier, but only 8.6 and later support the pointer sized integer datatypes in the Call Library Node. So you either configure the Call Library Node to use a Int32 for HANDLES and make it compatible to all LabVIEW versions but not 64 Bit, or you use the pointer sized integer to support 32 bit and 64 bit but then it won't be possible to make it work for < 8.6.

I wouldn't go to the extra length of using the conditional compile structure to implement the same stuff both for < 8.6 as 32 Bit and for >= 8.6 as pointer sized mainly because I simply consider that a stupid exercise but also because it would need additional trickery to still work.

[Jusborne68]

Understood. Thanks for the information Rolf.

John.

[Intaris]

---

@Jusborne68 wrote:

Unfortunately, I'm stuck using 8.2.1 as the company that I'm contracting to is very tight on money and software updates are at the bottom of their priority list. What happened post 8.6 that made this task easier? If there was a compelling reason to upgrade I could probably talk them into it but I still may have to support 8.2.1 as well.

If I could get VISA to work I would be going that direction but I need to interrogate the port as fast as possible (every 1-2 mSec) and the VISA timeout for some reason has a minimum settable value of 50 mSec. I talked to NI about this and they don't know why this limit is there but ut is.

John.

---

With regard to MY statement on LAbVIEW versions, I simply made use of some LVOOP features not present in 8.6.  Nothing to do with VISA.

With regard to polling the device, at least interrupt endpoints have a hardware setting as to how often they can be polled.  For most mice this is in the region of 5 to 20 ms, whereas some special gaming mice go as low as 1 ms (Maximum polling rate allowed according to the USB 2.0 spec.).  Since the majority of these thingas are more or less hardware implemented, it's not really possible to change this in software.  You can of course poll slower than desired, but not faster than the device dictates.  The USB subsystem normally will not allow this.

Shane.

[Jusborne68]

The USB hardware that I am working with is a virtual serial port. They used to use RS-232 to shoot telemetry data out but since RS-232 is getting harder and harder to find, they decided to switch it to USB. The data used to be sent out regardless of if there was an instrument connected. Now, USB needs to interrogate. The buffer at the port is small so if you don't interrogate fast enough, data gets lost.

With the VISA, raw USB does not have a bytes at port output so you need to set a fixed number of bytes to read. If that number of bytes aren't there then the 50 mSec timeout takes effect and data is lost. Ideally, I would set this timeout to 2 mSec (?) so that it would timeout fast enough that I wouldn't lose any data. Since I can't do this with VISA, I'm left to try and find a different strategy.

If I can find a reason why Labview 2011 would make my job easier, I could probably get them to upgrade.

Thanks for your reply. It is appreciated.

[Intaris]

IS the USB transport over COntrol, Bulk or Interrupt endpoints?

[Jusborne68]

All transfers are over bulk so limited to 64 bytes. Was hoping for isochronous for more data per transfer but not supported by chip firmware.

[rolfk]

---

@Jusborne68 wrote:
All transfers are over bulk so limited to 64 bytes. Was hoping for isochronous for more data per transfer but not supported by chip firmware.

---

Windows only supports isochronous when writing a specific Windows Kernel device driver. All other venues do not support isochronous operation at all.