LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using COM in an Instrument Driver: How call "Automation Open"(CoCreateInstance) only once?

I am rusty with Labview and I am having difficulties readjusting to data
flow again.

If I use a COM object in an instrument driver, how can a user use my driver
so that "Automation Open" (CoCreateInstance) gets called only one time?

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.

Does this approach seem reasonable or is there a cleaner way to do this,
perhaps by accessing the WIN32 API's directly?


I will attempt to follow the NI driver template with the sugges
ted
Initialize and Close VI's, etc.

"Developing a LabVIEW Instrument Driver"
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/117
f9eaedfd2c9e58625680a005acd06?OpenDocument

I am hoping my COM component design can fit into the suggested instrument
driver component VIs six categories:

1-Iinitialize
2-Configuration
3-Action/status
4-Data
5-Utility
6-Close.

Thanks in advance for any tips or suggestions,

-Ed
0 Kudos
Message 1 of 5
(2,434 Views)
"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
0 Kudos
Message 2 of 5
(2,433 Views)
Brian,

Thank you very much for your reply.

> 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.

Yes, I was hoping to use re-use the COM component that my VB users use in a
LabVIEW instrument driver. I want to hide "Automation Refnum" from my
LabVIEW end-users.

> 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.

It seemed kind of ugly to requiring end-users to wire the output "Automation
Refnum" to all of my instrument driver's VI's. A traditional instrument
driver would not require this.

The "Automation Refnum" is a required input of the "Invoke Node" and
"Property Node" VI's. I was hoping to discover a way to hide the
"Automation Refnum" from my instrument driver end-users. I don't think
end-users should have to worry about what the heck an "Automation Refnum" is
and why do they have to wire it to all of the VI's in my instrument drivers.

I am thinking about another approach which does not use the LabVIEW "Invoke
Node" and "Property Node" VI's.

I am thinking I will make a DLL wrapper with an Initialize function that
creates the COM object and maintains a pointer to it. This will be called
from my Initialize VI. I will need to create wrappers for all methods and
properties that will use that pointer to call the actual COM methods and
properties. This is the only way I can think of to completely hide
underlying COM and "Automation Refnum" from my end-users.

Any thoughts on this? Maybe I am still thinking procedural instead of data
flow and having to wire the "Automation Refnum" to all my instrument driver
VI's is not so bad? Don't VISA drivers require end-users to wire a VISA
session to all instrument driver VI's?

Thanks again for your reply,

-Ed
0 Kudos
Message 3 of 5
(2,433 Views)
> Don't VISA drivers require end-users to wire a VISA
> session to all instrument driver VI's?

Yes.

> It seemed kind of ugly to requiring end-users to wire the output
"Automation
> Refnum" to all of my instrument driver's VI's. A traditional instrument
> driver would not require this.

Please expand on this. Is it ugly because it's an "Automation Refnum"
(as opposed to a VISA or IVI refnum)? Is it ugly just because there's a
refnum?

A digression...
Regarding this last issue, there was an earlier discussion (either here
or on info-labview) that talked about an instrument driver approach where
the icons knew what device they were supposed to talk to. E.g., if I only
have one NI-4070 6.5 digit DMM in my system, then why don't
the NI-DMM
instrument driver VIs know what to talk to? Why do I need to wire in the
name of the device and wire a refnum to all the NI-DMM VIs? This is an
excellent topic for discussion, but it requires a non-traditional instrument
driver API. I'm still thinking about that one. As soon as you have two
NI-4070's in your system, you have to be able to differentiate them and
you're back to a refnum approach.


Brian
0 Kudos
Message 4 of 5
(2,433 Views)
> > It seemed kind of ugly to requiring end-users to wire the output
> "Automation
> > Refnum" to all of my instrument driver's VI's. A traditional instrument
> > driver would not require this.
>
> Please expand on this. Is it ugly because it's an "Automation
Refnum"
> (as opposed to a VISA or IVI refnum)? Is it ugly just because there's a
> refnum?

I guess I was thinking it was ugly simple because the end-user has to go
around wiring an extra input to each and every driver VI's. However, I
think I am changing my opinion on that as I readjust to LabVIEW. Please
nothe that the last time I programmed in LabVIEW was around the LabView 3.0
to 4.0 transition. After programming in C/C++ since then, it's taking me
awhile for me to fi
nd the "LabVIEW way" of doing things again.

> A digression...
> Regarding this last issue, there was an earlier discussion (either
here
> or on info-labview) that talked about an instrument driver approach where
> the icons knew what device they were supposed to talk to. E.g., if I only
> have one NI-4070 6.5 digit DMM in my system, then why don't the NI-DMM
> instrument driver VIs know what to talk to? Why do I need to wire in the
> name of the device and wire a refnum to all the NI-DMM VIs? This is an
> excellent topic for discussion, but it requires a non-traditional
instrument
> driver API. I'm still thinking about that one. As soon as you have two
> NI-4070's in your system, you have to be able to differentiate them and
> you're back to a refnum approach.

That's a very good point. A VI feels to me more analogous to a C function.
In order to communicate with different devices, it needs another input
argument; a unique argument such as a refnum. I think I was wasting y
our
time when I was trying to figure out how to get rid of an extra input
argument that is needed. Thank you very much for taking the time to discuss
this with me. It was very helpful.

Thanks again for your help,

-Ed
0 Kudos
Message 5 of 5
(2,432 Views)