Invoke Node on COM DLL can't configure input properly

[dpnsw]

I have a COM DLL I am trying to use from LV2013 32 bit. I have managed to get as far as the ActiveX "Automation Open" and an invoke node. This gets me a parameter list which looks right (input and outputs) but I'm not sure the actual datatypes are correct.

I have the DLL, a header file and an IDL file and 2 different bits of documentation (not all of which agrees).

I am trying initially to just connect to the server using the code below (see test Server Copnnect via dll.png)

This fails telling me I have incorrect input parameters.

One of the bits of documentation lists the paramters as:

char *pConnection                  Required

long ITimeout                          Optional

char *pOption                          Optional

but the idl file has:

HRESULT ConnectServer([in] CHAR *szPara)

and the header file has:

virtual /* [helpstring] */ HRESULT STDMETHODCALLTYPE ConnectServer( /* [in] */  CHAR   __RPC_FAR   *szPara) = 0;

I would have thought the idl and header files would be more reliable but then why does the method have 3 parameters?

Also the datatypes don't seem right.

szPara should be a pointer which should be Unlt32 for a 32 bit program (which this is) yet the data type reports itself as an I8 (8 bit integer). the szPara should contain connection txt such as "eth:10.10.10.10:5000".

I tried to create a string pointer to the data but it doesn't work. I tried typecasting to the I8 but that kills my data and I wind up passing zero to the dll. I tried it then as above but wind up with coercion dots. Do I need to convert my pointer into multiple bytes? (Not sure how to do this).

I looked at bunch of other invoke node calls into the same DLL and the parameter direction always seems correct and the data types do change (they are not all integers, some are reporting as real numbers) so it does look like the invoke node is working but I just don't know how to drive it.

Am I missing something obvious?

Many thanks

David

[dpnsw]

Couldn't get image in previous post so here it is

[rolfk]

Seems you would be better of getting the RoboWorks software as described here, instead of trying to figure out ActiveX, C++ and what else details.

citation from there:

There are two ways LabView can communicate with RoboWorks. The first is through data files that are created using LabView and then used to animate a RoboWorks model. The other means of communication is RoboTalk. RoboTalk offers realtime connectivity between LabView and RoboWorks. You can build your control and user interface application in LabView and use RoboWorks as a 3D display of your model. LabView vi's are installed with RoboWorks that allow you to communicate with it.

[nathand]

Something looks pretty broken here. Are you sure you're opening the correct ActiveX object? I could understand if the strings were being passed as arrays of chars (8-bit values) but accepting only a scalar seems weird. Can you provide a link to documentation, and ideally to the actual library you're using, if it's public?

[rolfk]

You can't allocate a pointer with one byte and then try to copy in a string which is more than one character. That surely will crash. LabVIEW has no way of resizing pointers, so you have to allocate them right from the start or better not at all and leave pointer acrobatics to the guy who knows best, which is the C compiler.

However from the picture alone it is not clear if szParam is recognized by LabVIEW to be a pointer. It could be just as well be a 8 bit value. It would seem that the guy who wrote that component surely has had a bad day when creating the type library. The type library certainly should define szParam and szOption as strings rather than a skalar pointed to reference and then LabVIEW would properly recignize that these parameters are strings and show them as such in the diagram node.

The discrepancy between the names of the parameters between what your documentation says and what LabVIEW recognizes is another hint that you might in fact be barking up the wrong tree (in other words looking at the wrong Active X Object in that Automation Server DLL).

[rolfk]

Another note: Why don't you download RoboTalk from Newtonium? They do include a LabVIEW library in there that accesses a DLL interface.

[dpnsw]

Thankyou for the help.

In terms of alternate libraries I don't think I have alot of flexibility here. This particular dll talks to a specific brand of robot, I will try pulling an earlier version of the dll and see if it behaves the same. The Newtonium dll just happens to have the same name rather than being equivalent. I need to talk to a specific Denso RC7M controller and the Denso VSA robot attached.

There are some prebuilt VI's available from ImagingLab / Digimetrix but they don't work properly and the support people can't seem to get them working. I can connect and run move commands on the robot BUT it only works if I manually put the robot into a specific mode each time and at the end of the move sequence the robot drops out of that mode and I have to manually put it back in that mode. When I use the Denso test tools everything work properly so it looks like the LabVIEW vi's from ImagingLab/Digimetrix have a problem that is a show stopper for us.

The option I am therefore exploring is hte ROBOTalk.dll which implements the ROBOTalk protocol between the PC and the controller I just didn't expect it to be so complicated. I have attached the full list of exports from the dll (using DLL export viewer) and I am trying the use the one below.

Function Name                           Ordinal                                   Type                 Filename      
IRbtlkEngine::ConnectServer    1610678272 (0x60010000)    COM Method    ROBOTalk.dll            

I am interested in how I might have picked up the wrong object, can anyone give me some more details on that. When i select the method in LabVIEW I get an option to show all methods not just the ones I can connect to and it lists 2 x ConnectServer

IRbtlkEngine::ConnectServer

and

RbtlkEngine::ConnectServer

I have chosen both but it always winds up as the same IRbtlkEngine::ConnectServer (which I am guessing is the public interface).

I don't think i can attach the actual dll however because it is part of a licenced product 😞

I will go back and check alternate versions of the dll (I just picked the latest production one assuming it would be the best).

Documentation wise I only really have the header files and a windows help file that is commented in Japanese.

All the best

David

[dpnsw]

Hi nathand,

It is good to hear that things look strange, it may not be just me after all.

In terms of the actual dll and help file I don't think I can post publicly but could send directly if someone is willing to have a look at them, just let me know via private message (I haven't used this feature before but assume it should just work).

Many thanks

David

[rolfk · Accepted solution]

A list of function names in the DLL is as useful to diagnose the issue at hand as would be a a list of random characters to understand a language: Niente, Nada!

It's even worse than having just a header file for a standard C DLL, which at least can tell a little about the parameters but the C syntax is notoriously inadequate to describe the actual API in a disambigous way.

In there "char* name" can be a string, a single character passed by reference or a byte array. "void *name" is even more ambigious as it could be basically anything! That is why Microsoft created ActiveX with a typelibrary interface that describes the functions in much more detail and this typelibrary is what LabVIEW (and Visual Basic and other "Visual" languages) accesses to build the diagram nodes that access the methods and properties of an ActiveX object. If this type library is wrong there is nothing you can do in LabVIEW to make it work anyways except writing a C++ wrapper that access the ActiveX object and translates them to a correct ActiveX interface. The reason is that VisualC does allow to access the typelibrary but as a true C descendent also allows to do everything the hard way by programming every detail explicitedly.

As to your problem with the Denso library that would not so much look like the library in itself is bad but that they forgot to document some attribute or register value that needs to be set in order to get the robot unit in remote mode. Robotic manufacturers are notorious to deliver little support in accessing their hardware from third party applications. If they have a library at all then it's often crippled and hampered with such little inconviniences and problems.

But trying to access a badly documented interface to circumvent that limitation is very likely going to be an even more frustrating exercise. Just by being able to access their obviously quite badly designed interface you will most likely run into many more problems. These interfaces will at some point require magic numbers as parameter such as register addresses to write specific values into and I would be surprised if this documention is more detailed about such details than the "official" library is, what they provide for LabVIEW.

You may maybe feel that this is all bad talk trying to take away the joy in having a fully working solution for your problem, but believe me I have been there and dealt with robotic interfaces and the only way that really works in the long run is to find the guy who knows and get them to find out what register address needs to be tickled to make the LabVIEW interface work as you want it.

An interesting industrial partner with some good sales prospects in case it can be made to work of course helps a lot. Then the sales people are sometimes more likely to keep pushing technical staff in the factory to spend a few more minutes to find some dust collecting document in the depths of their (digital) archives.

[rolfk]

double post