dynamically loading drivers for similar instruments

[Michael Ludwig]

I am writing a test module that communicates with different types of instruments (balances, thermometers, hygrometers etc...) of all different makes (MettlerToledo, Vaisala etc). The module must be able to work with many makes of balances, thermometers etc. How would you suggest i go about this?

The ideal would be to write IVI drivers, but these intrument types are not coved in the specifications. Is there still some way to register, say, balances with MAX?

Is the only other solution to write make-specific drivers for each instrument that all have one single top-level vi with the same connector pane and to dynamically load it with vi server?

thanks for any input,

michael

[Makoto]

Even if your instrument type is not defined in the IVI instrument class list, it is still possible to write your own (or vendor specific) instrument class and its class driver.  However writing your own instrument class and its class driver is not so easy.  Actual technical approach is different depending on the driver type, IVI-COM or IVI-C.

If IVI-COM, design your own class interfaces (COM interfaces).  Each specific driver must implement all the instrument-specific interfaces, your class's interfaces, and IVI-COM inherent interfaces.  Building the class driver DLL is not always needed as long as your class COM interface is compiled to a TLB module.

If IVI-C, design your own class interfaces (C API) and its corresponding FP file with LabWindows/CVI, build the true "class driver", which implements on-demand search mechanims for dynamically loading instrument driver DLL, invoking the dynamically imported DLL functions, by referencing the IVI Configuration Store.

What programming language do you use?  Depending on the language, you may have easier solution other than using true IVI interchangability approach.

[thehobbs]

If LabVIEW is your programming language of choice, then the approach you describe is probably a good one.  This solution would give you an IVI-like approach but all components would be native LabVIEW.

Depending on the degree of interchangeability you are looking for, you might consider packaging your similar driver VIs for different instruments together in polymorhphic VIs.  Technically, this would remove the need for higher level class VIs and class configuration, but would require going throughout the code and selecting the appropriate instrument driver for each poly VI when you want to change instruments.  I'm not sure how acceptable this will be for your application as it will require users to touch the LabVIEW code.

Jason Hobbs

[Michael Ludwig]

I am using LabView as a programming language and already have access to LabView Plug&Play drivers for most of the instruments. It does seem that writing a full IVI compliant driver would be too much extra work. Do you have any other suggestions, short of modifying the P&P drivers so that they all work with a custom 'class-driver' that i would write in LabView?

thanks for your help,

Michael

[Makoto]

Writing polymorphic VIs is not so bad but it still privides interchangability of "source-code" level. If your application requires interchangability allowing to swap the instrument drivers at runtime (without source code change), true IVI or pseudo IVI-like approach is needed.  This means you will have to provide "dynamic DLL loading" mechanism as like every IVI class driver does.

If acceptable, try consider to use partially C/C++ language for this kind of dynamic loading mechanism, assuming each instrument driver is built as a compiled DLL.

[Noel]

Your original idea is a good idea:

"... write make-specific drivers for each instrument that all have one single top-level vi with the same connector pane and to dynamically load it with vi server"

You don't have to make a single top-level VI.  Maybe group VIs into self-contained operations.   This way the Initialize and Close routines are separated out.   What reservations do you have about this approach?

[Henrik_Volkers]

I solved the same task with the vi-server approach. It's running in our lab(s) for more than 2 years now.

New instrument driver vis are now mostly only a question of hours (to find out how the instrument works/ RTFM) , since most of them use RS232 and its mostly only a quick change of command strings and format strings.

I recommend an approach without strickly typed vi server calls. Like that you can call all the instrument vis in independent background tasks. Just in case one Instrument hang the rest will still work. You can use named queues to send your values to the main application / GUI or (like I did) LV2 style globals.