....
> In a way, that is part of the issue with IVI. NI scares users into
> thinking that programming instruments is so hard that the only way to
> really get it done right is to let them do it. Theres's two problems
> with this line of reasoning. First, programming instruments isn't that
> hard and if you did the sums, you would probibly find you spent more
> time trying to workaround problems in existing drivers than it would
> have taken to write your own. Second, it ignores the point that NI
> never could write a decent instrument driver--and now if something is
> broken you have to buy another development environment from them to
> fix it.
>
> Kind of make you wonder what the real motivatio
n behind IVI is...
>
Actually, the point of IVI is to make for interchangable drivers, for
those that use common functionality and can't afford to have mfg down
due to a particular instrument being hard to locate. In reality, NI
would rather see drivers being built by the makers of the instruments
since they know the ins and outs of the particular instrument. The
fundamental problem here is that the more complete the driver, the less
willing the author is to write it over and over in multiple languages.
Ultimately, it seems that simple drivers are available in multiple
environments and languages, but more complex and more complete drivers
are available only as a DLL or some other component that is usable by
the largest number of people and the largest number of environments.
My suggestion is to make your wishes for various drivers known with both
NI and the instrument maker. Also make it clear which
language/environment you use and how complete you expect it to be.
Greg McKaskle
