OLE Automation Server

[Richard RUDEK]

Hi all.

I've been asked to help in a project where the main portion of it is
being written using labview (G), which I'm not familiar with.

I've had a quick browse through the various labview manuals, and really
don't want to go off at a tangent from what I need to do, meaning that I
don't have time to become proficient with labview - the current
"developer" does not describe himself as a "programmer", which is why he
chose labview.

Anyway, the job requires me to interface a Thompson Frame Grabber card
(FGT) with labview. Thompson supply an SDK and the source for a
Microsoft Visual Studio sample program. Unfortunately, no source for the
SDK DLL/driver.

Reading their French-glish manuals, the way they expect you to control
the FGT card is via a supplied DLL. They do supply some guidance on how
to do this, but the problem I have is that the DLL requires various low
level capabilities to allow things like an overlay window, callbacks,
etc. Given that such info seems to be rather difficult (tedious) to
extract or have labview perform, I've decided I should write (using
Delphi or C++) another component to talk directly to their DLL, and have
labview control the new component that I write.

Looking through the various manuals, I see that labview supports
ActiveX, but I'm unsure wether that is restricted to just ActiveX
controls specifically, or wether labview can interface with an
Automation Server (OLE and ActiveX are built upon COM) ?

If so, how does one "import" the Automation server's interface into the
labview environment/IDE, so my "non-programmer" client to easily
interface with an Automation Server ?

The reason that I want to go with a standalone, out-of-process (OOP...?)
Automation Server, as opposed to an in-process server, or an ActiveX
control, is that (naive) attempts thus far with interfacing labview with
the FGT DLL has lead to serious side effects, such as crashing the
system. However, trivial trials using Borland C++ Builder to interface
with the FGT DLL produced none of those stability problems.

Another reason is that if I make an ActiveX control, the possibility of
multiple use rears it's head, which the DLL and overlay functions do not
support, nor make sense for it to.

I will shortly install a temporary copy labview (5.1 ?) on my Dual boot
Win98/Win NT4 system here, just to experiment with labview. But my
client is using NT4 SP6, with a dual processor Xeon system (although
we've removed one of the CPU's due to various weirdities with labview).

Any additional pointers or confirmations would be most helpful.
__ __ ________________________________________________________
//)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/ |
|________________________________________________________|

[B & C Duffey]

If you are more comfortable with C/C++ you could always write a wrapper for
the dll's that came with your frame grabber and expose a simpler interface
to LabVIEW.

Coincidently I am doing the same task right now for a Foresight Imaging
HIDEF Accura Frame Grabber - I elected to use the Foresight Imaging
libraries and dll's and wrap them in LabVIEW code interface nodes (CINS).
The documentation on National Instruments sight is good concerning how to
setup Visual C++ to create CINS and also how to call a dll from a CIN or
LabVIEW directly - although calling dll's that use odd data types and
structures can be very tedious and you WILL crash LabVIEW during development
play.

Go to their site and search for CIN or "calling a dll from LabVIEW".

I would stay away from ActiveX
- the LabVIEW container doesn't seem to be
fully capable (even in LV 5.1).
BUT maybe you could use the ActiveX controls in a dll wrapper or CIN wrapper
maybe ?? I tried using the ActiveX controls for my frame grabber and could
only get the most rudimentary functions to work, the ActiveX control works
great with VB though - figures....


Good Luck


Richard RUDEK wrote in message <3855ab94.7152706@news.zeta.org.au>...
>Hi all.
>
>I've been asked to help in a project where the main portion of it is
>being written using labview (G), which I'm not familiar with.
>
>I've had a quick browse through the various labview manuals, and really
>don't want to go off at a tangent from what I need to do, meaning that I
>don't have time to become proficient with labview - the current
>"developer" does not describe himself as a "programmer", which is why he
>chose labview.
>
>Anyway, the job requires me to interface a Thompson Frame Grabber card
>(FGT) with labview. Thompson supply an SDK and the sou
rce for a
>Microsoft Visual Studio sample program. Unfortunately, no source for the
>SDK DLL/driver.
>

[Greg_McKaskle2]

> Reading their French-glish manuals, the way they expect you to control
> the FGT card is via a supplied DLL. They do supply some guidance on how
> to do this, but the problem I have is that the DLL requires various low
> level capabilities to allow things like an overlay window, callbacks,
> etc. Given that such info seems to be rather difficult (tedious) to
> extract or have labview perform, I've decided I should write (using
> Delphi or C++) another component to talk directly to their DLL, and have
> labview control the new component that I write.
>
> Looking through the various manuals, I see that labview supports
> ActiveX, but I'm unsure wether that is restricted to just ActiveX
> controls specifically, or wether labview can interface with an
> Automation Server (OLE and ActiveX are built upon COM) ?
>
> If so, how does one "import" the Automation server's interface into the
> labview environment/IDE, so my "non-programmer" client to easily
> interface with an Automation Server ?
>
> The reason that I want to go with a standalone, out-of-process (OOP...?)
> Automation Server, as opposed to an in-process server, or an ActiveX
> control, is that (naive) attempts thus far with interfacing labview with
> the FGT DLL has lead to serious side effects, such as crashing the
> system. However, trivial trials using Borland C++ Builder to interface
> with the FGT DLL produced none of those stability problems.
>
> Another reason is that if I make an ActiveX control, the possibility of
> multiple use rears it's head, which the DLL and overlay functions do not
> support, nor make sense for it to.
>
> I will shortly install a temporary copy labview (5.1 ?) on my Dual boot
> Win98/Win NT4 system here, just to experiment with labview. But my
> client is using NT4 SP6, with a dual processor Xeon system (although
> we've removed one of the CPU's due to various weirdities with labview).
>

If you inflate any arrays or strings before calling the DLL, then
there shouldn't be any problem calling into the DLL. This is how
the NI drivers are built. If you would rather, then you can use
the ActiveX client functions. LV can contain controls, and can
access any automation server. The function for importing is the
Automation Open function. Its in the ActiveX palette. Popup on
it to create an automation refnum, and type it to be the server
that you are creating and registering.

As for problems with the Dual processor, I now of a number of
LV users that use dual processor machines with no problem. If
you have problems, it is more likely to be a problem with a
driver. If it is anything reproducable, then please report it
to NI.

Greg McKaskle

[Tan_lv]

hi greg ,

i m interfacing an "Aver media frame grabber card " that is being used with "Fath software".I m using Activex Container to access the properties and methods.
but most of the time it opens the preview window of the fath software and hangs up .
i basically want to control certain features of the fath software through my LV program.
for eg.
properties like
1. open the preview window .
2. ableto sety to composite .
3. able to set the window size. etc......

So, when we are using activexcontrol do we need to flush the buffer or something?(as a solution to why it keeps hanging the comp while executing.


regards
tanisha

[Lycangeek]

Just a few comments about LabVIEW's support for calling outside code.

1. We don't require full ActiveX support for the "Invoke Node" and "Invoke Property" type of control - only if you want the component to display its UI in the LabVIEW front panel. Thus you can use any COM control. One catch - Until LabVIEW 7 (maybe 7.1, I forget), your component had to support IDispatch. The later versions use the v-table directly so IDispatch is no longer required if you upgrade LabVIEW. I'm not sure what Duffey means about ActiveX not being fully capable but you should have no trouble calling an inproc or out-of-proc COM component.

2. As Duffey mentioned, we also support calling standard C-style DLLs. You can either invoke them directly via the "Call Library Node" or use the Code Interface Node approach. The different is that the CLN just calls the DLL - no special work needed there. The CIN requires that you build with some LabVIEW header files and follow certain rules (This is fully documented in LV's docs). The advantage of the CIN is that it allows you to do more advanced things such as accessing LV data types directly and allocate memory for LabVIEW, but it is much more complicated.

3. LabVIEW does work on multi proc machines so don't give up on that one. I can understanding keeping it single CPU to reduce the number of variables while you try to get the interface to the DLL working, but you don't need to eliminate SMP boxes.