Hello Steve:
At National Instruments, we face similar issues. Historically, we have
recommended making native LabVIEW drivers to address LabVIEW user's needs.
This
was necessary for a few reasons, including:
1) Only native LabVIEW drivers can run on all LabVIEW platforms (Macintosh,
Sun, Windows, etc.).
2) Due to varying quality of drivers available, LabVIEW users wanted access
to
modify source code. A DLL approach would require LabVIEW users to a) know
C
and b) have a separate compliler.
In talking with our customers, it seems that they wouldn't mind a DLL
approach
as long as the driver delivered more in terms of performance and quality.
As a
matter of fact,they demanded higher performance and quality. Hence, we
introduced some new instrument driver technology we call IVI (Intelligent
Virtual Instruments or Interchangeable Virtual Instruments -- see
www.natinst.com/ivi or www.ivifoundation.org for details). This approach
is a
DLL approach so it does have some OS limitations for our LabVIEW customers.
However, for our LabVIEW users on a Win32 system, we have delivered higher
performance and quality. This includes interchangability, simulation, state
caching, among other features. We also spend considerably more time in our
development and testing phase than with past legacy drivers. In order to
address the LabVIEW needs with user friendly VIs, we spend a few days
customizing the converted drivers for LabVIEW users.
In LabVIEW there is a feature to convert vxipnp drivers to LabVIEW.
Although
LabVIEW customers could do this on their own, it does put the responsibility
to
get everything working in their hands. This is not recommended as the raw
converted driver is not "user friendly" for LabVIEW users. The panel layout
is
not optimal, the terminal assignments are not optimal, the on-line
documentation
tends to be geared for CVI users, etc. This conversion does create menu
files
(.mnu), but they also might need touched up.
Here at NI, we do the conversion for the customers. We then fix up the help
to
make sure it uses LabVIEW terms, not C-API terms. For example, LabVIEW
users
have "VIs", while C users use "functions". Next we re-organize the front
panels, make better terminal assignments, and create Getting Started VIs.
Similarly, we also go through the VIs and see if there is any redundancy
between
inputs and what is created from the conversion process. For example, in
order
for an array to be returned from a DLL, it needs to have memory allocated in
LabVIEW. The conversion process adds a terminal to specify the size of the
array. However, it is possible that the instrument driver function already
has
a parameter which specifies the size. This redundancy should be addressed
to
avoid confusion. There are other similar fixups that are needed. LabVIEW
5.1
has additional features to address IVI drivers.
In short, I would recommend NOT putting the burden of conversion on LabVIEW
users. The conversion for an average users is too difficult and the results
are
not satisfying. The driver developer should address their needs to make the
driver more LabVIEW friendly.
Have you considered making your vxipnp driver an IVI driver?
Let me know if this doesn't answer your question or if you have further
questions.
Best Regards,
Noel Adorno
Product Support Engineer
Instrument Drivers/IVI
Steve Lomas wrote in message
news:37c390d5.437304@news.easynet.co.uk...
> Hi
>
> I'm developing VXI PnP (VISA) instrument drivers for my Company's
> products using LabWindows/CVI and I would like to ensure that they are
> usable, and as user friendly as possible, for LabView users. I believe
> that the minimum requirement in addition to the standard files
> produced by CVI is the .dll file. Are there other files
> (e.g. .mnu files) which would make life easier in LabVIEW, and would I
> need to have a copy of LabView to produce them?
>
> I'd appreciate your advice.
>
> Steve Lomas
