How does one use imported CVI instrument drivers in LabVIEW 6.0 on Win 2k?

[andrewW]

Thanks to ian.f for his pointers on the subject.

The query I put to the Discussion Forum related
essentially to the fact that I have downloaded
and imported the ID Library CVI instrument
driver for the Solartron 7150 Digital
Multimeter (so7150) to LabVIEW 6.0, but cannot
read data from the instrument using the relevant
.vi's in the library created on importation.

The rather significant bit I left out in my
haste is that I do not have LabWindows on my PC.
Is it still possible to create the dll necessary
to use the imported instrument driver?


Thanks in advance,

Andrew

[JeremyB]

Andrew,

Unfortunately the short answer to your question is no, you will need LabWindows/CVI on your PC to create the instrument driver DLL. The Convert CVI FP file option in LabVIEW simply creates a wrapper VI for every function exported by the DLL.

However, all may not be lost... I would suggest talking nicely to your local NI Technical Support team and ask if they could do this for you (it is only a five minute job and they can then email the resulting DLL back to you).

Bare in mind that you will also require the necessary CVI run time engine files installed on any PC that has the DLL i.e. your development computer and any computers you may be targetting with your application. You may have these already on your PC as they are often installed as part o
f other NI applications/drivers. If not you can get the appropriate versions from the following page on the NI web site:

http://digital.ni.com/softlib.nsf/webcategories/85256410006C055586256BAC002C50D1?opendocument&node=132070_US

Jeremy

[andrewW]

Thank you for your answer, Jeremy.

The DMM driver is imported and running as per spec.
My only problem at the moment is efficiency relating
to getting number of possible error-free readings per
second to approach the values stipulated for
integration times <400 ms.

Needless to say, the manner in which the test .vi's
are impemented may be contributing to the disparity.

Andrew

[JeremyB]

Andrew,

Trying to actually get the manufacturers specified performance figures from a DMM via GPIB is often a big challenge! I have come across instances in the past where DMMs have been specified at 1000 readings/sec but in reality it was never possible to achieve such acquisition rates due to the bottleneck caused by the GPIB interface.

Looking to optimize the VIs within the instrument driver can often give good results. There is probably going to be significant overhead if you are performing single reads from the DMM (due to repetitive open instrument/read instrument/close instrument process). If the instrument allows you to set it up to retrieve multiple measurements you might be able to achieve the performance you are looking for.


Jeremy

[andrewW]

Jeremy,

Thanks again for an insightful reply.

I am indeed trying to optimize the driver VIs. The
structure and hierarchy is fairly simple as evidenced
by the C program code.

As you might be aware, the driver includes separate
VIs for initialization, configuration and measuring.
These three provide the functionality I require. The
main problem is that the Set Integration Time sub-
function is contained within the Configure function and
the latter does not have a control for the former. The
Set Integration Time is, however, available as a VI on
the driver menu. The fragmentation of functions is
underlined by the fact that the GPIB address (integer)
is set by the Initialize VI and this VI alone. Since
I have two DMM
s in my experimental setup, I have to
separate GPIB communication with them into non-
overlapping local contexts in LabVIEW. Even after
initialization and subsequent configuration, the
Measure function does not work. To take measurements,
I have to use the Configure and Measure function which
essentially combines the functionality of the two
functions - without explicitly setting a GPIB address
either.

How time consuming is the initialization of a GPIB
address? The intuitive solution whereby the
configuration and reading functions all set the GPIB
address should be possible without drastically reducing
read rates, shouldn't it?


Sorry for the treatise length,

Andrew

[JeremyB]

Andrew,

The problems you are facing I have to say are not uncommon. Instrument drivers have never been the most efficient way to communicate with an instrument. Don't get me wrong they are excellent at getting you up and running and giving a better understanding of how to communicate with the instrument. New instrument driver philosophies such as IVI improve the original instrument driver in a number of ways - one in particular that might help you here is that of "state caching". This process is simply one where the instrument driver knows what state the instrument is currently in. So if you configure the instrument for a particular range or measurement, the next time you take a measurement it remembers this fact and does not attempt to send out unnecessary commands across the GPIB bus.

With traditional instrument drivers you need to be aware that in their original form, they may be sending out redundant calls to the instrument and this will provide an overhead within your application. How much of an overhead this will cause can vary (sometimes dramatically). You have some good tools that you can use to help you better understand the performance aspects of the GPIB communication process. First and foremost is NI Spy, which will allow you to view all GPIB comms along with a time stamp - you can see exactly what commands are being sent out to your instruments. Secondly, the Profiler within LabVIEW may be of use to help identify bottlenecks within the code that you are developing.

If you do find that everytime you take a measurement, the instrument driver is sending out redundant commands to reconfigure the instrument, your way forward might be to consider taking the ASCII strings sent to the instrument (viewable in NI Spy or in the .c source code file in the original CVI instrument driver) and getting to grips with the LabVIEW GPIB Read/Write VIs.

Instruments, in common with most pieces of technology often have a 1001 different functions but you find yourself only using perhaps 10% of them. By this logic you may find that actually writing some specific GPIB comms VIs for your application is not going to be a major task - there are some template VIs provided with LabVIEW if this is a new area for you.

The code steps I would consider would be:
initialise
configure
take measurements (in a loop if no of measurements>1)
clear instrument (resource tidy up)

Try to take the instrument configuration steps outside of the loop if at all possible i.e. if you know that all you want to do is set the instrument up in a particular state.

If you find that the architecture of the instrument driver does not allow you to do this directly i.e. with the VIs generated by the FP conversion process it will be time to get your hands dirty and do it yourself!

This can often be the way when trying to get the best performance out of an instrument driver. Still on the bright side you should have all the necessary information (in terms of strings to send to the instrument).

Let me know how you get on - I'll take a look at the attached driver files over the weekend to see if there is anything else that might help.

Best wishes
Jeremy

[andrewW]

Thanks for the reply, Jeremy.

I am a relative newbie in the LabVIEW world, having
used it only very occasionally over the past year.
Total programming portfolio is a mere 16 (small) apps
exclusively performing GPIB I/O.

NI Spy starts, but all fields on its screen remain
blank despite the fact that MAX detects instruments
on the GPIB. Nothing is monitored. Since no error
message is displayed, I am at a loss as to what
could be the matter. Could the GPIB driver version
have something to do with this?

In respect of the intrument driver architecture, The
ideal functionality would be initialization outside
of the multiple measurement loop as you point out.
Since I require readings from both DMMs from within

the measurement loop, I thought furnishing the Measure
function in the attachment with address initialization
would suffice. As indicated in my previous comment,
however, the Measure function does nothing both with
and without address initialization. For now, I am stuck
with initializing integration times using the driver
VIs and subsequently measuring using LabVIEW's GPIB
Read.


Best regards,

Andrew

[JeremyB]

Andrew,

Try the following link for help with NI Spy:

http://www.ni.com/support/gpib/max/nispy.htm

Jeremy