Nugget: 1 of n : GEtting started with USB communication via VISA

[Standardnutzer]

It just doesn't accept the selected driver - if I pick and choose the VISA RAW driver file Widows says:

in English: 'No Information on this hardware in the file specified'

????

[Intaris]

OK, ich bin ratlos.

Bist du sicher, dass du die PID und VID für das Gerät richtig eingegeben hast?

Ich habe solche Problems nie gesehen.  Irgendwas triviales machen wir anders.

Shane.

PS Oops slipped into German: for others here is the english

OK, I'm out of ideas.

Are you sude you have aassigned the PID and VID correctly for the device?

I've never seen this problem.  We're doing some trivial thing differently.

Shane.

[Intaris]

Just to add to what I've previously posted....

During testing I've even managed to lock myself out of my PC by installing a VISA driver for my mouse and keyboard.  I have no idea why this isn't working for you.

If the driver dialog is saying that the device driver created by VISA doesn't have any data corresponding to your device, then there must be something wrong with the device driver.

Is your mouse part of a mouse / keyboard combination by and chance?  These are compound devices (more than one interface) and need to be treated differently to devices with a single interface.  I had lots of trouble getting communications up and running with my Logitech combi keyboard and mouse but it did eventually work.  Working with simple mice and keyboards (single device connected directly via USB to the computer) has never been aproblem for me.

Shane.

[Standardnutzer]

Ich versteh's halt auch nicht. Ich habe den Treiber mehrmals erzeugt und das ganze schließlich auch für einen Joystick probiert. Kann es sein, dass Windows bei irgendeiner Einstellung keine anderen Treiber für HID Geräte zulässt als die eigenen?

Uli

[Intaris]

Keine Ahnung.

Ich habe halt immer USB-sniffer software bei mir installiert.  Könnte sein, dass das Software irgendein Registryeinstellung ändert....

Ansonsten habe ich nichts gezielt geändert.

Was genau für Hardware hast Du probiert?

Gruss

Shane.

[gdubb85]

Shane,

I have been scouring your tutorial and NIs website and cannot find the infomation I am looking for...I wish to SIMULATE a device.  I.e. I don't need a driver installed on the host to communicate with a device, I need to model the device and have it respond to the command set of the device when the Host talks to it.  I have a spec from the manufacture with its Product ID/Vendor ID (which helps to install the RAW driver on the Host side) and the set of expected commands/responses the device should support, but I don't know how to talk USB from the device's POV within Labview.

Is this possible?  Thanks so much for this informative post so far.

[Intaris]

Don't know how to simulate a device, sorry.  That's a different topic entirely...

Shane

[rolfk]

Well, simulating a device in software you can do in two ways:

The hard and generic one, is to write a device driver that behaves like the device. But that would mean you have to write a kernel device driver in C. If what you want to do is having a simulation driver to develop and test your LabVIEW (or VB, Delphi, etc) instrument driver then this is really the only way to do it. But without exact information as to the USB protocol of the device, and SERIOUS knowledge about kernel device driver development, you are not going to get anywhere on this path.

The more usual case is to build a LabVIEW driver that has two modes. In one it talks to the actual hardware through whatever means the device dicates and in the other all that communication to the device is bypassed and the instrument driver VIs do something more or less useful, such as simply ignoring commands and for query functions returning some random or otherwise logical data. 

[Intaris]

@Rolf,

as usual, you're right on the money.

IF the simulation is only for use in LabVIEW then you can implement the dual-mode driver as Rolf mentioned.

The other way might to be to go the "Arduino" route and actually IMPLEMENT a hardware device which pretends to be the device you're referring to.  This is perhaps easier than writing a kernel driver but has limited possibilities and is still quite complex.

Shane.

[rolfk]

---

Intaris wrote:

The other way might to be to go the "Arduino" route and actually IMPLEMENT a hardware device which pretends to be the device you're referring to.  This is perhaps easier than writing a kernel driver but has limited possibilities and is still quite complex.

Shane.

---

Having a working, and I mean a really working hardware is not really easier than a kernel driver 🙂