When is a VI a "driver" ?

[BrokenArrow]

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!

[LAVA 1.0 Content]

QUOTE (BrokenArrow @ May 13 2008, 10:21 AM)

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

[PaulG.]

QUOTE (BrokenArrow @ May 13 2008, 10:21 AM)

... It's an over-used term at best.

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

[Michael Aivaliotis]

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.

[James N]

QUOTE (Michael_Aivaliotis @ May 13 2008, 01:36 PM)

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

[BrokenArrow]

QUOTE (Michael_Aivaliotis @ May 13 2008, 01:36 PM)

.....a hand full of turd balls...

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

Richard

[eaolson]

QUOTE (Michael_Aivaliotis @ May 13 2008, 12:36 PM)

Unless of course you're a mystical fairy who shoots pixie dust out of your a** when you fly.

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

[PaulG.]

:laugh:

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?

[Gary Rubin]

QUOTE (PaulG. @ May 13 2008, 02:12 PM)

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

[BrokenArrow]

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

[crelf]

QUOTE (BrokenArrow @ May 13 2008, 10:21 AM)

When is a VI a "driver" ?

1. When your manager, vendor, or girlfriend referes to it as such
   

Yes ma'am!

QUOTE (neB @ May 13 2008, 10:34 AM)

To me a driver is software entity that translates opeartional requests into hardware interactions that produce required results.

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.

[BrokenArrow]

QUOTE (crelf @ May 13 2008, 03:56 PM)

... it's all a matter of your frame of reference.

Argh!

OK. WHAT is THIS?...

• A VI
  
• A Driver
  
• A Turd Ball
  
• All of the above
  

[crelf]

QUOTE (BrokenArrow @ May 13 2008, 05:46 PM)

Argh!

QUOTE (BrokenArrow @ May 13 2008, 05:46 PM)

OK. WHAT is THIS?...

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

[Daklu]

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.

[BrokenArrow]

QUOTE (Daklu @ May 13 2008, 07:14 PM)

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.

QUOTE (crelf @ May 13 2008, 06:25 PM)

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

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

:beer: Richard :beer:

[Aristos Queue]

QUOTE (PaulG. @ May 13 2008, 01:12 PM)

The actual dll or C code is the "driver". Or am I full of pixie dust?

What if the DLL is a LV-built DLL? Do the VIs in the DLL count as a driver?

[Daklu]

QUOTE (BrokenArrow @ May 13 2008, 05:45 PM)

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.

Hence the inclusion of "almost" and my comment, "I suppose there may be some trivial cases where a single vi could serve as a driver."

QUOTE (BrokenArrow @ May 13 2008, 05:45 PM)

But I assert that it isn't a driver, but is a LabVIEW VI.

Why can't it be both? "VI" and "driver" are not mutually exclusive. A vi is simply a bunch of G code saved as a single file. It refers to where the code is. A driver refers to what the code does. The case you presented is both a vi and a driver.

I'm certainly not claiming my definition is the best there is, but it works well for me. I constantly struggle with "where should this code go?" when writing code. Keeping that definition in mind helps me make better decisions. It also easily answers questions in AQ's post.

QUOTE (PaulG)

"The actual dll or C code is the "driver". Or am I full of pixie dust?"

If you're going to follow that path, is the source code the driver or the compiled code? If it calls the OS API to perform low level functions is the operating system the driver? Drivers written in .NET and compiled into intermediate code? Drivers written in interpreted languages? What a mess...

The dll is a driver--so is the Labview code wrapped around it. I see no problem with drivers having multiple layers. To refer to my translator example, suppose I need to do business with someone from Russa but there are no English-Russian translators available. My Swedish translator has a friend who speaks Russian so we use both of them to bridge the gap. My translator handles the English/Swedish translation and his friend handles the Swedish/Russian translation. Can I claim one of them is the "real" translator?

QUOTE (AQ)

What if the DLL is a

LV

-built DLL? Do the VIs in the DLL count as a driver?

It waddles, quacks, and floats on lakes... must be a driver.

[Rolf Kalbermatter]

QUOTE (Gary Rubin @ May 13 2008, 01:56 PM)

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).

I don't think you can draw the line that strictly. Very strictly speaking the device driver is nowadays the piece of software that translates user application level requests into hardware specific cammands and address accesses. And that piece has to reside inside the kernel as kernel mode device driver since that is the only way to directly access hardware in nowadays protected mode OSes. However talking to that kernel device driver directly is tedious at best so they usually come with a DLL that provides an easier to use API and can be considered part of the driver as well. But with that I do not see any reason to exclude the LabVIEW VIs that access that API as being part of the driver either. After all they translate the not so easy to use DLL calls into something that can be used much more easily in LabVIEW.

And once you are there why not qualify any collection of VIs that translates access to some form of hardware in something more LabVIEW friendly as a driver too?

I wouldn't go as far as calling VIs to access the normal OS API as drivers though, but that is an entirely arbitrary and subjective classification on my part.

Rolf Kalbermatter

[BrokenArrow]

Thanks for all the responses. Great stuff. I've come to three conclusions:

1. I've concluded that this topic is "entirely arbitrary and subjective" to borrow a phrase from Rolf. :worship:
   
2. When the Quality Department asks me to divide my Software Release Document into the VI's that are drivers and the VI's that are not, I will just make a best guess and that'll be that. It may be up to non-LabVIEW programmers to make my mind up for me. :laugh:
   
3. I know that when I add "EasyDAQ.dll" alongside my VI's, there's going to be heck to pay.
   

Richard

[Michael Aivaliotis]

QUOTE (PaulG. @ May 13 2008, 11:12 AM)

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?

Wait a minute. Hold on there. So if a VI makes a VISA call to a GPIB instrument and that VISA call has a string input constant with a properly assembled format taken from an operating manual for that instrument, it's not a driver? You better tell that to 90% of the instrument vendors out there. "LabVIEW SDK", now I'm really laughing out loud!!! HAHA.

QUOTE (Gary Rubin @ May 13 2008, 11:56 AM)

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

Spoken like a real C programmer.

QUOTE (Daklu @ May 13 2008, 04:14 PM)

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.

I would agree that in complex hardware this may be true but I disagree that a single VI can never be called a driver.

QUOTE (Aristos Queue @ May 13 2008, 07:08 PM)

What if the DLL is a

LV

-built DLL? Do the VIs in the DLL count as a driver?

Touché

QUOTE (rolfk @ May 14 2008, 01:07 AM)

I don't think you can draw the line that strictly. Very strictly speaking the device driver is nowadays the piece of software that translates user application level requests into hardware specific cammands and address accesses. And that piece has to reside inside the kernel as kernel mode device driver since that is the only way to directly access hardware in nowadays protected mode OSes. However talking to that kernel device driver directly is tedious at best so they usually come with a DLL that provides an easier to use API and can be considered part of the driver as well. But with that I do not see any reason to exclude the LabVIEW VIs that access that API as being part of the driver either. After all they translate the not so easy to use DLL calls into something that can be used much more easily in LabVIEW.

And once you are there why not qualify any collection of VIs that translates access to some form of hardware in something more LabVIEW friendly as a driver too?

I wouldn't go as far as calling VIs to access the normal OS API as drivers though, but that is an entirely arbitrary and subjective classification on my part.

Rolf Kalbermatter

I agree with rolfk but I think we all need to make a distinction here. There is a different definition for the word driver depending on what software language you are using to program the application layer. To us, a driver can be LabVIEW friendly and contain VI's we just plop down (regardless of what's inside the VI's), or can be LabVIEW agnostic in the case of a pure C DLL call which we have to interface to by writing wrappers. In both cases, it's a driver but the level of LabVIEW integration varies. I think the best LabVIEW driver is not really called a driver at all, but is a specific Instrument Class using LVOOP.

[Rolf Kalbermatter]

QUOTE (Michael_Aivaliotis @ May 15 2008, 03:12 AM)

I think the best LabVIEW driver is not really called a driver at all, but is a specific Instrument Class using LVOOP.

What is best and what not is very discutable. LVOOP is most probably not such a bad thing but such a driver restricts its use to applications that can and will use LVOOP. Also just as with normal VI libraries the usefullness and ease of use depends greatly on the person implementing that class. You can make a mess with (LV)OOP just as easily as with normal VI library interfaces and in fact even easier since you need to understand OOP fairly well to really deliver easily reusable class implementations.

I'm sure this is biased by experiences with some C++ code which can be sometimes called horrible to understand at best but it's nevertheless a real experience and is also a result of my mind which likes visual representation very much but has much more affinity with a functional interface than with some of the more complex OOP design patterns.

Rolf Kalbermatter

[Michael Aivaliotis]

Perhaps "best" was too strong a word, but I think Classes need to be examined as a way of implementing hardware interaction.

[orko]

QUOTE (BrokenArrow @ May 13 2008, 07:21 AM)

When is a VI a "driver" ?

When it's not a http://www.youtube.com/watch?v=b7YenPOWjbw' rel='nofollow' target="_blank">putter?

[Gary Rubin]

QUOTE (Michael_Aivaliotis @ May 15 2008, 03:12 AM)

Spoken like a real C programmer.

Any C programmer who knows me would either laugh hysterically or be highly offended that someone might consider me a real C programmer. :laugh:

I can only write C if I have a C book open in front of me.

[PaulG.]

QUOTE (Michael_Aivaliotis @ May 15 2008, 03:12 AM)

... "LabVIEW SDK", now I'm really laughing out loud!!! HAHA.

LabVIEW SDK: ActiveX, dll's and/or C code drivers written by the manufacturer wrapped in LV Vi's. They usually include "example" programs demonstrating most of the functionality of the hardware along with full documentation*. They cost around $200 - $300. And laugh only after you try to do something like this by yourself without a "LabVIEW SKD".

*I consider myself blessed to get basic documentation from a peer working on the same frackin' project.