When is a VI a "driver" ?

1. It never is
2. It always is, if it talks to hardware
3. When the VI works only on a specific brand/model/part number of device
4. When its main purpose is to make API calls
5. When your manager, vendor, or girlfriend referes to it as such

Thanks!

There is probably a forma definition of a driver somewhere, that I 'll others find and link.

Years ago I asked "what is the difference between a mainframe and a super-mini computer?" The response was "Anything that cost more than $1M is a mainframe."

To me a driver is software entity that translates opeartional requests into hardware interactions that produce required results. An automobile driver takes request "turn left" slow down" and manipulates the hardware for that end. A disk driver accepts read request (read 100 bytes from block sector 500) into a "seek command" "header verify" "read 512 bytes" "transfer to client buffer".

Ben

And "elegant" drivers would be about as over-used as you can get.

One thing that ticks me off to no end is when you discuss a new application with a customer and they bring up the fact that NI has "drivers" on their website so this should automatically translate to: "The app can be finished in a day or two right?" People, a hand full of turd balls does not translate to a full blown user interface with real time graphing, reporting and data analysis application. Unless of course you're a mystical fairy who shoots pixie dust out of your a** when you fly.

That quote's going up on my door right now! Perfect.

-James

First time I ever LOL'd reading a LAVA post!

Richard

I'm going to go put that on my resume right now.

But seriously folks, to me a driver is a piece of code that allows me to use LabVIEW to interface relatively easily with a piece of hardware. A VI can indeed be called a "driver". Many companies sell LabVIEW SDK's with their equipment. They contain vi's that contain the dll's or the CIN's or whatever that allow you to communicate and control their hardware. That to me would be a "driver" VI. But more accurately I would call it an xyzdeviceInterface.vi. Not a driver. The actual dll or C code is the "driver". Or am I full of pixie dust?

I agree with that. If a VI is calling a device-specific DLL, I wouldn't call that VI a driver; the DLL would be the driver. I'd probably call a VI a driver if it was performing the hardware interface using only native Labview and OS functions (i.e. memory peeks/pokes).
Gary

I agree with the points that Gary and Paul have brought up. To take it a step further, a driver (to me) is something that a piece of hardware *can't* work without (think printer driver), whereas if you've written a LabVIEW VI that controls a device, the device may still stand on its own with something written in (god forbid) C or VB or Cobol or Fortran or Pascal or JAVA or HPV.... ... ...

Thanks for the input, I've been trying to get people to stop calling LabVIEW VI's "drivers" because I think that terminology can confuse a customer/user.

OK, back to my hand full of turd balls. These arrays aren't going to index themselves.

Richard

Yes ma'am!


Right - I also think that drivers can have wrappers (like translating error codes that a DLL spits out into a meaningful LabVIEW error cluster) which encapsulate the lower-level driver, and can be thought of as part of the driver itself. I think it's all a matter of your frame of reference.

Argh!

OK. WHAT is THIS?...

• A) A VI
• B) A Driver
• C) A Turd Ball
• D) All of the above

I'd say A that is also a B with some C

To me a driver is a piece of software whose sole purpose is to pass information from an application's business layer to/from a piece of hardware. If the driver contains business logic it is no longer just a driver and becomes an integrated part of the application. Or as I call it... a PITA.

I see a driver performing much the same role as a translator. If I need to conduct business with someone in Japan, I find a translator so we can communicate. If the translator is making business decisions on his own, then when I get another translator to do business in Sweden my system breaks down. I need to train the Swedish translator to make the same decisions as the Japanese translator. I restrict the translator's function to translation.

As to the original question, "When is a VI a 'driver,'" I'd say a single vi is almost never a well-written driver. (I suppose there may be some trivial cases where a single vi could serve as a driver.) A good driver is generally a collection of vis. If your hardware has a single vi as a driver it likely needs to be broken up or rewritten.

Well, I think that's true to the extent of complexity of the "thing" you're driving. I've used devices that just do one simple thing and the VI can fit on 1/3 of a screen, such as a high-current relay output board with just two relays. So to your point (or against it) I guess that would be an example of one VI being a well written driver. But I assert that it isn't a driver, but is a LabVIEW VI.



Well, since I wrote it, I can assure you it is a C (Turd Ball).
Richard