"Ed Sutton" wrote...
> My plan was to call "Automation Open" in my instrument driver's
> Initialize.vi and make "Automation Refnum" an output of the Initialize.vi.
> This seems to be non-ideal since users will have to wire an "Automation
> Refnum" input to *** ALL*** Instrument Driver VI's used.
I'm not sure I follow you completely, but I think you're on the right
track.
First of all, I like your idea to insulate your end-user as much as
possible from COM. The closer you get to a traditional instrument driver
interface, the less dependent you are on a specific implementation
underneath--GPIB, TCP, RS-232, COM/DCOM, .Net, etc. (I'm blurring some
lines between protocols and programming models here.) Insulating users from
these differ
ences will, in turn, will help with long-term code
maintainability. NI-VISA does a good job of hiding the details of GPIB vs.
TCP/IP vs. RS-232, etc. The COM/DCOM/.Net approaches to abstraction impose
an alternate proprietary way of doing things, but I think you can still hide
it in an instrument driver reasonably well.
Following the traditional instrument driver model, you will have some
sort of "refnum" input to all your VIs, and with a COM-based driver, it's
easiest to make that an Automation Refnum opened in your Initialize VI.
Additionally, you'd like to avoid having the user do anything with that
refnum other than wire it to one of your VIs. You don't want the end user
to directly deal with Invoke and Property nodes for the Automation Refnum,
because then the user has to understand the structure of the COM object
(which isn't going to be a traditional instrument driver structure). Your
instrument driver VIs should encapsulate all of the COM stuff.
I hope this h
elps.
Brian