How to connect LabView to an automation server

[SteveMoores]

I have a COM interface on a server, I need to connect to this from LabView and then use the refnum to allow me to make calls using the interface. My server is registered and works frm VB, VBScript and C++ code. I accnot get this to work from LabView.

[Greg_McKaskle2]

> I have a COM interface on a server, I need to connect to this from
> LabView and then use the refnum to allow me to make calls using the
> interface. My server is registered and works frm VB, VBScript and C++
> code. I accnot get this to work from LabView.

Can you be more specific with where the problem is? I'm on a Mac at the
moment, so this is from memory, but you should be able to drop an Open
Automation node, create a constant for the input type refnum. Either
double click or Browse on the constant to find the .tlb file or browse
the system ones. At this point, the refnum out of the open will go into
property nodes or invoke nodes. This is used all of the time, so if you
have a problem with a specific server, please give more details as to
wh
ere it is failing, what error code is returned from open, from Invoke,
etc.

Greg McKaskle

[SteveMoores]

I have a server which has been developed over many years by my software team and as I have said works fine from within C++, VB, VBScript. It implements two interfaces, an IUnknown and an IDispatch. These are implemented seperately and NOT as a dual interface. The reason for this is that very early on it was implemented using ATL with a single interface and we have a need to support legacy systems and don't wish to alter this unless we really need to. I ( as you suggested ) am using the Automation Open vi, however this fails giving the error message and number:

error number 3005,
Automation Open: Object specified is not creatable in ActiveRIOTest.vi

On the upside, if I remove the Automation Open stage and then ensure that the server is running bef
ore I run my vi's then the controls which I have in my vi's do connect to the server and there invoke methods work well.

I have also attempted to create my own ActiveX exe/dll in VB to act as intermediary ( knowing that under normal circumstance the server runs ok under VB ) , the results are that from labview I can connect to my ActiveX exe/dll, I can initialise it but when I try to return the reference to my server object from VB to labview it fails. For your info I am working on a PC with XP. I appreciate that there is a lot of information here I hope you can pick out the important bits ??

[Greg_McKaskle2]

Thanks for the additional details.

Based on the error message, this looks familiar. In versions before LV7, LV would precheck to see if the interface claimed to be creatable. If not, it would return the error indicating that either you are trying to call open on a class that isn't creatable, or the construction of the class isn't quite right.

Once again, LV was trying to be correct when VB and other environments simply call open, ignoring the interface settings. So, in LV7, LV does likewise and should succeed on the Open call. Another way to fix this without upgrading LV versions would be to look at the definition of the class and make sure that it is marked as creatable.

Greg McKaskle

[SteveMoores]

Greg

Thanks for the response, I am using LV7 Express demo version having just placed an order for the s/w this week.

This afternoon we created a new version of our server with the two interfaces implemented in ATL as a dual interface.

My LV code now connects and works happily...

However, as I said previously this server has been in existance for a while now and of course many users use it and of course changing the interface would require changes for our customers, of course we would like to keep this to a minimum. It would appear that it is an interface implementation problem.