Driver for custom PCI device

[Mat Kramer]

We're considering writing a LabVIEW driver for a custom PCI data acquisition
card that we sell. We have a NT driver and DLLs that we can use to do most
of the work, but I'm not sure where to start as far as writing the LabVIEW
portion. This device doesn't use any standard interface. Is it possible to
extend VISA to work with a custom device?

Thanks in advance.

[Kevin_work]

Mat,
VISA is simply an API that sits on top of specific interfaces such as
GPIB, serial, and VXI. If your device does not use any of these then
there is no need to consider using VISA.

As far as the Labview portion, you can use the "Call Library Function"
to interface to your DLL.
My personal preference is to create the low level functions first and
then tie them together to make higher level functions. This gives the user
access to quick setups as well as fine control.

Have fun
Kevin Kent

Mat Kramer wrote:

> We're considering writing a LabVIEW driver for a custom PCI data acquisition
> card that we sell. We have a NT driver and DLLs that we can use to do most
> of the work, but I'm not sure where to start as far as writing the LabVIEW
> portion. This de
vice doesn't use any standard interface. Is it possible to
> extend VISA to work with a custom device?
>
> Thanks in advance.

[Greg_McKaskle2]

> We're considering writing a LabVIEW driver for a custom PCI data acquisition
> card that we sell. We have a NT driver and DLLs that we can use to do most
> of the work, but I'm not sure where to start as far as writing the LabVIEW
> portion. This device doesn't use any standard interface. Is it possible to
> extend VISA to work with a custom device?
>

As the other post pointed out, you probably want to use the DLL node,
officially called the Call Library function, to reuse your DLLs from
LV. You may want to look at some NI drivers for examples. The DDE
VIs still ship with LV and they evetually call into DLLs, plus some
of their functions support asynchronous calls. This isn't quite as
important with multithreading, but it is still a nice thing. Other
drivers
examples that are external to LV are DAQ, VXI, IMAQ, and lots
of third party drivers.

The biggest thing to watch for, as with any code interfacing, is
datatypes and allocations. There is an online manual called the
Code Interface Reference Manual or something like that. It covers
LV datatypes and talks a bit about LV data conventions. Using the
DLL node you can choose C datatypes and largely ignore this, but
that does mean that you must preallocate most arrays on the LV
diagram before calling the DLL. In a few cases, it may be easiest
to make some additional exported functions in the DLL to do things
like return array sizes or to simplify datatypes or pointer usage.
Another feature you will find useful, but potentially dangerous is
the Adapt to Type option on the DLF node. It will allow you to
build a LV cluster the same as a C structure, and in many cases
you can use adapt to type to communicate between them.

Another way to do this, is of course to contact an alliance member
th
at has done this in the past. They can contract with you to do
the work. The NI web site has information on the Alliance program
at www.ni.com/alliance.

Greg McKaskle

[Scott Kovner]

VISA 2.0.1 or later can be used to write drivers for any custom PXI device
using the LabVIEW VIs. Most PCI devices should also be programmable using
the PXI API in VISA, since PCI and PXI are very similar from a software
viewpoint.

Scott Kovner
Senior Software Engineer
National Instruments

"Mat Kramer" wrote in message
news:83rakq$2o31$1@news1.spacestar.net...
> We're considering writing a LabVIEW driver for a custom PCI data
acquisition
> card that we sell. We have a NT driver and DLLs that we can use to do
most
> of the work, but I'm not sure where to start as far as writing the LabVIEW
> portion. This device doesn't use any standard interface. Is it possible
to
> extend VISA to work with a custom device?
>
> Thanks in advance.
>
>
>

[BIRA_PXI]

Hello Scott,

Can you please provide some links on how to get started in the process of writing device drivers using VISA and integrating it with Labview. Are there any examples for custom device drivers that have already been written using Labview ?

Thanks a ton,

Sandeep

[Robert M]

Sandeep,

Here's a good starting point for you, assuming your custom device is PCI:

Using the VISA Driver Development Wizard and NI-VISA to Register-Level Program a PXI/PCI Device unde...

If it is not a PCI device, what type is it?

[BIRA_PXI]

Hi Robert,

Thank you for the link. Its a Compact PCI device. I was wondering if any of NI drivers will also be a good starting point. For example the NI driver for NI-4072 ( 1 channel DMM ), since these drivers essentially read and write from the memory and the config space of the DMM using the cPCI/PXI bus.
Are these NI drivers written using VISA and Labview ? I want to limit my development to labview and not extend it to Labwindows/CVI.
Please advise.

Thank you,

Sandeep

[Robert M]

Sandeep,

Unfortunately we don't provide the driver source code for any of our PXI or PCI devices.  The example given in the link I posted will have to suffice.

Thanks,

[gekr]

Robert, or any who have solved this...

if I understand the description in the link you mentioned, with that tool I can create an Windows device driver. With this the device is known in the system. That's imortant and essential.

But interesting the interesting question is, how can I use this driver from labview? How can I read and write to my card? And how can I read or change the configuration registers? Thats also the question of the other - I think.

Is there really no template available für LabView?  Or a full excample, which I can use and change for my requirements? In a former project, we used windriver which generate the .inf file and an .dll-template to allow access to the card (open(), close(), byteRead(), byteWrite(),....).

Or can I use such a .dll as an IVI driver? I am a litte confuse about the driver world of LabView. As I see in http://www.ni.com/ivi/ the IVI is above VISA!? For my understandig till now, IVI is lowLevel (like the mentioned dll) and VISA is highlevel!? So this two boxes should be changed.

Also there is the question to me, what components, vi,.. I need to talk to my card?

I hope to get help or links to a documentation regarding this. Thanks

Georg

[Dennis_Knutson]

In order to communicate to a PCI/PXI device, you use either the VISA low-level or high-level register access functions. There are shipping examples of each. The descrption of each says that they are used to communicate to VXI/VME devices but the only difference between VXI/VME and PCI/PXI is the address space. If I remember correctly, 13 is for PCI. The register functions are similar to what you descibe with functions to read and write a specific register. The low level functions are more efficient. You are required to use the Map Address function first, do the read/writes, and then do the Unmap Address. The high level functions do the map/unmap each time. All of this is shown in the examples.

You cannot simply 'use' an IVI driver'. One has to be written for your board and it would have to be written with LabWindows/CVI. IVI is a higher level driver than VISA. You start by first creating a specific driver for a board/instrument. The communication to the board/instrument is done with VISA. The functions you implement for the board/instrument are mapped to instrument class functions. For example, if the board/instrument is a type of DMM, then there are certain functions that have to implemented. You would implement a measurement function (i.e. Volts, Amps, Current, etc) with the specific code for your device. An end user would use the IVI DMM class driver which in turn would call the specific instrument driver, which would in turn issue the actual commands to the device.

If you choose to implement a driver with VISA, then you would have to distribute VISA with the driver or require the end user to download and install it. There are some licensing issues that you may need to address. If the board and driver is intended for only LabVIEW users, then there is issue. If you want the board to be used by developers in C, C++, .Net, etc, you may be better off developing a more traditional windows type driver. A LabVIEW driver can then be created from that using the Call Library Function Node.